Scrum Guide | 35. การต่อสู้รายวัน

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

Daily Scrum – สารบัญ:

1. บทนำ
2. สูตร Daily Scrum
3. ปัญหาเกี่ยวกับ Daily Scrum และวิธี 5W
4. คำถามสนับสนุน
5. 5 ทำไม
6. สรุป

บทนำ

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

สูตร Daily Scrum

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

Daily Scrum ที่ดำเนินการอย่างดีควรให้ผู้เข้าร่วมแต่ละคนตอบ คำถามสองข้อ :

• งานที่สำคัญที่สุดที่ฉันจะทำในวันนี้คืออะไร?
• อะไรคืออุปสรรคในการทำภารกิจนี้ให้สำเร็จ?

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

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

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

ปัญหาเกี่ยวกับ Daily Scrum และวิธี 5W

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

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

คำถามสนับสนุน

หากทีมไม่ได้รับประโยชน์จาก Daily Scrum Scrum Master สามารถช่วยนักพัฒนาระบุปัญหาได้โดยการสังเกตการประชุมเพื่อหาคำตอบสำหรับคำถามต่อไปนี้:

5 ทำไม

หลังจากการระบุปัญหาเบื้องต้นแล้ว เทคนิคที่มีประสิทธิภาพในการระบุสาเหตุของปัญหาอาจเป็น วิธี 5 ทำไม หรือที่เรียกว่า 5 Whys หรือ 5W โดย Sakichi Toyoda มันเกี่ยวข้องกับการถามหลายครั้งว่า “ทำไม” คำถามในแถว ทำให้สามารถวินิจฉัยสาเหตุของปัญหาที่ลึกกว่า และแก้ไขได้ง่ายขึ้น

ตัวอย่างเช่น มาดูรายการสุดท้ายในตาราง: ปัญหาที่เกิดขึ้นในด้านความมุ่งมั่นในการแก้ปัญหาโดยทีมพัฒนา คำถามห้าข้ออาจมีลักษณะดังนี้:

1 x ทำไม?

ถาม: เหตุใดนักพัฒนาจึงไม่เสนอวิธีต่างๆ ในการแก้ปัญหาที่เกิดขึ้น

ตอบ: เนื่องจากแฮรี่นักพัฒนาซอฟต์แวร์เป็นคนแรกที่เสนอวิธีแก้ปัญหา

2 x ทำไม?

ถาม: เหตุใดแฮรี่ผู้พัฒนาจึงเป็นคนแรกที่เสนอโซลูชันเดียวเสมอ

ตอบ: เพราะไม่มีใครพูด

3 x ทำไม?

ถาม: ทำไมไม่มีใครพูดถึง?

ตอบ: เนื่องจากผู้พัฒนารายอื่นไม่ต้องการหาวิธีแก้ปัญหาที่ดีกว่า

4 x ทำไม?

ถาม: เหตุใดผู้พัฒนารายอื่นจึงไม่รู้สึกว่าต้องการหาวิธีแก้ปัญหาที่ดีกว่า

ตอบ: เนื่องจากการหาวิธีแก้ปัญหาต้องมีสมาธิและการพิจารณาวิธีแก้ปัญหาของ Harry นั้นดีเพียงพอจึงง่ายกว่า

5 x ทำไม?

ถาม: ทำไมพวกเขาถึงคิดว่าวิธีแก้ปัญหาของแฮร์รี่ดีพอ

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

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

สรุป

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

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