Scrum Guide | 25. เกมประเมินทีม

เผยแพร่แล้ว: 2022-05-28

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

เกมประเมินทีม – สารบัญ:

  1. บทนำ
  2. กฎของเกมการประเมินทีม
  3. เกมประเมินทีมกับโป๊กเกอร์วางแผน
  4. สรุป

บทนำ

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

เกมการประเมินทีมได้รับความนิยมอย่างต่อเนื่อง เนื่องจากช่วยให้ทีมพัฒนาสร้างการประมาณได้เร็วกว่าการใช้ 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 และอื่นๆ

Team Estimation Game

ขั้นตอนของเกมการประเมินทีม:

  1. บทนำ. ในการเล่นเกมการประเมินทีม สมาชิกทีม Scrum จะนั่งรอบโต๊ะ Product Owner เริ่มต้นด้วยการจั่วการ์ดใบแรกจากเด็ค User Story และแชร์เนื้อหากับทุกคน จากนั้นไพ่จะอยู่บนโต๊ะ จากนั้น Product Owner จะอธิบายให้ทีม Scrum ที่เหลือฟังว่าต่อจากนี้ไป ผู้เล่นจะประเมิน User Stories ว่าง่ายหรือยากต่อการนำไปใช้โดย จัดวางตามนั้นทางด้านซ้ายและด้านขวา หากมีระดับความยากอยู่บ้าง ผู้เล่นจะเรียงซ้อนกัน กองหนึ่งวางทับกันบนโต๊ะ ตอนนี้ คนที่นั่งอยู่ข้างๆ ตามเข็มนาฬิกาจะขยับต่อไป
  2. ผู้เล่นจั่วการ์ดจากเด็ค User Story หลังจากแชร์เนื้อหากับทุกคนแล้ว ให้อธิบายสาระสำคัญแก่เจ้าของผลิตภัณฑ์ จากนั้นผู้ที่ถือการ์ดจะวางมันลงบนโต๊ะและเลือกที่นั่งตามความคิดเห็นของพวกเขาเกี่ยวกับความยากของเรื่องราวของผู้ใช้รายนี้ จากนั้น ผู้เล่นจะอธิบายเหตุผลที่อยู่เบื้องหลังการเลือกให้ทุกคนฟัง และผู้เล่นคนอื่นๆ สามารถถามคำถามเกี่ยวกับการใช้เหตุผลได้อย่างอิสระ พวกเขาไม่สามารถตั้งคำถามกับการตัดสินใจได้ แต่เป็นการโต้แย้งที่มีเหตุผลในการตัดสินใจ
  3. ตอนนี้ ผู้เล่นผลัดกัน และมีสองตัวเลือกให้เลือก:
    • ทำซ้ำขั้นตอนที่ 2 หรือ
    • ย้ายไพ่หนึ่งใบ บนโต๊ะไปยังตำแหน่งที่เหมาะสมที่สุด

    หากพวกเขาเลือกทางเลือกที่สอง พวกเขาควร ปรับเหตุผลที่ทำให้พวกเขาเปลี่ยนใจ ผู้เล่นผลัดกันทำซ้ำขั้นตอนที่ 3 จนกว่าไพ่ทั้งหมดจากสำรับ User Story จะถูกแจกจ่ายและประมาณการ

  4. ขั้นตอนสุดท้ายของการวางการ์ด User Story จะเกิดขึ้นครั้งเดียวหรือหลายครั้ง ขึ้นอยู่กับการฝึกฝนของ Scrum Team ในรอบนี้ ผู้เล่นแต่ละคนยังมีโอกาสย้ายไพ่หนึ่งใบบนโต๊ะไปยังตำแหน่งที่เหมาะสมกว่า
  5. เมื่อผู้เล่นมอบหมายการ์ด User Story ทั้งหมดไปยังตำแหน่งที่แสดงถึงระดับความยาก ทีมพัฒนาจะย้ายไปจับคู่มูลค่าโดยมอบหมายการ์ดจากกอง Story Point การ์ด User Story ใบแรกทางด้านซ้ายจะได้รับการ์ด Story Point ที่มีคะแนนน้อยที่สุด โดย Product Owner กฎสำหรับการวางไพ่ใบต่อไปจะเหมือนกับคะแนน 3 และ 4 ซึ่งจะทำให้การประมาณเสร็จสมบูรณ์
Team Estimation Game

เกมประเมินทีมกับโป๊กเกอร์วางแผน

เกมการประเมินทีมถือเป็นเครื่องมือการประมาณที่มีประสิทธิภาพมากกว่าการวางแผนโป๊กเกอร์ เนื่องจาก ความแตกต่าง ระหว่างสองเทคนิคนี้:

  • การ์ดตาราง เกมการประเมินทีมใช้ "กฎโต๊ะไพ่" ที่รู้จักกันดีจากเกมไพ่ยอดนิยม ซึ่งหมายความว่าเมื่อคุณวางการ์ดแล้ว คุณจะไม่สามารถนำกลับมาได้ เนื่องจาก User Story ถูกประเมินทีละคน ความผันผวนระหว่างการประมาณค่าและจำนวนครั้งที่ตำแหน่งกะจะต่ำกว่าอย่างเห็นได้ชัด เมื่อเทียบกับ Planning Poker
  • การคำนวณที่แม่นยำเพียงพอ ใน Planning Poker ควรมีข้อตกลงร่วมกันสำหรับ User Story แต่ละรายการ อย่างไรก็ตาม ในเกมการประเมินทีม มีเพียงคนเดียวเท่านั้นที่ตัดสินใจ แม้ว่าการประมาณการของเขา/เธอจะไม่ถูกต้อง นักพัฒนารายอื่นก็มีแนวโน้มจะวางให้ตรงกับมูลค่าของมันมากขึ้น วิธีนี้รับประกันว่าจะได้รับค่าประมาณที่ถูกต้องและรวดเร็วเพียงพอ
  • หมดประเด็นการสนทนา ตัวเลือกการโต้เถียงมักจะยาวเกินไปเมื่อเล่น Planning Poker เวลาของพวกเขาลดลงอย่างมากในระหว่างเกมการประเมินทีมเพราะพวกเขามุ่งเน้นไปที่การตัดสินใจครั้งเดียวโดยหนึ่งในผู้พัฒนามากกว่าธรรมชาติของเรื่องราวของผู้ใช้แต่ละคน

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

เกมประเมินทีม – สรุป

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

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

Scrum Guide | 25. Team Estimation Game caroline becker avatar 1background

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

ในฐานะผู้จัดการโครงการ 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 สินค้า