Scrum Guide | 34. Velocity in Scrum – ความเร็วของทีมพัฒนา

ความเร็วใน Scrum ช่วยให้คุณกำหนดอัตราที่ทีม Scrum ทำงานให้เสร็จสิ้น เราสามารถกำหนดเป็นจำนวนเฉลี่ยของ Story Points ที่เสร็จสิ้นใน Sprint เดียว ความเร็วยังสามารถประมาณระยะเวลาของโครงการตามความคืบหน้าของงานที่เสร็จสมบูรณ์แล้ว อย่างไรก็ตาม สิ่งนี้เหมาะสมสำหรับทีมที่เป็นผู้ใหญ่ที่ทำงานด้วยความเร็วที่สม่ำเสมอและสม่ำเสมอเท่านั้น มาดูกันว่า Velocity คืออะไรและจะทำให้ดีที่สุดสำหรับคุณได้อย่างไร!

ความเร็วใน Scrum – สารบัญ:

1. ความเร็วในการต่อสู้ – บทนำ
2. ความเร็วจริงและความเร็วที่วางแผนไว้
3. ความยากและความเสี่ยงที่เกี่ยวข้องกับ Velocity ใน Scrum
4. สรุป

ความเร็วในการต่อสู้ – บทนำ

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

Velocity of the Development Team มักถูกนำเสนอในรูปแบบของแผนภูมิความเร็ว บนแกน X จะมีการทำเครื่องหมาย Sprints ที่ต่อเนื่องกัน ในทางกลับกัน ในแกน Y เราจะพบจำนวน Story Points หรือหน่วยที่เกี่ยวข้องอื่นๆ ที่เสร็จสิ้นใน Sprint ที่กำหนด ด้วยแผนภูมิความเร็ว ทีม Scrum จะได้รับมุมมองที่ชัดเจนเกี่ยวกับการเปลี่ยนแปลงในจังหวะการทำงาน หากเส้นที่ทำเครื่องหมายไว้บนแผนภูมิเพิ่มขึ้น แสดงว่าทีมกำลังเพิ่มประสิทธิภาพหรือลดค่าคะแนนเนื้อเรื่อง ดังนั้น ทั้ง Scrum Master และ Product Owner จึงควรปฏิบัติตามบรรทัดที่แสดงความเร็วของทีมอย่างระมัดระวัง

ความเร็วจริงและความเร็วที่วางแผนไว้

ความเร็วที่แท้จริง ของทีมพัฒนาจะอธิบายความเร็วของงานใน Sprint ที่เสร็จสมบูรณ์และคำนวณเมื่อสิ้นสุด Sprint แต่ละรายการ จะใช้มูลค่ารวมของ Story Points สำหรับ User Stories ที่เสร็จสมบูรณ์ทั้งหมด ความเร็วที่แท้จริงของทีมพัฒนาช่วยให้คุณวางแผนและประเมินด้วยความน่าจะเป็นของงานในอนาคต

ในทางกลับกัน Velocity ที่วางแผนไว้ นั้นถูกประเมินตามค่าเฉลี่ยของ Velocity จริง มันต้องมีการสันนิษฐานว่าไม่มีการเปลี่ยนแปลงในทีมพัฒนา เป็นเครื่องมือภายในที่สำคัญสำหรับทีมพัฒนา ซึ่งสามารถประเมินได้ว่าความร่วมมือในทีมเป็นไปด้วยดีหรือไม่ และการรักษาระดับความเร็วของงานไว้หรือไม่

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

ความยากและความเสี่ยงที่เกี่ยวข้องกับ Velocity ใน Scrum

Velocity in Scrum มักให้ความสำคัญมากเกินไปโดยไม่คำนึงถึงปัจจัยต่อไปนี้:

• การประมาณค่าโดยรวมที่ใหญ่กว่าหรือทั้งโครงการ – ในขณะที่ทีมพัฒนาสามารถประมาณจำนวน Story Points ที่จะมอบหมายให้กับงานเฉพาะได้อย่างแม่นยำ เป็นเรื่องยากหรือเป็นไปไม่ได้ที่จะอธิบายภาพรวมที่ใหญ่ขึ้นสำหรับการนำไปใช้ในอนาคตในหน่วยเหล่านี้
• การเปลี่ยนแปลงในโครงการ – การเปลี่ยนแปลงใดๆ ในโครงการอาจหมายถึงการเปลี่ยนแปลงจำนวน Story Points ที่จำเป็นเพื่อให้บรรลุเป้าหมายผลิตภัณฑ์ อาจเป็นไปได้ว่างานที่ทำเสร็จแล้วจะต้องได้รับการแก้ไขหรือแม้กระทั่งไม่ได้ใช้ในเวอร์ชันสุดท้ายของ Product
• เหตุการณ์ที่ไม่คาดฝัน – การคาดคะเนความเร็วของโครงการในอนาคตโดยพิจารณาจากเหตุการณ์ที่เสร็จสิ้นไปแล้ว กล่าวคือ การแปลความเร็วจริงเป็นความเร็วตามแผน อาจส่งผลให้มีการประมาณการที่แม่นยำ อย่างไรก็ตาม แต่ละโปรเจ็กต์มีลักษณะเฉพาะของตัวเอง และการคาดการณ์ที่แม่นยำตามประวัติมักจะเป็นไปไม่ได้

สรุป

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

Velocity in Scrum มีประโยชน์อย่างมากในเบื้องต้นเนื่องจากเป็นการวัดภายในที่ทีมพัฒนาใช้เพื่อ ประเมินความเร็วของงาน เนื่องจากช่วยให้สามารถกำหนดจำนวนงานที่สามารถทำได้ระหว่าง Sprint เดียว

ความเร็วที่อยู่ในมือของ Product Owner กลายเป็นเครื่องมือที่มีประโยชน์สำหรับ การประมาณเส้นตายสำหรับงานที่ใหญ่ขึ้น

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

หากคุณชอบเนื้อหาของเรา เข้าร่วมชุมชนผึ้งที่วุ่นวายบน Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest

ผู้เขียน: แคโรไลน์ เบ็คเกอร์

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

ดูกระทู้ทั้งหมด

คู่มือการต่อสู้:

1. อภิธานศัพท์ของคำศัพท์พื้นฐาน บทบาท และแนวคิด
2. Scrum คืออะไร?
3. ค่าการต่อสู้
4. วิธีใช้งาน Scrum ในบริษัทของคุณ
5. Scrum Team - มันคืออะไรและทำงานอย่างไร?
6. เจ้าของผลิตภัณฑ์คือใคร?
7. ข้อผิดพลาดที่พบบ่อยที่สุดของ Product Owner
8. Scrum Master คือใคร?
9. ลักษณะของ Scrum Master ที่ดี
10. ข้อผิดพลาดที่พบบ่อยที่สุดของ Scrum Master
11. สถิติและตัวชี้วัดใดที่ Scrum Master ควรติดตาม
12. ความร่วมมือระหว่าง Product Owner และ Scrum Master
13. ทีมพัฒนาใน Scrum
14. ข้อผิดพลาดที่พบบ่อยที่สุดของ Developers
15. สิ่งประดิษฐ์การต่อสู้
16. สเกลการต่อสู้
17. Sprint Backlog
18. Backlog สินค้าคืออะไร?
19. เรื่องราวของผู้ใช้คืออะไร?
20. สร้าง User Story ที่ดีที่สุดกับ INVEST
21. ข้อผิดพลาด User Story ที่พบบ่อยที่สุด
22. เกณฑ์การยอมรับเรื่องราวของผู้ใช้
23. การประมาณค่าและจุดเรื่องราวใน Scrum
24. การวางแผนโป๊กเกอร์
25. เกมประเมินทีม
26. กำหนดส่วนเพิ่ม
27. เหตุการณ์การต่อสู้
28. Sprint ใน Scrum คืออะไร?
29. ความมุ่งมั่นของทีม Scrum - เป้าหมายผลิตภัณฑ์ เป้าหมาย Sprint และคำจำกัดความของความสำเร็จ
30. แผนภูมิ Burndown คืออะไร?
31. จะสร้างและตีความแผนภูมิเบิร์นดาวน์ได้อย่างไร?
32. ข้อดีและข้อเสียของแผนภูมิการเบิร์นดาวน์
33. กระดาน Kanban ใน Scrum และ Scruban
34. Velocity in Scrum - ความเร็วของทีมพัฒนา
35. การต่อสู้รายวัน
36. การวางแผนการวิ่ง
37. Sprint Review
38. Sprint Retrospective คืออะไร?
39. ข้อผิดพลาดทั่วไประหว่าง Sprint Retrospective
40. บำรุง Backlog สินค้า