Scrum Guide | 16. การต่อสู้แบบสเกล

Scrum Team ควรประกอบด้วยคนไม่เกินสิบคน แต่จะทำอย่างไรเมื่อผู้เชี่ยวชาญกลุ่มใหญ่ต้องทำงานในโครงการเดียว หรือหากองค์กรตัดสินใจที่จะปฏิบัติตามวิธีการจัดการที่คล่องตัว? เพื่อแก้ปัญหานี้ นักพัฒนา Scrum ได้เสนอ [email protected] ซึ่งเป็นสถาปัตยกรรมที่ไม่ต้องปรับขนาดเพื่อจัดระเบียบทั้งทีมตามหลักการของ Scrum

Scaling Scrum – สารบัญ:

1. บทนำ
2. [ป้องกันอีเมล]
3. การต่อสู้ของ Scrums
4. ปัญหาการปรับขนาดเพิ่มเติมและ [ป้องกันอีเมล]
5. สรุป

บทนำ

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

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

องค์กรส่วนใหญ่ที่นำวิธีการจัดการแบบ Agile มาใช้ในวงกว้าง เลือกใช้แบบจำลอง SAFE หรือ Scaled Agile Framework อย่างไรก็ตาม วันนี้ เราจะไม่เน้นที่ SAFE แต่เราจะพูดถึงรูปแบบอื่นที่เรียกว่า [email protected] ตามรายงาน State of Agile ฉบับที่ 15 ของปี 2021 เป็นตัวเลือกที่ดีที่สุดอันดับสองในบรรดาธุรกิจที่เลือกใช้ Agile

[ป้องกันอีเมล]

ในปี 1996 ผู้สร้าง Scrum, Jeff Sutherland และ Ken Schwaber กำลังทำงานในโครงการขนาดใหญ่ ขณะที่พวกเขากำลังทำอยู่ พวกเขาประสบปัญหาในการทำให้ทีมเล็กๆ ทำงานใน Scrum ซิงค์กัน พวกเขาคิดหาวิธีขยายขนาด ซึ่งในที่สุดพวกเขาก็เรียกว่า [ป้องกันอีเมล]

คล้ายกับ Scrum Guide อย่างเป็นทางการคือ [email protected] Guide ซึ่งกำหนดวิธีการปรับขนาดเป็น:

กรอบงานภายในที่เครือข่ายของ Scrum Teams ดำเนินการตาม Scrum Guide เพื่อแก้ปัญหาการปรับตัวที่ซับซ้อนและส่งมอบผลิตภัณฑ์อย่างสร้างสรรค์โดยมีมูลค่ามากที่สุด

หลักฐานพื้นฐานของ [ป้องกันอีเมล] คือความเรียบง่ายและมีประสิทธิภาพ ดังนั้น การดำเนินงานจะขึ้นอยู่กับ สถาปัตยกรรมแบบไม่มีขนาด กล่าวอีกนัยหนึ่งคือใช้ Scrum เพื่อปรับขนาด Scrum ด้วยวิธีนี้ ทีม scrum ที่ประกอบด้วยบุคคลที่ทำหน้าที่เป็น Product Owner, Scrum Master หรือ Developer จะกลายเป็น Scrum of Scrums: ทีมที่ประกอบด้วยทีม

การต่อสู้ของ Scrums

Scrum of Scrums คือทีม scrum ที่มีผู้คนสวมบทบาท Scrum แบบเดิมๆ อย่างไรก็ตาม เนื่องจากงานของ Scrum of Scrums คือการผสานรวมผลงานของ Scrum Teams หลายๆ ทีม จึงต้องมีการโพสต์เพิ่มเติม:

• Product Owner Team – กลุ่ม Product Owners ที่พบกันเพื่อตกลงเรื่องลำดับความสำคัญและสร้างวิสัยทัศน์ของผลิตภัณฑ์ที่เหนียวแน่น
• Chief Product Owner – เจ้าของผลิตภัณฑ์ของ Scrum Team หรือบุคคลที่เกี่ยวข้องกับ Scrum of Scrums เท่านั้น
• Scrum of Scrums Master – บุคคลที่ดูแลประสิทธิภาพของ Scrum of Scrums

พวกเขาพบกันที่ Scrum Events เดียวกันและใช้สิ่งประดิษฐ์ที่คล้ายกัน

ปัญหาการปรับขนาดเพิ่มเติมและ [ป้องกันอีเมล]

สถาปัตยกรรมแบบไม่มีสเกลของ [ป้องกันอีเมล] หมายความ ว่าสามารถปรับขนาดได้มากกว่าเพียงครั้งเดียว หากองค์กรต้องการประสานงานทีมในระดับที่ใหญ่ขึ้น ก็สามารถตั้งค่า Scrum of Scrums ได้

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

Scaling Scrum – สรุป

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

หากองค์กรเลือกที่จะเสริม Scrum จะได้รับสถาปัตยกรรมที่ปราศจากขนาดที่สามารถเพิ่มได้สำเร็จเพิ่มเติม อย่างไรก็ตาม การเพิ่มแต่ละครั้งจะมาพร้อมกับระดับความซับซ้อนที่เพิ่มขึ้นซึ่งทีม Product Owner, Chief Product Owner และ Scrum of Scrums Master ต้องจัดการด้วย

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