Ghid Scrum | 25. Joc de estimare a echipei

Publicat: 2022-05-28

Jocul de estimare a echipei este o tehnică care facilitează planificarea sprintului în Scrum. Prin ce diferă de Planning Poker? De ce unele echipe de dezvoltare îl consideră un instrument mai eficient, iar altele nu? Veți găsi tot ce trebuie să știți despre el în articolul următor.

Joc de estimare a echipei – cuprins:

  1. Introducere
  2. Regulile jocului de estimare a echipei
  3. Joc de estimare a echipei versus Planning Poker
  4. rezumat

Introducere

Jocul de estimare a echipelor se mai numește și Swimlanes Estimation. Ultimul termen a apărut ca observare spontană a unui joc de cărți, deoarece afișarea cărților semăna cu benzile de înot ale unei piscine cu apă.

Jocul Team Estimation câștigă în mod constant popularitate, deoarece permite echipelor de dezvoltare să creeze estimări de aproximativ 3 ori mai rapid decât folosind Planning Poker.

Despre această tehnică scriem în articolul anterior. Astăzi, să ne concentrăm pe Jocul de estimare a echipei.

Regulile jocului de estimare a echipei

Instrucțiuni de joc pentru estimarea echipei:

  • un pachet de cărți User Stories – pregătite separat pentru fiecare joc
  • un pachet de cărți Story Point – pentru utilizare repetată

În primul rând, stivuiți cărțile User Stories în ordinea corespunzătoare intrărilor din Product Backlog. Pentru a vă asigura că cele mai urgente sunt estimate mai întâi.

Cărțile de punctaj conțin de obicei valori corespunzătoare secvenței Fibonacci. Aceasta este o succesiune a următoarelor numere: 0, 1, 3, 5, 8, 13, 20, 40 și 100. De asemenea, le puteți eticheta cu puteri succesive ale numărului 2, adică 2, 4, 8, 16, 32 și așa mai departe.

Team Estimation Game

Fazele jocului de estimare a echipei:

  1. Introducere. Pentru a juca Jocul de estimare a echipei, membrii echipei Scrum stau în jurul unei mese. Product Owner începe prin a trage prima carte din pachetul User Story și a împărtăși conținutul acesteia tuturor. Apoi, cărțile rămân pe masă. Apoi Product Owner explică restului echipei Scrum că, de acum înainte, jucătorii vor evalua User Stories ca fiind ușor sau greu de implementat, plasându-le în mod corespunzător în stânga și în dreapta. Dacă se întâmplă ca vreunul să aibă un anumit grad de dificultate, jucătorul se va stivui, unul peste altul pe masă. Acum, persoana care stă lângă ei în sensul acelor de ceasornic face următoarea mișcare.
  2. Un jucător trage o carte din pachetul User Story. După ce și-a împărtășit conținutul tuturor, își explică esența lui Product Owner. Persoana care deține cardul îl așează apoi pe masă și selectează un loc în funcție de opinia sa despre dificultatea Povestirii acestui utilizator. Apoi, jucătorul explică tuturor raționamentul din spatele alegerii, iar celălalt jucător este liber să pună întrebări cu privire la raționament. Ei nu pot pune la îndoială decizia în sine, ci argumentele care justifică decizia.
  3. Acum, jucătorii iau o tură și au două opțiuni din care să aleagă:
    • Repetați pasul 2 sau
    • Mutați una dintre cărțile de pe masă în poziția cea mai potrivită

    Dacă optează pentru a doua opțiune, ar trebui să justifice și ceea ce i-a făcut să se răzgândească. Jucătorii repetă pe rând pasul 3 până când toate cărțile din pachetul User Story sunt distribuite și estimate.

  4. Etapa finală a plasării cardurilor User Story are loc o dată sau de mai multe ori, în funcție de practica echipei Scrum. În timpul acestei runde, fiecare jucător are încă o oportunitate de a muta una dintre cărțile de pe masă într-un loc mai potrivit.
  5. Odată ce jucătorii atribuie toate cărțile Poveștile utilizatorului în locațiile lor reprezentând niveluri de dificultate, Echipa de Dezvoltare trece la potrivirea valorii prin alocarea cărților din teancul Story Point. Primul card User Story din stânga primește cardul Story Point cu cel mai mic număr de puncte de către Product Owner. Regula pentru plasarea cărților ulterioare este aceeași ca și pentru punctele 3 și 4. Aceasta completează estimarea.
Team Estimation Game

Joc de estimare a echipei versus Planning Poker

Jocul de estimare a echipei este considerat un instrument de estimare mai eficient decât Planning Poker. Din cauza următoarelor diferențe dintre aceste două tehnici:

  • Masă de cărți. Jocul Team Estimation folosește binecunoscuta „regulă a mesei de cărți” din jocurile de cărți populare. Aceasta înseamnă că, odată ce ați plasat un card, nu îl puteți lua înapoi. Deoarece User Story este estimată de o persoană odată, fluctuația dintre estimări și numărul de ori în care pozițiile de schimb sunt semnificativ mai mici, în comparație cu Planning Poker.
  • Un calcul suficient de precis. În Planning Poker, ar trebui să se ajungă la un consens deplin pentru fiecare poveste de utilizator. În jocul de estimare a echipei, totuși, o singură persoană decide. Chiar dacă estimarea lui/ei este greșită, un alt Dezvoltator o va pune probabil pe o potrivire mai precisă a valorii sale. Acest mod garantează atingerea unor estimări suficient de precise și rapide
  • Epuizant subiectul discutiei. Opțiunile de ceartă devin adesea excesiv de lungi când joci Planning Poker. Timpul lor este mult redus în timpul unui joc de evaluare a echipei, deoarece se concentrează pe o singură decizie a unuia dintre Dezvoltatori, mai degrabă decât pe natura fiecărei povești de utilizator.

Un potențial dezavantaj al jocului de estimare a echipei este sentimentul de nedreptate. Dacă echipa de dezvoltare este mai mare decât numărul de povești de utilizator programate într-un anumit Sprint, unii dezvoltatori se pot simți excluși.

Joc de estimare a echipei – rezumat

Team Estimation Game are o opinie despre cea mai eficientă tehnică de estimare pentru majoritatea echipelor Scrum. Cu toate acestea, este important să ne amintim că este doar un instrument de estimare a dificultății și efortului User Stories. Și, ca orice instrument, ar trebui să îl adaptăm pentru a se potrivi cu nevoile și capacitățile membrilor echipei.

Dacă vă place conținutul nostru, alăturați-vă comunității noastre de albine ocupate pe Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

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

Autor: Caroline Becker

În calitate de manager de proiect, Caroline este expertă în găsirea de noi metode de a proiecta cele mai bune fluxuri de lucru și de a optimiza procesele. Abilitățile ei de organizare și capacitatea de a lucra sub presiunea timpului o fac cea mai bună persoană pentru a transforma proiectele complicate în realitate.

Ghid Scrum:

  1. Glosar de termeni de bază, roluri și noțiuni
  2. Ce este Scrum?
  3. Valorile Scrum
  4. Cum implementezi Scrum în compania ta?
  5. Echipa Scrum - ce este și cum funcționează?
  6. Cine este un proprietar de produs?
  7. Cele mai frecvente greșeli ale Product Ownerului
  8. Cine este Scrum Master?
  9. Caracteristicile unui bun Scrum Master
  10. Cele mai frecvente greșeli ale Scrum Master
  11. Ce statistici și valori ar trebui să urmărească Scrum Master?
  12. Cooperare între Product Owner și Scrum Master
  13. Echipa de dezvoltare în Scrum
  14. Cele mai frecvente greșeli ale dezvoltatorilor
  15. Artefacte Scrum
  16. Scaling Scrum
  17. Sprint Backlog
  18. Ce este Product Backlog?
  19. Ce sunt User Stories?
  20. Crearea celei mai bune povești de utilizator cu INVEST
  21. Cele mai frecvente greșeli ale User Story
  22. Criterii de acceptare a poveștii utilizatorului
  23. Estimare și Story Points în Scrum
  24. Planificarea Pokerului
  25. Joc de estimare a echipei
  26. Definirea creșterii
  27. Evenimente Scrum
  28. Ce este Sprint în Scrum?
  29. Angajamentele echipei Scrum - Obiectiv de produs, obiectiv de sprint și definiția finalizării
  30. Ce este un grafic Burndown?
  31. Cum se creează și se interpretează un grafic de ardere?
  32. Avantajele și dezavantajele diagramei de ardere
  33. Panouri Kanban în Scrum și Scrumban
  34. Viteza în Scrum - Viteza echipei de dezvoltare
  35. Scrum zilnic
  36. Planificarea sprintului
  37. Sprint Review
  38. Ce este o retrospectivă Sprint?
  39. Greșeli frecvente în timpul unei retrospective de sprint
  40. Creșterea backlog-ului de produse