Scrum Guide | 31. จะสร้างและตีความแผนภูมิเบิร์นดาวน์ได้อย่างไร?

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

จะสร้างและตีความแผนภูมิเบิร์นดาวน์ได้อย่างไร? – สารบัญ:

1. จะสร้างแผนภูมิการเบิร์นดาวน์ได้อย่างไร?
2. ใครเป็นผู้รับผิดชอบแผนภูมิการเบิร์นดาวน์?
3. จะตีความแผนภูมิการเบิร์นดาวน์ได้อย่างไร
4. แผนภูมิการเบิร์นดาวน์ที่แท้จริงและเหมาะสม
5. การเลือกหน่วยวัด
6. สรุป

จะสร้างแผนภูมิการเบิร์นดาวน์ได้อย่างไร?

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

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

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

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

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

ใครเป็นผู้รับผิดชอบแผนภูมิการเบิร์นดาวน์?

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

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

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

จะตีความแผนภูมิการเบิร์นดาวน์ได้อย่างไร

เราได้อธิบายลักษณะที่ปรากฏของกราฟการเบิร์นดาวน์โดยละเอียดในบทความที่แล้ว ที่นี่เราจะเตือนคุณว่า แกน X แสดงเวลาที่เหลือในการทำงานให้เสร็จ ในทางกลับกัน แกน Y จะแสดงจำนวนงานที่เหลืออยู่ที่ต้องทำ

แผนภูมิการเบิร์นดาวน์ที่แท้จริงและเหมาะสม

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

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

กราฟเบิร์น ยังช่วยให้คุณกำหนดค่าที่เรียกว่า Development Team Velocity ได้ในระยะยาว เราจะอุทิศบทความแยกต่างหากให้กับมัน ที่นี่เราจะพูดถึงว่าเป็นค่าที่กำหนดโดยปริมาณงานที่ทำในหนึ่ง Sprint

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

การเลือกหน่วยวัด

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

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

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

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

สรุป

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

หากคุณชอบเนื้อหาของเรา เข้าร่วมชุมชนผึ้งที่วุ่นวายบน 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 สินค้า