เรื่องที่ 20 ที่นักพัฒนาควรรู้ และ เข้าใจก็คือ Make the Invisible More Visible
พยายามให้การพัฒนา software มันโปร่งใส (transparentcy)
พยายามให้การพัฒนา software เป็นอะไรที่จับต้องได้
พยายามพูดความจริง
แต่ปกติการพัฒนา software มักขาดความโปร่งใส
ทั้งการพัฒนา และ ขั้นตอนการพัฒนา
ที่มักจะถูกเก็บซ่อนไว้เสมอ
ทำไมนะ ?
ตัวอย่างของความไม่โปร่งใส หรือ สิ่งที่มองไม่เห็น
1. Source code
ปกติเราจะเห็น source code ก็ต่อเมื่อทำการเปิดด้วย Editor/IDE
และมันจะหายไปเมื่อจะการปิดมันลงไป
เรามักพบว่า source code มักจะไม่มีใครสนใจ
จนกว่ามันจะเกิดปัญหาขึ้นมา
จุดนั้นแหละที่คุณมักจะพบว่า source code มันรกรุงรังไปหมด
เหมือนกันต้นไม้ที่คุณไม่เคยสนใจ ไม่เคยดูแล
2. สนใจแต่การทำงาน หรือ สิ่งที่เห็นของระบบ โดยไม่สนใจ code เลย
เราไม่เคยสนใจเลยว่า ระบบที่ใช้งานอยู่นั้น
มันถูกสร้างมาด้วย code อย่างไร แบบไหน
ตัวอย่างเช่น google.com นั้นมี user interface ที่เรียบง่ายมากๆ
แต่คุณรู้ไหมว่า code และ โครงสร้างด้านหลังเป็นอย่างไร
3. การแก้ไข bug และการ debug
ถ้าเมื่อไรที่นักพัฒนาบอกว่า งานเสร็จแล้ว 90% เหลือ 10% คือการ debug
ให้คุณเดาไว้ก่อนเลยว่า งานมันยังไม่เสร็จ 90% หรอกนะ
การ debug นั้นมันไม่ได้ก่อนให้เกิดประโยชน์ใดๆ เลย
กลับทำให้เสียเวลาไปอีกต่างหาก
ดังนั้นแทนที่จะเสียเวลาไปกับการ debug
ให้มาเสียเวลาเพื่อทำให้เห็นว่า
คุณคิดอย่างไร เพื่อที่จะสร้าง หรือ ไม่สร้าง มันขึ้นมาดีกว่านะ
4. Progress ของการพัฒนาระบบ
ปกติในการพัฒนา software นั้น
ในช่วงแรกๆ มักจะไม่ค่อยมีปัญหาอะไร progress การทำงานมันตรงตามแผนงานทั้งหมด
แต่เมื่อทำไปเรื่อยๆ ก็เริ่มเกิดอาการแปลกๆ
เช่น พัฒนาช้าไป ติดปัญหาโน่นนี่นั่น
แต่เราก็ยังรายงาน progress ไปว่ามันยังตามแผนนะ
และเมื่อเวลาผ่านไปเรื่อยๆ ณ วันหนึ่ง
เรากลับบอกว่า ระบบงานที่พัฒนามันต้องเลื่อนไปอีกนะ
คุณคิดว่า ปัญหามันเกิดจากอะไร ?
การพัฒนาที่ไม่โปร่งใส หรือ ปิดบังขั้นตอนการทำงานไว้นั้นมันอันตรายมากๆ
ดังนั้น ในการจะทำอะไรสักอย่างนั้น
ควรให้มันชัดเจน ทำให้คนอื่นๆ เห็นภาพชัด
มองเห็นขั้นตอนการทำงานชัดเจน
ไม่ต้องมา tracking progress น่าจะดีกว่าหรือเปล่า
เนื่องจากการ tracking progress มันคือการแก้ปัญหา ด้วยการสร้างปัญหาขึ้นมาอีกหรือเปล่า ?
ดังนั้น เราจำเป็นจะต้องเปลี่ยนวิธีการจัดการ
ในเรื่องของการคิด การทำ ที่แตกต่างไปจากเดิมแล้วนะ
ตัวอย่างเช่น
1. การเขียน Unit test
ในการเขียน code นั้น มันคือการแก้ไขปัญหา
แต่นักพัฒนาส่วนใหญ่ จะลงมือแก้ไขปัญหาทั้งหมดในครั้งเดียวเลย
ซึ่งนั่นคือปัญหา !!
ดังนั้น ลองมาเปลี่ยนวิธีการพัฒนาใหม่
โดยให้เริ่มเขียน Unit test ก่อน เพื่อต้องสมมุติฐานของการทำงาน
ว่ามี input แบบนี้ เมื่อผ่านกระบวนการทำงานหนึ่งๆ แล้ว จะได้ output อย่างไร
หลังจากนั้น จึงเริ่มทำการเขียน code จริงๆ
ซึ่งวิธีการนี้ มันทำให้คุณรู้ว่ากำลังจะแก้ไขปัญหาย่อยๆ อะไรตรงไหน
และมันช่วยบอกคุณว่า คุณเข้าใจสิ่งที่กำลังแก้ไขหรือไม่
รวมทั้งใช้บอก progress การทำงานของคุณด้วยว่าเป็นอย่างไร ถึงไหน
ยังไม่พอ Unit test มันยังใช้บอก หรือ พูดคุยกับคนอื่นๆ ด้วย
ว่าคุณคิดอย่างไร มันชัดเจนเอามากๆ
และ code ที่ได้มานั้นมันจะไม่ผูกติดกันมาก
มีการทำงานเฉพาะอย่างอีกด้วย
ถ้าไม่เชื่อก็ลองทำดูนะครับ
2. Automated Unit test
ปกติในการพัฒนา software
จะทำทดสอบอย่างไร ?
จะทำการทดสอบตอนไหน ?
ใครเป็นคนทดสอบ ?
ใช้เวลานานไหม นานเท่าไร ?
คำถามเหล่านี้ มันล้วนได้คำตอบที่บ่งบอกถึงปัญหาทั้งนั้น
แต่ถ้าเราและทีมพัฒนาเขียน Unit test แล้ว
เราสามารถ checkout code ทั้งหมดมา
และทำการ run Unit test ทั้งหมดซะ
เพื่อให้รู้ว่า ระบบงานของเรายังคงทำงานได้ตามที่คาดหวังนะ
มันสร้างความเชื่อมั่นให้ทีมพัฒนา
มันช่วยทดสอบระบบงานให้เราอยู๋ตลอดเวลา
มันใช้เวลาทดสอบน้อยมาก
ใครๆ ก็สามารถทดสอบได้
มันก็น่าจะช่วยให้เห็น progress ของการพัฒนาโดยรวมได้นะ
สิ่งที่ได้มาคือ เรื่อง ความน่าเชื่อถือ และ ความถูกต้อง ใช่หรือไม่
แต่ต้องเริ่มสร้างมันขึ้นมานะครับ
3. สร้าง Board และ Card ของงานขึ้นมา
ปกติงานต่างๆ และเอกสารการพัฒนาต่างๆ มันมักจะอยู่ในรูปแบบของไฟล์
เช่น Excel, Word, project management tool เป็นต้น
คำถามคือ มีใครบ้างที่เปิดอ่านทั้งหมด ?
คำถามคือ ทำไมไม่มีใครเปิดอ่าน ?
คำถามคือ งานแต่ละคนไปถึงไหนล่ะ ? เบื่อไหม ?
คำถามคือ ทำการ tracking progress อย่างไร ?
มันจึงเกิดปัญหาตามาใช่ไหม ?
แต่ก็ยังทำกันอยู่ ทั้งๆ ที่มันก็เปิดปัญหาเดิมซ้ำแล้วซ้ำเล่า !!
ดังนั้น เปลี่ยนง่ายๆ ด้วยการ
- เขียนงานต่างๆ ลงใน Card ที่เป็นนกระดาษ
- นำ Card ต่างๆ ไปติดบน Physical board ซะ
- Board นั้นก็แบ่งออกเป็น 3 ช่องง่าย คือ Not Start, In progress และ Done
เพียงเท่านี้
เราไม่ต้องการ project management tool แล้ว
เราไม่ต้องการ tracking progress ล่ะ
เพราะว่า progress การทำงานนั้นมันอยู่บน board
ใครๆ ก็สามารถมองเห็นมันได้
ไม่มีการปิดบังการทำงานใดๆ ทั้งสิ้น
4. ส่งมอบ software อยู่ตลอดเวลา และ สม่ำเสมอ
ปกติเรามักจะส่งมอบงาน หลังจากการพัฒนาทุกอย่างเสร็จสิ้น
ปัญหาที่ตามมาก็คือ สิ่งที่เราบอกว่าเสร็จ มันไม่เสร็จ
และพบว่างานที่กลับมาให้ทำใหมม่ แก้ไข มันเยอะมาก
รวมทั้ง bug ก็เยอะ
แต่แปลกนะ ก็ยังทำการพัฒนาในรูปแบบนี้กันอยู่เยอะมากๆๆๆ
ดังนั้น เราลองเปลี่ยนไหม ?
ด้วยการส่งมอบ software ที่สร้างอยู่บ่อยๆ และสม่ำเสมอ
เช่น ส่งมอบทุกๆ 5 วัน 10 วัน หรือ 1 เดือน
เพื่อให้ลูกค้าได้ลองใช้งาน ได้รับรู้ progress ของงานอยู่ตลอดเวลา
ว่าจริงๆ แล้วการพัฒนามันไปถึงไหน มันมีปัญหาอะไรหรือไม่
หรือว่าควรจะหยุดพัฒนาได้แล้วหรือไม่
นั่นคือ ช่วยลูกค้าลดค่าใช้จ่ายในการพัฒนาด้วยนะ
มันน่าจะดีกว่าไหม ?
โดยรวมแล้ว
การพัฒนา software มันควรจะโปร่งใส
การพัฒนา software มันควรจะสามารถจับต้องได้
ทั้งทีมพัฒนาเอง และ ลูกค้า ด้วย
เพื่อทำการสร้างความเชื่อมั่นซึ่งกันและกัน
ไม่ต้องมาสร้างภาพ ไม่ต้องมาพูดจาด้วยคำสวยหรู
ไม่ต้องซ่อน ไม่ต้องปิดบังความจริง
แต่เอาสิ่งที่ต้องการมาให้ลองใช้งาน ให้ลองสัมผัส
มันจะทำให้เห็นภาพจริง และ progress งานจริงๆ
เรื่องจริงไม่เคยฆ่าใคร
แต่มันช่วยให้เรารู้ว่า ควรที่จะปรับปรุงอะไรบ้าง ?
