- Story Point ไม่น่าเชื่อถือโดยสิ้นเชิง ก่อให้เกิดความสับสน และต้องคอยอธิบายความหมายให้ผู้เกี่ยวข้องฟังอยู่เสมอ
- ค่าพอยต์ที่ต่ำจะมีความแม่นยำมากกว่า แต่ค่าพอยต์ที่สูงจะสมมติความผันผวนที่สูงขึ้นและเป็นเพียงช่วงค่า จึงไม่สามารถนำมาบวกรวมกันอย่างแม่นยำได้
- Story Point ไม่ได้แทนเวลา แต่เมื่อถูกใช้คู่กับเมตริกความเร็ว ก็แทบจะกลายเป็นตัวแทนของเวลา ส่งผลให้การนำตัวเลขและช่วงค่ามารวมกันตั้งแต่แรกเป็นสิ่งที่ผิด
- การประมาณงานซอฟต์แวร์เป็นเรื่องยาก และผลลัพธ์ของกระบวนการนี้โดยทั่วไปไม่ได้ให้ประโยชน์มากเมื่อเทียบกับสิ่งที่ใส่เข้าไป
- ทีมขนาดเล็กที่มีสิ่งรบกวนน้อยมักดูเหมือนประมาณได้แม่นยำ จึงทำให้เกิดภาพลวงตาว่าสิ่งที่ทำอยู่ใช้ได้ดีในกรณีส่วนใหญ่
- เมื่อ Capacity ถูกใช้งานจนเต็ม ความผันผวนของงานทั้งหมดจะพุ่งสูงขึ้นอย่างมาก และส่งผลกระทบอย่างรุนแรงต่อทุกการประเมินและไทม์ไลน์
- การวัด Queue ช่วยแก้ปัญหาการประมาณทั้งระยะสั้นและระยะยาว รองรับการเปลี่ยนขอบเขตงานได้อย่างเป็นธรรมชาติ และสร้างคุณค่ามากกว่าสำหรับทีมขนาดใหญ่ พร้อมลดความไม่แน่นอน
- การวัด Queue ให้สัญญาณนำที่ช่วยคาดการณ์ปัญหาได้เร็วกว่าตัวชี้วัดที่เกี่ยวกับ velocity หรือ cycle time ถึง 20 เท่า
Story Point คืออะไร?
- ตาม Atlassian Story Point คือหน่วยที่ใช้แสดงการประมาณความพยายามทั้งหมดที่ต้องใช้เพื่อทำรายการใน product backlog หรืองานอื่นให้เสร็จสมบูรณ์
- Point ใช้แทนความซับซ้อน ปริมาณงาน ความเสี่ยงหรือความไม่แน่นอน และขนาดของงาน
- การวัดความซับซ้อนเป็นแนวคิดเชิงสัมพัทธ์ ดังนั้นแต่ละทีมอาจประเมินงานเดียวกันต่างกันได้
- ด้วยธรรมชาติแบบสัมพัทธ์ของ Point การเปรียบเทียบข้ามทีมจึงไม่มีความหมาย ซึ่งเป็นปัญหาที่มักเกิดขึ้นในระดับการบริหาร
ความผันผวนที่มีอยู่โดยธรรมชาติ
- Story Point อิงกับลำดับฟีโบนัชชี ทำให้ค่ายิ่งสูงยิ่งสะท้อนความผันผวนที่มากขึ้น
- การนำค่าพอยต์ที่มีความผันผวนสูงมาบวกรวมกันไม่มีความหมาย และการรวม Point ในเมตริก velocity เป็นการใช้งานที่ผิด
- ตามกฎของ Goodhart เมื่อใดที่ตัวชี้วัดกลายเป็นเป้าหมาย ตัวชี้วัดนั้นจะไม่สามารถเป็นตัวชี้วัดที่ดีได้อีกต่อไป
ปัญหาที่รู้กันอยู่แล้ว
- ปัญหาของ Story Point เป็นที่รู้กันดี แต่ยังคงถูกใช้อยู่ เพราะเทคนิคการประมาณแบบอื่นก็เจอปัญหาคล้ายกัน
- Ron Jeffries ผู้ให้กำเนิด Story Point เองก็ปฏิเสธมัน และวิจารณ์การใช้งานที่ผิดรูป
- ใน Scrum มีการเปลี่ยนคำว่า "Commitment" เป็น "Forecast" แต่ก็ยังถูกใช้อย่างผิด ๆ อยู่ดี
- เกิดสถานการณ์ย้อนแย้งที่เมื่อทำงานได้มากกว่าที่ประเมินไว้ กลับกลายเป็นถูกตำหนิ
จัดลำดับความสำคัญด้วย ROI
- ธุรกิจจัดลำดับความสำคัญของงานเพื่อเพิ่มประสิทธิภาพการใช้ทรัพยากร เช่น เวลา เงิน เครื่องมือ และคน
- การประมาณงานพัฒนาเป็นสิ่งจำเป็นต่อการคำนวณต้นทุนการลงทุน แต่ตัวการประมาณเองก็ทำได้ยากและมีต้นทุนสูง
- Software Estimation: Demystifying the Black Art เป็นหนังสือที่ยอดเยี่ยมซึ่งกล่าวถึงความยากของการประมาณงาน
ผลลัพธ์ของกระบวนการ
- กระบวนการประมาณด้วย Story Point ใช้เวลามาก แต่ผลลัพธ์กลับไม่มีคุณค่า
- เซสชัน grooming เป็นประจำใช้เวลามาก และแต่ละทีมก็ทำแตกต่างกันโดยไม่มีความสอดคล้อง
- การจัดทำรายการงานที่มีความหมายจริง ๆ มีคุณค่ามากกว่าการให้ Story Point
ทางเลือกที่เสนอ
- การประมาณด้วย T-shirt size อาจเป็นทางเลือกที่ดีกว่า แต่ก็ยังมีปัญหาเช่นกัน
- การประมาณด้วยเวลาก็มีปัญหาคล้ายกัน เพราะเวลาที่ทีมใช้ทำงานจริงกับเวลาที่ฝั่งธุรกิจคาดหวังนั้นแตกต่างกัน
- สำหรับทีมเล็ก การประมาณด้วยเวลาอาจใช้ได้ผลดี แต่เมื่อทีมใหญ่ขึ้น ความแม่นยำของการประมาณจะลดลง
- หนังสือ "The Principles of Product Development Flow" ของ Donald Reinertsen เสนอทางเลือกไว้
- แก่นสำคัญคือการโฟกัสที่การจัดการคิว (Queue) เพื่อเพิ่มประสิทธิภาพของการไหลของงาน
- ควรมีการวางแผนกำลังการผลิตและเตรียม buffer capacity เพื่อรองรับความผันผวน
วิธีแก้ปัญหา
- เริ่มจากให้ทีมวิเคราะห์งานร่วมกัน แยกออกเป็น task ย่อยขนาดเล็ก และกำจัดความไม่แน่นอน
- รายการ task จะกลายเป็นคิว (Queue) และจำนวน task รวมทั้งหมดจะแทนขนาดของงาน (Job Size)
- ใช้ค่าเฉลี่ยอัตราการทำ task เสร็จ (Average Task Rate) เพื่อประมาณแทน Story Point
- ติดตามงานตามความเร็วเฉลี่ยในการทำงาน และคำนวณอัตราการทำงานเสร็จ
- เมื่อมีข้อมูลใหม่หรือ feedback เพิ่มเข้ามา ก็อัปเดต task ได้ และทำให้ค่าประมาณปรับตามได้อย่างเป็นธรรมชาติ
- นักพัฒนาไม่จำเป็นต้องรับแรงกดดันทางจิตวิทยาจากการประมาณงาน
คิว (Queue) คือสัญญาณนำ
- ค่าเฉลี่ยอัตราการทำ task เสร็จ, Cycle Time, Velocity ฯลฯ เป็นตัวชี้วัดแบบตามหลัง ขณะที่ Queue เป็นตัวชี้วัดแบบนำ
- เมื่อขนาดของ Queue เพิ่มขึ้น ก็สามารถรับรู้ปัญหาล่วงหน้าและตอบสนองได้
สรุป
- Story Point สร้างความสับสน ไม่น่าเชื่อถือ และเหมือนถูกออกแบบมาให้ล้มเหลว
- สิ่งที่มีความหมายและมีคุณค่ากว่าคือให้ทีมใช้เวลาร่วมกันทำความเข้าใจปัญหา กำจัดความไม่แน่นอน แยกงานเป็น task ย่อย และจัดการ Queue
ความเห็นของ GN+
- วิธีจัดการ Queue ที่บทความเสนอ ดูเป็นทางเลือกที่สมจริงในการก้าวข้ามความยากของการประมาณงานในกระบวนการพัฒนาแบบ Agile
- อย่างไรก็ตาม กระบวนการแยกงานเป็น task ย่อยอาจเพิ่มภาระให้กับนักพัฒนา และในช่วงต้นของโปรเจกต์อาจต้องใช้เวลามากขึ้น
- นอกจากนี้ กระบวนการวิเคราะห์ task ยังตั้งอยู่บนสมมติฐานว่านักพัฒนาต้องมีส่วนร่วมอย่างแข็งขันและแสดงความคิดเห็นอย่างตรงไปตรงมา
- ในอีกด้านหนึ่ง ก็อาจคาดหวังผลเชิงบวกได้เช่นกันจากการที่ทีมพัฒนาจะเข้าใจความต้องการทางธุรกิจอย่างลึกซึ้งและช่วยกันคิดมากขึ้น
2 ความคิดเห็น
นั่นไม่ใช่วิธีการแบบคัมบังหรอกเหรอ..?
ความคิดเห็นจาก Hacker News
จากประสบการณ์ส่วนตัว ตัวเลขของ story point ไม่ได้สำคัญนัก แต่กระบวนการที่ทีมใช้ประเมินความซับซ้อนของงานนั้นมีประโยชน์มาก
การที่คำว่า "Commitment" ในคู่มือ Scrum ถูกเปลี่ยนเป็น "Forecast" ไม่ได้เกิดขึ้นในปี 2011
การแยกแพ็กเกจงานออกเป็นหน่วยอะตอมและการวัดความยาวของคิวเป็นคนละมิติของปัญหา
ในบางกรณี วิธีแบบ waterfall และการประเมินเป็นหน่วยเวลาก็ใช้ได้ผลดี
story point ไม่ใช่หน่วยเวลา แต่สะท้อนความซับซ้อนสัมพัทธ์และความไม่แน่นอน
story point เป็นหน่วยเวลาคร่าว ๆ
ตอนเริ่มใช้ Scrum ครั้งแรก เคยใช้ Rally
story point มีประโยชน์เวลาพูดคุยเรื่องความซับซ้อนของงาน แต่ไม่เหมาะกับการวัดความเร็ว
การประเมินโครงการพัฒนาซอฟต์แวร์ให้เชื่อถือได้นั้นยาก
การประเมินเป็นหน่วยเวลาเป็นวิธีที่ดีกว่า