Story Points ไม่ได้มีไว้บอกว่าทำงานเสร็จแน่

สิ่งหนึ่งที่ Story Points มักถูกนำไปใช้อย่างผิดวิธี คือการให้คะแนน Story Points เทียบกับจำนวนที่นักพัฒนาต้องใช้ในการเขียนโปรแกรม โดยอาจจะเป็นจำนวนชั่วโมง จำนวนวัน

การนำค่าของ Story Point ไปให้คำสัญญาว่า Sprint ต่อไป เราจะทำอะไรได้บ้าง ด้วยจำนวน Story Points ที่เท่ากัน นั้นผมคิดว่า มันง่ายที่จะถูกชี้นำให้เข้าใจผิด

ท้าวความเดิมก่อน ว่า Story Points เกิดขึ้นมาได้ยังไง

ที่มาของ Story Points

ในฝั่ง Business สิ่งที่ต้องการจะรู้คือ งานจะเสร็จเมื่อไหร่ แต่ในความเป็นจริง ในเรื่องของ ซอฟแวร์ เราไม่ได้กำลังสร้างบ้านที่มีโครงสร้างที่ชัดเจน แต่มันเป็นการประกอบของไอเดีย ที่ “น่าจะเวิร์ค” เอามารวมกัน ทำให้ปัญหาคือ การพัฒนา มีความเสี่ยงว่า มันอาจจะใช้งานไม่ได้ หรือ มันอาจจะใช้ท่านั้นๆ ในการพัฒนาไม่ได้

แต่ครั้นพอ Business จะเค้นเอาคำตอบ ในยุคสมัยก่อน เมื่อถูกบีบคอ ก็ต้องให้คำตอบไปว่า โอเค เราจะใช้ระยะเวลากี่ชั่วโมงหรือกี่วัน ซึ่งผลที่ตามมาคือ โปรเจคพัง ส่งมอบช้า หรือแม้แต่ส่งมอบไม่ได้ หรือ ส่งมอบแบบเพื่อให้เสร็จทันกำหนด โดยตัดส่วนที่ไม่จำเป็นออกไป ซึ่งการทำให้มีคุณภาพ ก็อาจจะถูกตัดออกไปด้วยในเวลาเดียวกัน

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

ถ้าอย่างนั้นเราจะทำยังไงดีล่ะ ในเมื่อ Business ก็ต้องการคำตอบ

Story Point เกิดขึ้นมาเพื่ออำพลางความคิดของฝั่ง Business ว่าต้องใช้กี่ชั่วโมง แต่เป็นการให้สัญญาณ เป็นลักษณะของ การประเมินความเสี่ยง แทน ว่าทีมคิดว่ามีความเสี่ยงอย่างไรบ้างที่จะส่งมอบงานไม่ได้ ดังนั้น Story Point จึงถูกประเมินด้วย ภาระงานที่ทำ, ความซับซ้อนของงาน, และความเสี่ยง แทนที่จะเป็นจำนวนชั่วโมงทำงาน

และนั่นเป็นสาเหตุเช่นกันว่า ทำไมเราถึงให้ Story Point เป็นเลข Fibonacci เพราะเราพยายามจะสร้างความซับซ้อนให้คนเลิกเอาไปเปรียบเทียบกับจำนวนชั่วโมงที่ใช้พัฒนาซะ ก็คือ ทำให้มันไม่สามารถเอามาเปรียบเทียบกันได้ซะ

สิ่งที่เราบอกได้ ไม่ใช่การให้คำมั่นว่า งานเสร็จภายใน Sprint หน้าแน่นอน อ้าว ก็ Story Point มันเท่ากันนี่นา มันก็ควรจะเสร็จสิ ….. ไม่ใช่

สิ่งที่เราบอกได้คือ ระดับของความเสี่ยง ที่สามารถส่งมอบงานได้ (Confident Level) นั้นอยู่ในระดับที่เสี่ยงต่ำมาก และเชื่อว่าจะทำงานเสร็จสมบูรณ์ได้

ตัวอย่าง

/– ทีมพัฒนานึงมีการพัฒนาผ่านไปแล้ว 100 Sprints โดยที่มีค่าเฉลี่ยของ Story Points ที่ส่งมอบได้ อยู่ที่ 20 Story Points –/

ข้อความข้างต้นไม่ได้บอกอะไรเกี่ยวกับ Sprint ถัดไป บอกได้แค่ว่า ทีมนี้ “มีความสามารถ” และมีความเชื่อมั่น ทำให้ส่งมอบงานชิ้นนี้ได้ (ไม่เกี่ยวว่า Story Points เท่าไหร่)

ในกรณีที่ Sprint ถัดไป มี 20 Points อีก จากข้อความข้างต้น อาจจะเอามาบอกอะไรไม่ได้เลย เดี๋ยวมาคุยกันว่าทำไม

ปรากฏว่าทีมพัฒนานี้ Sprint แรก มีการแตก Story เป็น 10 Stories แบ่งเป็นคะแนนตามนี้ 1,2,3,1,2,3,1,2,3,2 ก็สามารถบอกได้ว่า โอเค 20 Story Points นี้ มีความเสี่ยงต่ำที่จะส่งมอบงานไม่ได้ เพราะ Story ได้ถูกแตกออกมาเป็นชิ้นเล็กชิ้นน้อยแล้ว งานชัดเจนมากว่าจะต้องทำอะไร

แต่….. เราไม่ควรบอกว่า เฮ้… แน่นอน เราส่งมอบงานได้. แต่ควรจะเป็น รอบนี้มีความเสี่ยงต่ำมากที่จะส่งมอบงานไม่ได้

ปรากฏว่า ในอีก Sprint นึง ทีมพัฒนานี้ มีการประเมิน 20 Story Points แต่เป็น Story 2 Story คือ 7,13 คะแนน อาจจะบอกได้ว่า เรามีความเสี่ยงสูง คือ งานที่ Story Points ขนาดใหญ่ มีความเสี่ยง จากความซับซ้อนของงาน ดังนั้น การให้คำสัญญา คือการบอกได้ว่า โอเค รอบนี้เราประเมินงานมาจำนวนเท่ากับ Sprint ก่อน โดยที่ทีมมีความเสี่ยงอยู่ที่ Story A ซึ่งมี 13 Points อาจจะมีความซับซ้อนอันทำให้ปิด Sprint โดยที่งานไม่เสร็จได้ ซึ่งตรงนี้ ยิ่งเลขมาก มันก็คือยิ่งมีความเสี่ยงสูงนั่นเอง สิ่งที่ทำได้คือ การทำแตก Story ออกมาให้มีขนาดเล็กลง หรือ การประเมินว่า ตรงจุดใดที่มีความไม่มั่นใจ

ด้วยเหตุนี้เอง การประเมินว่า Sprint ถัดไปส่งมอบอะไรได้บ้าง จะต้องแนบไปกับ Message เรื่องของ Confident Level, Risk Level จากทีมเสมอ แทนที่จะบอกว่า Story ทั้งหมดนี้เสร็จใน Sprint หน้า อันถือว่าเป็นความอันตราย ไม่ใช่แค่ต่อทีมเท่านั้น แต่ Business อาจจะไป Commit ต่ออีกทอดนึงจนลืมไปว่ามีความเสี่ยงตรงไหนที่อาจจะทำให้ส่งมอบไม่ได้หรือเปล่า ในบางบริษัท ก็อาจจะแก้ไขแบบคลื่นใต้น้ำคือ Developer ก็ทำงาน OT กันไป จนตัวพัง ลาออกหายไป แต่โดยมาก ท่าง่าย ก็เพียงแค่ลดคุณภาพ ทำพอเสร็จใช้งานได้ ส่งออกไปให้ใช้งาน

ผู้อ่าน อ่านแล้วคิดเห็นยังไงครับ คิดว่าจริงๆ แล้วควรจะ Commit ได้เลยหรือเปล่าว่า Sprint ถัดไปจะส่งมอบอะไรได้บ้าง หรืออะไรที่ขาดหายไปจากสิ่งที่เขียนนี้