Ghid Scrum | 31. Cum se creează și se interpretează un grafic de ardere?

Un grafic de ardere este relativ ușor de creat. Există multe instrumente disponibile pentru a-l genera din munca înregistrată de membrii echipei de dezvoltare. În ciuda simplității sale, interpretarea sa poate oferi informații valoroase pentru întreaga echipă Scrum. Citiți acest articol pentru a afla cum să creați și să interpretați un grafic de ardere.

Cum se creează și se interpretează un grafic de ardere? - Cuprins:

1. Cum se creează un grafic de ardere?
2. Cine este responsabil pentru graficul de ardere?
3. Cum se interpretează un grafic de ardere?
4. Diagrama de ardere reală și ideală
5. Selectarea unității de măsură
6. rezumat

Cum se creează un grafic de ardere?

Echipa de dezvoltare ar trebui să-și monitorizeze activitatea zilnică. Aceasta este baza nu numai pentru evaluarea eficacității sale, ci și pentru îmbunătățirea acesteia. Și unul dintre cele mai simple și dovedite instrumente în acest scop este diagrama de ardere.

Îl puteți crea manual desenând un sistem de coordonate pe o bucată de hârtie. Pe axa Y trebuie să reprezentați cantitatea de muncă exprimată într-o unitate aleasă, de exemplu, puncte de poveste. Pe axa X, desenați o scară care indică zilele consecutive ale Sprintului. Desenați o linie a sprintului ideal, apoi marcați numărul de sarcini realizate în mod realist pentru fiecare zi. Deși această soluție este fermecătoare și angajează echipa, nu este foarte practică. De asemenea, nu este neapărat potrivit pentru echipele aflate la distanță.

Prin urmare, mijloacele digitale de creare a unei diagrame de ardere sunt mult mai comune. Multe instrumente pentru înregistrarea lucrărilor pe sarcini distribuite între membrii echipei vin cu o opțiune de a crea automat un grafic de ardere. Apoi, tot ce trebuie să facă un Dezvoltator este să marcheze începutul și sfârșitul lucrului pentru o anumită caracteristică a produsului, iar contribuția lor este reflectată în graficul de ardere.

Cu instrumentele potrivite, este, de asemenea, posibilă scalarea liberă a diagramei. Acest lucru oferă o perspectivă asupra arderii nu numai la nivelul unui Sprint dat, ci și la scara unui sfert sau a întregului proiect.

Un factor important de luat în considerare atunci când alegeți un instrument pentru crearea unei diagrame de ardere este accesibilitatea acestuia pentru toți membrii echipei Scrum. Vizibilitatea diagramei de ardere pentru întreaga echipă de dezvoltare este un factor motivațional cheie. La fel de importantă este o privire zilnică asupra liniei care arată munca rămasă de făcut. Vorbind despre burn-in în timpul Scrumului zilnic, , îi face pe Dezvoltatori să se gândească la modurile în care lucrează și la starea actuală a Produsului.

Cine este responsabil pentru graficul de ardere?

Problema proprietății diagramei de ardere este oarecum controversată. Pe de o parte, ar trebui să aparțină Scrum Master, deoarece este un instrument pentru a vă asigura că echipa lucrează eficient și conform planului. Pe de altă parte, ar trebui să rămână în mâinile Product Owner-ului, deoarece reflectă progresul către un Produs Goal care este comunicat Clientului. În plus, o terță parte care își revendică proprietatea este Echipa de dezvoltare, deoarece diagrama funcționează ca instrument intern.

Diagrama de ardere este o măsură esențială pentru evaluarea eficienței echipei de dezvoltare și este adoptată de toți membrii echipei Scrum. De aceea, transparența și accesibilitatea sunt cruciale. Cu toate acestea, scopul său este de a servi Echipa. Ar trebui să-și consolideze auto-organizarea, să îmbunătățească motivația și să ofere o imagine reală a stării muncii în sarcinile care îi sunt atribuite. Prin urmare, în teorie, fiecare membru al echipei de dezvoltare poate actualiza diagrama de ardere.

În practică, însă, sarcina de a actualiza diagrama de ardere revine de obicei Scrum Master. Acest lucru se întâmplă mai ales la începutul lucrului său cu o nouă echipă de dezvoltare, când viteza echipei este încă variabilă și greu de estimat. Cu toate acestea, se recomandă să delegați această sarcină unuia dintre Dezvoltatori. La urma urmei, graficul este menit să fie o măsură onesta și internă a progresului lucrării, după cum este judecat de către dezvoltatori înșiși.

Cum se interpretează un grafic de ardere?

Am descris în detaliu aspectul graficului de ardere într-un articol anterior. Aici vă vom aminti doar că axa X arată timpul rămas pentru finalizarea lucrării. Pe de altă parte, axa Y arată cantitatea de muncă rămasă de făcut.

Diagrama de ardere reală și ideală

Pentru a interpreta o diagramă de ardere, factorul cheie nu este doar reprezentarea obișnuită a „combustiei”, adică executarea sarcinilor de către Echipa de Dezvoltare. La fel de importantă pentru imagine este compararea acesteia cu căderea ideală a liniei de ardere (linia directoare).

Comparând linia ideală de ardere cu reducerea reală a muncii marcată pe graficul de ardere, pot fi evaluați doi parametri foarte importanți. În primul rând, pentru a vedea dacă munca continuă în ritmul actual, echipa de dezvoltare va îndeplini obiectivul de Sprint sau obiectivul de produs la timp. În al doilea rând, să vă faceți o idee despre când va fi finalizată lucrarea, menținând în același timp ritmul actual. Cu alte cuvinte, graficul de ardere arată ritmul real al sarcinilor, iar linia ideală arată în ce ritm trebuie să lucreze Echipa pentru a finaliza sarcinile.

Graficul de ardere vă permite, de asemenea, să determinați o valoare numită Development Team Velocity pe termen lung. Îi vom dedica un articol separat. Aici vom menționa doar că este o valoare determinată de cantitatea de muncă depusă în timpul unui Sprint.

Datorită faptului că diagrama de ardere ilustrează compararea unei linii de ardere ideale cu o scădere reală a numărului de sarcini, vă permite să estimați ritmul de lucru. Și astfel anticipați riscul de întârzieri ale proiectului.

Selectarea unității de măsură

Viteza echipei este de obicei măsurată în unități numite puncte de poveste. Acesta definește numărul de povești de utilizator care au fost realizate. Acestea pot necesita cantități foarte diferite de muncă.

Acesta este motivul pentru care multe echipe Scrum folosesc o măsură bazată pe timp. În funcție de scară, acestea sunt zile sau ore-om. Fiecare Dezvoltator estimează și apoi înregistrează timpul petrecut cu sarcinile sale.

O altă opțiune este adoptarea sarcinilor ca unitate. Acestea sunt unități puțin mai mari, cărora, la rândul lor, li se atribuie o valoare exprimată în puncte de poveste, sau în zile sau ore-om. Este o unitate care permite clientului să prezinte într-un mod mai clar progresul lucrării la produs.

Indiferent de unitatea de măsură, merită să ne amintim principiul calculării vitezei echipei de dezvoltare. Într-o anumită zi sau Sprint , contează doar sarcinile care au fost finalizate efectiv. Înseamnă că sarcinile începute vor fi numărate pentru ziua următoare sau pentru Sprint, chiar dacă lipsește doar testarea finală.

rezumat

Cu instrumentele de monitorizare a echipei disponibile, crearea unei diagrame de ardere devine o sarcină ușoară. Cea mai importantă problemă este asigurarea coerenței, clarității și accesibilității pentru toți membrii echipei Scrum.

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