Ghid Scrum | 35. Daily Scrum

Daily Scrum nu durează mai mult de cincisprezece minute și este întotdeauna ținut în același loc și în același timp pentru a reduce complexitatea inutilă. La ea participă toți dezvoltatorii care lucrează împreună la produs și, opțional, Scrum Master. Scopul principal al acestui eveniment Scrum este de a planifica sarcinile asupra cărora se vor concentra pentru ziua respectivă.

Daily Scrum – cuprins:

1. Introducere
2. Formula Daily Scrum
3. Probleme cu Daily Scrum și metoda 5W
4. Întrebări de sprijin
5. 5 de ce
6. rezumat

Introducere

Daily Scrum este cel mai scurt și mai frecvent dintre evenimentele Scrum, o prezentare generală a căruia poate fi găsită într-un articol separat. Sarcina dezvoltatorilor care participă la Daily Scrum este să stabilească rapid obiective de lucru pentru următoarele 24 de ore. În acest fel, fiecare dintre ei știe la ce lucrează ceilalți și cum lucrează pentru un obiectiv comun de Sprint.

Formula Daily Scrum

Nu există o singură formulă Daily Scrum corectă. Fiecare echipă de dezvoltare dezvoltă un format de întâlnire care funcționează pentru ea. Cu toate acestea, există un cadru general pentru a face mai ușor de condus.

Un Daily Scrum bine condus ar trebui să permită fiecărui participant să răspundă la două întrebări :

• Care este cea mai importantă sarcină pe care o voi îndeplini astăzi?
• Care sunt obstacolele în îndeplinirea acestei sarcini?

Cu toate acestea, a le cere direct nu este o formulă obligatorie. Acestea sunt exemple de întrebări care definesc axa întâlnirii. Daily Scrum are scopul de a îmbunătăți comunicarea în echipa de dezvoltare, de a prioritiza sarcinile și de a reduce riscul blocajelor.

Daily Scrum este un eveniment echivalent cu Daily Standup în alte metode Agile. Și deseori funcționează foarte asemănător cu acesta – deși Ghidul Scrum oficial nu cere dezvoltatorilor să stea în timpul acestui scurt eveniment. Foarte des participanții săi pur și simplu stau în picioare în timp ce vorbesc într-un grup informal.

Deși poate părea că 15 minute pe zi este mult pentru a discuta despre sarcinile zilnice, practica arată că o astfel de întâlnire este cea mai bună pentru eficacitatea echipei de dezvoltare. Cu actualizări frecvente și regulate cu privire la obiective și angajamente, toți dezvoltatorii se concentrează pe sarcini prioritare și acordă prioritate progresului uniform al echipei față de rezultatele individuale.

Probleme cu Daily Scrum și metoda 5W

Una dintre problemele cu Daily Scrum este că dezvoltatorii prelungesc timpul întâlnirii. Dacă acesta este cazul, este o idee bună să introduceți o politică de a scrie pe o tablă – fizice sau virtuale – probleme problematice care nu sunt esențiale pentru Daily Scrum, dar sunt importante pentru echipă. În acest fel, se va putea reveni la problemele care au rămas de discutat în cadrul discuțiilor informale din timpul zilei. Și, de asemenea, dacă este nevoie, în timpul Retrospectivei Sprint, pe care o vom descrie mai detaliat într-un articol separat.

O altă problemă care apare adesea în timpul Daily Scrums este transformarea acestora în întâlniri pentru a rezuma munca din ziua precedentă. Dezvoltatorii se concentrează apoi pe discutarea rezultatelor deja obținute. Aceasta nu este o practică bună. Desigur, orientarea actuală a Dezvoltatorilor cu privire la stadiul lucrării care duce la Scopul Sprint este foarte importantă. Cu toate acestea, dedicarea Daily Scrum sarcinilor deja finalizate nu promovează eficiența.

Întrebări de sprijin

Dacă echipa nu beneficiază de Daily Scrum, Scrum Master îi poate ajuta pe dezvoltatori să identifice problemele observând întâlnirea pentru a găsi răspunsuri la următoarele întrebări:

5 de ce

După identificarea inițială a problemei, o tehnică eficientă pentru determinarea cauzei problemei poate fi metoda 5 Whys numită și 5 Whys sau 5W de Sakichi Toyoda. Aceasta implică întrebarea mai multor „De ce?” întrebări la rând. Acest lucru face posibilă diagnosticarea cauzei mai profunde a problemei și, astfel, rezolvarea ei mai ușor.

De exemplu, să luăm ultimul element din tabel: problema apare în zona angajamentului pentru rezolvarea problemelor din partea echipei de dezvoltare. Cele cinci întrebări ar putea arăta după cum urmează:

1 x DE CE?

Î: De ce dezvoltatorii nu oferă modalități diferite de a rezolva problemele care apar?

R: Pentru că dezvoltatorul Harry este întotdeauna primul care propune o soluție.

2 x DE CE?

Î: De ce dezvoltatorul Harry este întotdeauna primul care propune o soluție?

R: Pentru că nimeni altcineva nu vorbește.

3 x DE CE?

Î: De ce nu vorbește nimeni altcineva?

R: Pentru că alți Dezvoltatori nu doresc să caute soluții mai bune.

4 x DE CE?

Î: De ce alți Dezvoltatori nu au chef să caute soluții mai bune?

R: Pentru că găsirea de soluții necesită concentrare și este mai ușor să consideri soluția lui Harry suficient de bună.

5 x DE CE?

Î: De ce au considerat soluția lui Harry suficient de bună?

R: Deoarece nu sunt recompensați pentru că au propus alternative, ei și-au discutat planurile pentru astăzi la începutul întâlnirii și se gândesc să înceapă.

În acest caz, problema lipsei de angajament în rezolvarea problemelor poate fi rezolvată prin schimbarea ordinii Scrum-ului zilnic și începând cu această problemă. Sau venirea cu un sistem de recompensare a celei mai bune soluții, de exemplu, introducerea unei recompense simbolice pentru autorul celui mai mare număr de soluții acceptate de Echipă într-un anumit Sprint.

rezumat

Daily Scrum este o parte cheie a muncii zilnice a echipei de dezvoltare. Cu toate acestea, fiecare echipă trebuie să elaboreze pentru sine formula optimă pentru această întâlnire. Un Daily Scrum bine desfășurat permite stabilirea continuă a sub-obiectivelor pentru a atinge Scopul Sprintului. De asemenea, face posibilă diagnosticarea rapidă a problemelor de comunicare și îmbunătățirea cooperării între Dezvoltatori.

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

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.

Vizualizați toate postările

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