ดูเหมือนว่า อะไรๆ มันก็มีปัญหาไปหมดนะ

ในการพัฒนา software นั้น มันมักจะมีสิ่งที่แปลกๆ ออกมาให้เห็นเสมอ
ตัวอย่างเช่น ถ้าผลการทำงาน หรือ พัฒนามันออกมาไม่ดี
เรามักจะโทษโน่น นี่ นั่น อยู่เสมอ
โดยที่เราจะไม่มองย้อนดูตัวเราเอง
ว่าเป็นสาเหตุคืออะไร และ จะปรับปรุงอย่างไรดี

มันแปลกดีไหม ?

มาดูตัวอย่างของปัญหากัน

ปัญหาการ Estimate หรือการประเมินงาน

บ่อยครั้งเรามักจะพบว่า การ estimate หรือประเมินงาน เวลา หรืออะไรก็ตาม
มันมักจะไม่เป็นไปตามที่คาดหวังเลย
ทำให้มันเกิด drama อยู่บ่อยครั้ง
แต่เราก็พยายาม ที่จะหาวิธีการ estimate ให้ตรงหรือใกล้เคียงที่สุด
แต่ผลออกมาก็เหมือนๆ เดิม

เนื่องจากเราสนใจไปที่การปรับปรุงการ estimate
มากกว่า ให้ความสนใจไปที่การปรับปรุง product ให้ดียิ่งขึ้น
ทำไมนะ ?
ทั้งๆ ที่เราต้องการจะพัฒนา product/software ไม่ใช่หรือ !!

เนื่องจาก เราไปสนใจว่า จะต้อง estimate
ให้อยู่ในงบค่าใช้จ่ายที่ตั้งไว้นะ
นั่นคือ จัดการด้วยสิ่งที่เรียกว่า deadline
นั่นคือ คุณพยายามจะจัดการการพัฒนา product
แบบ fixed cost และ fixed scope นั่นเอง
ผลที่ออกมา ก็ไม่ได้เป็นดังที่คาดหวังใช่ไหมล่ะ ?
แต่ก็ยังคงตั้งหน้าตั้งตาทำไปอยู่อย่างนั้น !!

เจ็บ 1 ครั้ง ยังพอให้อภัย
เจ็บ 2 ครั้ง ยังพอทน
แต่เจ็บมากกว่านั้น มันคืออะไร ?

ดังนั้น เราจึงสรุปตรงๆ ได้เลยว่า การ Estimate มันแย่
เราไม่ควรทำการ Estimate นะ

2. Deadline เจ้าปัญหา

เมื่อเราพูดถึงคำว่า deadline ในการพัฒนา software
มันเป็นคำหยาบ คำไม่ดี ที่ใครๆ ก็ไม่อยากพูดถึงมัน !!
มันทำให้เราและทีม ต้องทำอย่างไรก็ได้ ด้วยวิธีอะไรก็ได้
เพื่อทำให้ product มันเสร็จๆ ไปซะ !!

คำถาม
ผลที่ได้คืออะไรล่ะ ?
คำตอบ
ลูกค้าไม่ happy เลย เมื่อใช้ product !!
จะขอเปลี่ยน ก็เปลี่ยนไม่ได้
หรือถ้าเปลี่ยน ก็จะใช้เวลามาก

Product ที่พัฒนาออกมาด้อยคุณภาพ
Bug เพียบ !!

หนักกว่านั้น ไม่สามารถส่งมอบทุกๆ feature ได้อีก

ดังนั้น เราจึงสรุปได้ว่า Deadline มันแย่
เราไม่ควรมี Deadline หรอกนะ

3. Backlog หรือ User Story มันแย่

backlog ที่เรานำมาใช้งาน มันแย่นะ
เพราะว่า เรากำหนดทุกอย่างไว้แล้วว่า
แต่ละช่วงต้องทำ backlog อะไรบ้าง ตาม deadline ที่กำหนด
และบังคับให้ทีมพัฒนาสัญญาว่า จะทำงานใน backlog ให้เสร็จตาม deadline ที่กำหนด
สุดท้าย ก็ทำไม่เสร็จหรอกนะ หรือจะเสร็จก็ต้องเหนื่อยกาย และ เหนื่อยใจอย่างมากมาย
ซึ่งมันทำให้เราปรับปรุง เรื่องของการ estimate หรอ ?

บ่อยครั้ง ที่มาเพิ่มอะไรไม่รู้มาใน backlog อีก
แต่ยังต้องทำให้เสร็จ ทำให้เสร็จ ทำให้เสร็จ ใน deadline นะ !!

ดังนั้น เราจึงสรุปได้ว่า Backlog มันแย่
เราไม่ควรมี Backlog หรอกนะ

คำถาม
มันถูกต้องแล้วหรือ ที่คุณจะไม่ทำการ Estimate ไม่มี Deadline และ ไม่มี Backlog ?
คำตอบ
ลองมานั่งคิดกันหน่อยไหมว่า ทำไมล่ะ?
ลองคิดหน่อยสิว่า ถ้าเราเปลี่ยนแนวคิดในการพัฒนา product
จาก Fixed scope และ Fixed date (deadline) มาเป็น

• ส่งมอบ feature ของ product ที่ละ feature เล็กๆ
• ถ้าคิดว่า feature ใดมัน estimate ยาก ทำไมไม่แบ่งเป็น feature เล็กๆ เพื่อให้ estimate ได้ง่ายขึ้นล่ะ
• หยุดคิด !!  แล้วหาวิธีการใหม่ๆ เพื่อทำให้มันดีขึ้นดีกว่าไหม

บางคนคิดว่า วิธีการใหม่ๆ มันไม่ work หรอก
แต่ลองคิดดูสิ อย่างน้อยมันก็ไม่น่าจะแย่ไปกว่าเดิมหรอกนะ

จากหนังสือ The Nature of Software Development

อธิบายไว้ว่า

• การพัฒนา product/software คือ การส่งมอบ product ที่มีคุณค่าให้แก้ลูกค้า
• ต้องทำการส่งมอบ product ที่มีคุณค่าอยู่อย่างเสมอ ถ้าเราส่งได้ทุกๆ วันจะดีมาก แต่ถ้าส่งปีละครั้ง ไม่น่าจะดีนะ ว่าไหม ?
• Feature อะไรที่มันใหญ่ๆ มันจะสิ้นเปลืองมากๆ ทั้ง เวลา คน และ ค่าใช้จ่าย ดังนั้นแยก feature ออกมาซะ อย่าไปเสียเวลากันมันมากนัก
• การจัดการการพัฒนา software ที่ดีคือ การพัฒนา feature เล็กๆ ไปเรื่อยๆ แล้วคุณจะเห็นว่าทีมพัฒนามีศักยภาพอย่างไร และ ควรจะปรับปรุงอะไรบ้าง
• Feature ที่มีคุณค่าต่อลูกค้าสูงสุด ควสรจะทำให้เสร็จอันดับแรกๆ นะ ปัจจุบัน feature อะไรเสร็จก่อนกันหรือ มันมีคุณค่าต่อลูกค้าไหม !! เรามันมีคุณค่าต่อคนสร้างกันแน่ ?
• การพัฒนา software คือ การตอบรับต่อการเปลี่ยนแปลงนะ ดังนั้น การเปลี่ยนแปลงเป็นเรื่องปกติ ดังนั้น ถ้าเราแยก feature เป็น feature เล็กๆ แล้ว ผลกระทบจะน้อยกว่า feature ใหญ่ๆ ไหม ? ลองคิดดู ?
• ทุกๆ feature ที่ส่งมอบจะต้องสามารถทำงานได้อย่างดี ถ้า feature ที่ทำงานไม่ได้ หมายถึงคุณไม่ได้ส่งมอบคุณค่าไปให้ลูกค้านะ มันคือการทำให้แบบเสร็จๆ ไปที
• ทีมพัฒนาควรเรียนรู้ วิธีการสร้าง feature-by-feature ให้มันทำงานได้และดีอยู่อย่างเสมอ ซึ่งต้องได้รับการสนับสนุนจากทาง management ด้วยเช่นกัน

ดังนั้นถามอีกครั้ง

คำถาม
มันถูกต้องแล้วหรือ ที่คุณจะไม่ทำการ Estimate ไม่มี Deadline และ ไม่มี Backlog ?
คำตอบ
เราคงไม่ต้องมาเสียเวลาไป เพื่อถกเถียงกันหรอกนะ
ทีมพัฒนาควรไปทำงานใกล้ชิดกับทาง business
และ business ก็ควรไปทำงานใกล้ชิดกับทีมพัฒนา
อย่ามาต่อสู้กัน
เนื่องจากมันไร้ซึ่งประโยชน์ใดๆ ทั้งสิ้น

Reference Website
Artifacts are not the problem