สตอรี่พอยต์ในการพัฒนา — คืออะไร มาตราส่วนการประเมินและการประยุกต์ใช้

สตอรี่พอยต์คืออะไร

สตอรี่พอยต์ เป็นเมตริกความซับซ้อนของงานที่ใช้ใน Scrum และวิธีการคล่องตัวอื่นๆ ทีมประเมินแต่ละงานไม่ใช่เป็นชั่วโมง แต่เป็นหน่วยสัมพัทธ์: “งานนี้ซับซ้อนเป็นสองเท่าของงานอ้างอิง” แนวทางนี้ช่วยลดความแตกต่างของความเร็วระหว่างนักพัฒนาต่างๆ และมุ่งเน้นที่ความซับซ้อน

ที่มาของคำศัพท์

แนวคิดของ สตอรี่พอยต์ เกิดขึ้นในช่วงต้นทศวรรษ 2000 พร้อมกับความนิยมของ Scrum หนึ่งในคนแรกๆ ที่อธิบายวิธีการนี้คือ Ron Jeffries ซึ่งเป็นส่วนหนึ่งของ Extreme Programming (XP) แนวคิดคือการย้ายออกจากการประเมินในรูปแบบ “ชั่วโมงทำงาน” ซึ่งมักจะไม่แม่นยำ ไปสู่ความซับซ้อนเชิงสัมพัทธ์ที่ทีมกำหนดร่วมกัน ปัจจุบัน สตอรี่พอยต์เป็นมาตรฐานอุตสาหกรรมสำหรับทีมคล่องตัว

ปัจจัยที่พิจารณาในสตอรี่พอยต์

เมื่อประเมินด้วย สตอรี่พอยต์ ทีมพิจารณาปัจจัยสามประการ: ปริมาณงาน (ปริมาณโค้ด หน้าจอ ตรรกะ) ความซับซ้อน (ความท้าทายทางเทคนิค เทคโนโลยีใหม่) และความไม่แน่นอน (ความต้องการที่ไม่ชัดเจน ความเสี่ยง) หนึ่งสตอรี่พอยต์อาจหมายถึง “งานง่ายที่ไม่มีความเสี่ยง” ในขณะที่ 8 อาจหมายถึง “งานซับซ้อนที่มีความไม่แน่นอนสูง”

มาตราส่วนสตอรี่พอยต์: วิธีเลือก

การเลือก มาตราส่วนสตอรี่พอยต์ ส่งผลต่อความแม่นยำของการประเมินและความสะดวกในการวางแผน มาตราส่วนที่นิยมมากที่สุดคือลำดับฟีโบนัชชี แต่ก็มีทางเลือกอื่นๆ

ทำไมต้องฟีโบนัชชี? จิตวิทยาของมาตราส่วน

ลำดับฟีโบนัชชี ไม่ได้ถูกเลือกโดยบังเอิญ ความแตกต่างระหว่าง 1 และ 2 น้อยมาก (50%) ในขณะที่ระหว่าง 13 และ 21 มีนัยสำคัญ (62%) สิ่งนี้สะท้อนความเป็นจริง: งานเล็กได้รับการประเมินแม่นยำกว่า งานใหญ่มีการกระจายตัวมากกว่า เมื่องานถูกประเมินที่ 21 สตอรี่พอยต์ ทีมเข้าใจว่า: “เราไม่รู้ว่าจะใช้เวลาเท่าไหร่ แต่มันมากกว่า 13 แน่นอน” มาตราส่วนฟีโบนัชชีป้องกันความแม่นยำที่ผิดพลาด

งานอ้างอิง — พื้นฐานของมาตราส่วน

เพื่อให้มาตราส่วนทำงาน ทีมตกลงเกี่ยวกับ งานอ้างอิง: “งาน X คือ 1 สตอรี่พอยต์” โดยทั่วไปจะเลือกงานที่ง่ายและคุ้นเคยเป็นงานอ้างอิง เช่น “เพิ่มฟิลด์ข้อความบนหน้าจอ” หรือ “แก้ไขบั๊กพิมพ์ผิด” งานอื่นๆ ทั้งหมดจะถูกประเมินโดยเทียบกับงานอ้างอิง หากไม่มีงานอ้างอิง สตอรี่พอยต์จะสูญเสียความหมาย — แต่ละคนเข้าใจหน่วยแตกต่างกัน

ความเร็วของทีมและการพยากรณ์

ความเร็ว (Velocity) คือจำนวนเฉลี่ยของสตอรี่พอยต์ที่ทีมทำให้เสร็จต่อสปรินต์ นี่คือเมตริกหลักสำหรับการพยากรณ์กำหนดการของโครงการ

วิธีคำนวณความเร็ว

ความเร็ว คำนวณจากงานที่เสร็จสมบูรณ์: รวมสตอรี่พอยต์ของงานทั้งหมดที่ทีมทำให้เสร็จ (ตรงตามนิยามของความสำเร็จ) งานที่ยังไม่เสร็จจะไม่นับรวม เพื่อความแม่นยำ ให้ใช้ค่าเฉลี่ยของ 3-5 สปรินต์ล่าสุด ตัวอย่างเช่น ถ้าทีมทำสตอรี่พอยต์เสร็จ 20, 22, 18 และ 24 ใน 4 สปรินต์ล่าสุด ความเร็ว = 21 ส‌ต

การพยากรณ์ผ่านความเร็ว

การทราบ ความเร็ว และปริมาณรวมของแบ็คล็อกในสตอรี่พอยต์ คุณสามารถพยากรณ์จำนวนสปรินต์จนถึงการเผยแพร่ได้ ตัวอย่างเช่น ถ้าแบ็คล็อกมี 210 สตอรี่พอยต์และความเร็ว = 21 จะต้องใช้ 10 สปรินต์ นี่คือการพยากรณ์คร่าวๆ ที่จะปรับปรุงเมื่องานดำเนินไป สำคัญ: ความเร็วคือค่าเฉลี่ย ไม่ใช่ข้อผูกมัด วางแผนโดยใช้ขอบเขตล่าง (18 ส‌ต) แทนที่จะใช้ค่าเฉลี่ย

วิธีเพิ่มความเร็ว

ความเร็ว ไม่สามารถเพิ่มได้ด้วยคำสั่ง — มันเป็นอาการของสุขภาพของกระบวนการ การเติบโตของความเร็วอย่างยั่งยืนทำได้โดย: ลดหนี้ทางเทคนิค ปรับปรุงกระบวนการตรวจสอบโค้ด ลดการสลับบริบท ทำให้การทดสอบและ CI/CD เป็นอัตโนมัติ สำคัญ: ไม่สามารถเปรียบเทียบความเร็วของทีมต่างๆ ได้ — แต่ละทีมกำหนดสตอรี่พอยต์ในแบบของตนเอง

สตอรี่พอยต์เทียบกับชั่วโมง: อะไรและเมื่อใดควรใช้

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

เมื่อใดสตอรี่พอยต์ทำงานได้ดีกว่า

สตอรี่พอยต์ ขาดไม่ได้สำหรับการวางแผนสปรินต์: พวกมันไม่ขึ้นอยู่กับว่าใครจะเป็นคนทำงาน จูเนียร์อาจทำ 2 ส‌ตต่อวัน ซีเนียร์ทำ 4 ส‌ต แต่การประเมินงานยังคงเป็น 2 ส‌ตสำหรับทั้งสองคน สตอรี่พอยต์ช่วยให้ติดตามประสิทธิภาพของทีมโดยไม่ต้องเปรียบเทียบนักพัฒนา ซึ่งช่วยลดแรงกดดันทางการเมืองและปรับปรุงบรรยากาศในทีม

เมื่อใดจำเป็นต้องใช้ชั่วโมง

ชั่วโมง จำเป็นสำหรับข้อผูกมัดภายนอก: สัญญา งบประมาณ รายงานลูกค้า ลูกค้าต้องการรู้ไม่ใช่ “8 สตอรี่พอยต์” แต่เป็น “3 สัปดาห์” ในการแปลงสตอรี่พอยต์เป็นชั่วโมง ให้ใช้อัตราการแปลงในอดีต: ทีมรู้ว่า 1 ส‌ต เท่ากับประมาณ 4 ชั่วโมงทำงาน การแปลงควรโปร่งใสและขับเคลื่อนด้วยข้อมูล ไม่ใช่การเดา

แนวทางแบบผสมผสาน

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

ข้อผิดพลาดทั่วไปในการทำงานกับสตอรี่พอยต์

การนำสตอรี่พอยต์มาใช้อมักมาพร้อมกับข้อผิดพลาดที่ทำให้ข้อดีของการประเมินแบบสัมพัทธ์สูญเปล่า ต่อไปนี้คือข้อผิดพลาดที่พบบ่อยที่สุด

การผูกสตอรี่พอยต์กับเวลา

ข้อผิดพลาดที่พบบ่อยที่สุด — ทีมตกลงกัน: “1 ส‌ต = 4 ชั่วโมง” ในกรณีนี้ สตอรี่พอยต์สูญเสียความหมายและกลายเป็นชั่วโมงในชื่ออื่น สตอรี่พอยต์ควรเป็นแบบสัมพัทธ์ ไม่ยึดติดกับเวลา ถ้างาน A ซับซ้อนเป็นสองเท่าของงาน B มันจะได้รับ 2 ส‌ต ไม่ว่าจะใช้เวลากี่ชั่วโมงก็ตาม

การประเมินหลังเสร็จสิ้น

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

การเปรียบเทียบความเร็วระหว่างทีม

การเปรียบเทียบความเร็ว ของทีม A และทีม B เป็นการกระทำที่ไร้ความหมาย แต่ละทีมกำหนดงานอ้างอิงและมาตราส่วนแตกต่างกัน สำหรับทีมหนึ่ง 1 ส‌ต คืองานง่ายหนึ่งชั่วโมง สำหรับอีกทีมหนึ่ง คืองานหนึ่งวัน คุณสามารถเปรียบเทียบได้เฉพาะความเร็วของทีมเดียวกันเมื่อเวลาผ่านไป: ว่ามันเพิ่มขึ้นหรือลดลง

มาตราส่วนที่ไม่สอดคล้องกัน

เมื่องาน ที่แตกต่างกัน มีความซับซ้อนเท่ากันได้รับสตอรี่พอยต์ต่างกัน และงานที่ซับซ้อนกว่าได้รับพอยต์น้อยกว่า มาตราส่วนก็จะพัง ทีมควรปรับเทียบมาตราส่วนอย่างสม่ำเสมอ: ทุก 3-6 สปรินต์ ทบทวนย้อนหลังว่าการประเมินสอดคล้องกับความซับซ้อนจริงมากน้อยเพียงใด สิ่งนี้ช่วยปรับปรุงความสอดคล้องของการประเมิน