Scrum Guide | 25. เกมประเมินทีม
เผยแพร่แล้ว: 2022-05-28เกมการประเมินทีมเป็นเทคนิคที่อำนวยความสะดวกในการวางแผน Sprint ใน Scrum แตกต่างจาก Planning Poker อย่างไร? เหตุใดทีมพัฒนาบางทีมจึงพบว่าเครื่องมือนี้มีประสิทธิภาพมากกว่าและบางทีมไม่ทำ คุณจะพบทุกสิ่งที่คุณจำเป็นต้องรู้เกี่ยวกับเรื่องนี้ในบทความต่อไปนี้
เกมประเมินทีม – สารบัญ:
- บทนำ
- กฎของเกมการประเมินทีม
- เกมประเมินทีมกับโป๊กเกอร์วางแผน
- สรุป
บทนำ
เกมการประเมินทีมเรียกอีกอย่างว่าการประมาณการว่ายน้ำ ระยะหลังเกิดขึ้นจากการสังเกตเกมไพ่โดยธรรมชาติเนื่องจากการแสดงไพ่คล้ายกับช่องทางว่ายน้ำของแอ่งน้ำ
เกมการประเมินทีมได้รับความนิยมอย่างต่อเนื่อง เนื่องจากช่วยให้ทีมพัฒนาสร้างการประมาณได้เร็วกว่าการใช้ Planning Poker ถึง 3 เท่า
เราเขียนเกี่ยวกับเทคนิคนี้ในบทความที่แล้ว วันนี้มาเน้นที่เกมการประเมินทีมกัน
กฎของเกมการประเมินทีม
เกมการประเมินทีมพร้อมท์:
- สำรับการ์ด User Story - จัดทำแยกต่างหากสำหรับแต่ละเกม
- สำรับไพ่ Story Point – สำหรับการใช้งานซ้ำ
ขั้นแรก ให้ซ้อนการ์ด User Stories ตามลำดับที่ตรงกับรายการใน Product Backlog เพื่อให้แน่ใจว่าสิ่งที่เร่งด่วนที่สุดได้รับการประเมินก่อน
บัตรให้คะแนนมักจะมีค่าที่สอดคล้องกับ ลำดับฟีโบนักชี นี่คือลำดับของตัวเลขต่อไปนี้: 0, 1, 3, 5, 8, 13, 20, 40 และ 100 คุณยังสามารถติดป้ายกำกับด้วยเลขยกกำลังที่ต่อเนื่องกันของเลข 2 นั่นคือ 2, 4, 8, 16,32 และอื่นๆ
ขั้นตอนของเกมการประเมินทีม:
- บทนำ. ในการเล่นเกมการประเมินทีม สมาชิกทีม Scrum จะนั่งรอบโต๊ะ Product Owner เริ่มต้นด้วยการจั่วการ์ดใบแรกจากเด็ค User Story และแชร์เนื้อหากับทุกคน จากนั้นไพ่จะอยู่บนโต๊ะ จากนั้น Product Owner จะอธิบายให้ทีม Scrum ที่เหลือฟังว่าต่อจากนี้ไป ผู้เล่นจะประเมิน User Stories ว่าง่ายหรือยากต่อการนำไปใช้โดย จัดวางตามนั้นทางด้านซ้ายและด้านขวา หากมีระดับความยากอยู่บ้าง ผู้เล่นจะเรียงซ้อนกัน กองหนึ่งวางทับกันบนโต๊ะ ตอนนี้ คนที่นั่งอยู่ข้างๆ ตามเข็มนาฬิกาจะขยับต่อไป
- ผู้เล่นจั่วการ์ดจากเด็ค User Story หลังจากแชร์เนื้อหากับทุกคนแล้ว ให้อธิบายสาระสำคัญแก่เจ้าของผลิตภัณฑ์ จากนั้นผู้ที่ถือการ์ดจะวางมันลงบนโต๊ะและเลือกที่นั่งตามความคิดเห็นของพวกเขาเกี่ยวกับความยากของเรื่องราวของผู้ใช้รายนี้ จากนั้น ผู้เล่นจะอธิบายเหตุผลที่อยู่เบื้องหลังการเลือกให้ทุกคนฟัง และผู้เล่นคนอื่นๆ สามารถถามคำถามเกี่ยวกับการใช้เหตุผลได้อย่างอิสระ พวกเขาไม่สามารถตั้งคำถามกับการตัดสินใจได้ แต่เป็นการโต้แย้งที่มีเหตุผลในการตัดสินใจ
- ตอนนี้ ผู้เล่นผลัดกัน และมีสองตัวเลือกให้เลือก:
- ทำซ้ำขั้นตอนที่ 2 หรือ
- ย้ายไพ่หนึ่งใบ บนโต๊ะไปยังตำแหน่งที่เหมาะสมที่สุด
- ขั้นตอนสุดท้ายของการวางการ์ด User Story จะเกิดขึ้นครั้งเดียวหรือหลายครั้ง ขึ้นอยู่กับการฝึกฝนของ Scrum Team ในรอบนี้ ผู้เล่นแต่ละคนยังมีโอกาสย้ายไพ่หนึ่งใบบนโต๊ะไปยังตำแหน่งที่เหมาะสมกว่า
- เมื่อผู้เล่นมอบหมายการ์ด User Story ทั้งหมดไปยังตำแหน่งที่แสดงถึงระดับความยาก ทีมพัฒนาจะย้ายไปจับคู่มูลค่าโดยมอบหมายการ์ดจากกอง Story Point การ์ด User Story ใบแรกทางด้านซ้ายจะได้รับการ์ด Story Point ที่มีคะแนนน้อยที่สุด โดย Product Owner กฎสำหรับการวางไพ่ใบต่อไปจะเหมือนกับคะแนน 3 และ 4 ซึ่งจะทำให้การประมาณเสร็จสมบูรณ์
หากพวกเขาเลือกทางเลือกที่สอง พวกเขาควร ปรับเหตุผลที่ทำให้พวกเขาเปลี่ยนใจ ผู้เล่นผลัดกันทำซ้ำขั้นตอนที่ 3 จนกว่าไพ่ทั้งหมดจากสำรับ User Story จะถูกแจกจ่ายและประมาณการ
เกมประเมินทีมกับโป๊กเกอร์วางแผน
เกมการประเมินทีมถือเป็นเครื่องมือการประมาณที่มีประสิทธิภาพมากกว่าการวางแผนโป๊กเกอร์ เนื่องจาก ความแตกต่าง ระหว่างสองเทคนิคนี้:
- การ์ดตาราง เกมการประเมินทีมใช้ "กฎโต๊ะไพ่" ที่รู้จักกันดีจากเกมไพ่ยอดนิยม ซึ่งหมายความว่าเมื่อคุณวางการ์ดแล้ว คุณจะไม่สามารถนำกลับมาได้ เนื่องจาก User Story ถูกประเมินทีละคน ความผันผวนระหว่างการประมาณค่าและจำนวนครั้งที่ตำแหน่งกะจะต่ำกว่าอย่างเห็นได้ชัด เมื่อเทียบกับ Planning Poker
- การคำนวณที่แม่นยำเพียงพอ ใน Planning Poker ควรมีข้อตกลงร่วมกันสำหรับ User Story แต่ละรายการ อย่างไรก็ตาม ในเกมการประเมินทีม มีเพียงคนเดียวเท่านั้นที่ตัดสินใจ แม้ว่าการประมาณการของเขา/เธอจะไม่ถูกต้อง นักพัฒนารายอื่นก็มีแนวโน้มจะวางให้ตรงกับมูลค่าของมันมากขึ้น วิธีนี้รับประกันว่าจะได้รับค่าประมาณที่ถูกต้องและรวดเร็วเพียงพอ
- หมดประเด็นการสนทนา ตัวเลือกการโต้เถียงมักจะยาวเกินไปเมื่อเล่น Planning Poker เวลาของพวกเขาลดลงอย่างมากในระหว่างเกมการประเมินทีมเพราะพวกเขามุ่งเน้นไปที่การตัดสินใจครั้งเดียวโดยหนึ่งในผู้พัฒนามากกว่าธรรมชาติของเรื่องราวของผู้ใช้แต่ละคน
ข้อเสียเปรียบประการหนึ่งของเกมการประเมินทีมคือ ความรู้สึกไม่ยุติธรรม หากทีมพัฒนามีมากกว่าจำนวน User Stories ที่กำหนดไว้ใน Sprint ที่กำหนด นักพัฒนาบางคนอาจรู้สึกว่าถูกทอดทิ้ง
เกมประเมินทีม – สรุป
เกมการประเมินทีมมีความเห็นเกี่ยว กับเทคนิคการประมาณที่มีประสิทธิภาพมากที่สุดสำหรับทีม Scrum ส่วนใหญ่ อย่างไรก็ตาม สิ่งสำคัญที่ต้องจำไว้ว่าเป็นเพียงเครื่องมือสำหรับการประเมินความยากและความพยายามของ User Stories เท่านั้น และเช่นเดียวกับเครื่องมืออื่นๆ เราควรปรับให้เข้ากับความต้องการและความสามารถของสมาชิกในทีม
หากคุณชอบเนื้อหาของเรา เข้าร่วมชุมชนผึ้งที่วุ่นวายบน Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest
คู่มือการต่อสู้:
- อภิธานศัพท์ของคำศัพท์พื้นฐาน บทบาท และแนวคิด
- Scrum คืออะไร?
- ค่าการต่อสู้
- วิธีใช้งาน Scrum ในบริษัทของคุณ
- Scrum Team - มันคืออะไรและทำงานอย่างไร?
- เจ้าของผลิตภัณฑ์คือใคร?
- ข้อผิดพลาดที่พบบ่อยที่สุดของ Product Owner
- Scrum Master คือใคร?
- ลักษณะของ Scrum Master ที่ดี
- ข้อผิดพลาดที่พบบ่อยที่สุดของ Scrum Master
- สถิติและตัวชี้วัดใดที่ Scrum Master ควรติดตาม
- ความร่วมมือระหว่าง Product Owner และ Scrum Master
- ทีมพัฒนาใน Scrum
- ข้อผิดพลาดที่พบบ่อยที่สุดของ Developers
- สิ่งประดิษฐ์การต่อสู้
- สเกลการต่อสู้
- Sprint Backlog
- Backlog สินค้าคืออะไร?
- เรื่องราวของผู้ใช้คืออะไร?
- สร้าง User Story ที่ดีที่สุดกับ INVEST
- ข้อผิดพลาด User Story ที่พบบ่อยที่สุด
- เกณฑ์การยอมรับเรื่องราวของผู้ใช้
- การประมาณค่าและจุดเรื่องราวใน Scrum
- การวางแผนโป๊กเกอร์
- เกมประเมินทีม
- กำหนดส่วนเพิ่ม
- เหตุการณ์การต่อสู้
- Sprint ใน Scrum คืออะไร?
- ความมุ่งมั่นของทีม Scrum - เป้าหมายผลิตภัณฑ์ เป้าหมาย Sprint และคำจำกัดความของความสำเร็จ
- แผนภูมิ Burndown คืออะไร?
- จะสร้างและตีความแผนภูมิเบิร์นดาวน์ได้อย่างไร?
- ข้อดีและข้อเสียของแผนภูมิการเบิร์นดาวน์
- กระดาน Kanban ใน Scrum และ Scruban
- Velocity in Scrum - ความเร็วของทีมพัฒนา
- การต่อสู้รายวัน
- การวางแผนการวิ่ง
- Sprint Review
- Sprint Retrospective คืออะไร?
- ข้อผิดพลาดทั่วไประหว่าง Sprint Retrospective
- บำรุง Backlog สินค้า