Metricurile agile sunt măsurători utilizate pentru a urmări progresul și succesul unei echipe de proiect agile.
Valorile, atunci când sunt definite în mod corect, oferă informații despre performanța echipei, calitatea, eficiența testării sau eficiența generală și modul în care aceasta evoluează în timp.
Scopul final al metricilor agile este de a ajuta echipele să identifice zonele de îmbunătățire și să ia decizii bazate pe date care vor duce la produse mai bune pe măsură ce echipa progresează.
De cele mai multe ori, companiile definesc valori care sunt fie valori vanitare, fie numere brute, crescând frumos de la stânga la dreapta. S-ar putea să arate bine pe unele tablouri de bord, dar de obicei sunt inutile pentru echipa în sine.
Scopul lor nu este să ajute în vreun fel echipa ci mai degrabă să completeze niște rapoarte pentru conducere și apoi să încheie cu niște decizii strategice. Din păcate, atunci echipa este cea care nu înțelege de ce există această decizie specială.
Într-un gard pentru a îndeplini astfel de valori greșite, echipele își falsifică apoi propriile procese pentru a face ca valorile să arate bine. Dar rezultatul echipei nu se îmbunătățește deloc.
Cuprins
Valori de bază
Există multe moduri de a separa valorile. Poate cel mai de bază este de sus în jos și de jos în sus.
➡️ De sus în jos înseamnă: noi, liderii, vă vom crea valori pe care vrem să le îndepliniți cu toții, iar obiectivul vostru final este să vă încadrați în zonele verzi ale acestora. Nu ne deranjează dacă tu – o echipă ca ei sau nu; asta vrem să urmărim.
➡️ De jos în sus înseamnă: Noi – echipa trebuie să ne îmbunătățim în acele domenii și, pentru asta, trebuie să ne concentrăm asupra acestor lucruri. Prin urmare, definim valori care ne vor permite să urmărim progresul echipei în atingerea obiectivelor noastre și vă putem demonstra – leadership-ul, cum ne-a îmbunătățit activitatea în timp.
Definiția Good Metric
Deci, ce ar trebui să conțină orice valoare bună sau cum să o descriem?
Cea mai importantă proprietate este schimbarea comportamentului. Aceasta înseamnă că de fiecare dată când te uiți la rezultatul valorii, este clar ce trebuie să se schimbe în interiorul echipei pentru a obține îmbunătățiri.
Atunci trebuie să fie simplu. Dacă nu poți explica cu câteva propoziții simple, astfel încât toți ascultătorii relevanți să înțeleagă, atunci ceva nu este chiar bun.
O valoare bună este comparabilă în timp. Faceți un instantaneu al rezultatelor într-un timp, apoi faceți-o din nou cândva mai târziu. Așezați-le unul lângă altul. Dacă nu puteți compara cele două rezultate între ele, atunci ar trebui să vă gândiți din nou la această măsurătoare.
În cele din urmă, mai bine decât numerele pure, ori de câte ori este posibil, faceți un raport sau un procent. „10 noi defecte deschise în timpul sprintului” nu vor spune prea multe. Depinde dacă ai în mod normal unul sau 100.
Iată câteva exemple de valori despre care cred că îndeplinesc toate aceste criterii de definiție. Ei au în vedere echipele Agile. Există trei categorii principale: performanță, calitate și moral.
Categorii de metrici
Valori de performanță
Scopul este de a înțelege cât de bine este echipa să ajungă din urmă cu poveștile comise în cadrul unui sprint. Pentru a evalua dacă supraangajarea nu este o afacere ca de obicei sau dacă poveștile reportate sunt un standard de la sprint la sprint.
Din perspectiva performanței agile, echipa se va strădui să livreze conținutul de sprint planificat la care echipa sa angajat la începutul sprintului.
Nu înseamnă că nu vom fi flexibili în schimbul de povești în timpul sprintului. Dar ar trebui să fie întotdeauna o negociere care să conducă la un schimb, nu o adăugare. Capacitatea echipei nu va crește doar pentru că cineva a adăugat povești noi în sprint.
Aducem această măsurătoare pentru a fi atenți la astfel de cazuri și pentru a îndruma pe toți membrii echipei pentru a proteja capacitatea pe care o au pentru sprint.
Acest lucru sporește fiabilitatea și predictibilitatea echipei.
#1. Capacitate de sprint vs. Puncte de poveste livrate
Urmăriți istoricul capacității de sprint în comparație cu conținutul de puncte de poveste livrate (SP) pe parcursul sprinturilor.
- Micile abateri de la sprint la sprint sunt bune. Salturi uriașe în orice direcție semnalează că ceva este oprit.
- Capacitate totală de sprint – ziua disponibilă a unui membru al echipei adaugă una la capacitatea totală. De exemplu, dacă echipa are 10 persoane și toate vor fi disponibile în sprint complet, atunci capacitatea totală pentru sprint este de 100.
Verificați capacitatea de sprint față de SP finalizat de la sprint la sprint. Dacă echipa (în timpul planificării) se angajează la o cantitate semnificativ mai mare de SP decât o poate completa de obicei, ridicați acest risc pentru echipă.
Scopul va fi acela de a avea un SP total planificat egal sau mai mic decât SP total finalizat pe sprint.
Puteți avea totuși mai mult SP finalizat decât era planificat dacă echipa a finalizat (spre sfârșitul sprintului) toate poveștile planificate și echipa are încă capacitatea de a prelua povestea suplimentară.
- Dacă echipa oferă în mod repetat mai puțin SP decât era planificat, echipa trebuie să își modifice planificarea și să ia mai puțin SP în următorul sprint.
Instrumente precum monday.com, Atlassian Jira sau Asana oferă o modalitate simplă de a salva și de a extrage puncte pentru fiecare poveste din sprinturi. Ei pot chiar să genereze asta automat după fiecare planificare de sprint.
#2. Graficul Burndown
Aceasta este una dintre valorile probabil pe care majoritatea echipelor scrum au ascuns undeva pe tabloul de bord. Sunt de acord că asta ar putea chiar să pară un lucru inutil. Echipa ia rareori în considerare. Mai degrabă, managerului îi place să sublinieze cum arată poveștile de la un nivel înalt și cum nu progresează bine (deoarece sunt toate deschise întregului sprint).
Ceea ce aș dori să subliniez este că, în ciuda acestui fapt, tu, ca echipă, ar trebui să mergi și să verifici graficul de ardere pentru binele tău. Dacă toate poveștile sunt deschise pe tot parcursul sprintului și închise doar în ultima zi a sprintului, acest lucru creează incertitudine în interiorul echipei și către îndeplinirea obiectivelor de sprint.
- Examinați-vă tabloul de sprint pentru a afla poveștile finalizate.
- Verificați cu echipa pentru a determina de ce micile povești sunt încă deschise, chiar dacă au început la începutul sprintului.
- Lucrează cu echipa pentru a construi acea mentalitate, nu pentru a menține poveștile deschise mai mult decât este necesar.
- Diagrama de ardere ideală este de obicei o stare teoretică. Cu toate acestea, cu cât ne apropiem de ea, cu atât avem o gestionare mai eficientă a poveștii.
Instrumentele de management agil, cum ar fi Asana, vă pot genera automat un grafic de ardere pentru fiecare sprint.
Sursa: asana.com
#3. Finalizarea obiectivului de sprint
Acesta urmărește procentul de obiective de sprint pe care le-ați îndeplinit în timpul fiecărui sprint.
Documentați obiectivele Sprintului separat, de exemplu, pe pagina Confluence / Jira, pentru fiecare sprint. Statutul va fi atribuit indiferent dacă au fost îndeplinite sau nu în sprint.
Chiar dacă echipa nu a finalizat toate poveștile într-un sprint, ar putea totuși atinge obiectivul Sprintului (de exemplu, lipsesc doar poveștile secundare).
Vom urmări atingerea 100% a obiectivelor de sprint în fiecare sprint. Dacă nu este cazul, află ce previne echipa.
- Dacă sunt prea multe subiecte paralele în fiecare sprint, reduceți cantitatea acestora.
- Dacă sunt adăugate prea multe povești ad-hoc în timpul sprintului, reduceți acest lucru, astfel încât să nu afecteze obiectivele originale de sprint.
- Dacă obiectivele de sprint sunt prea mari sau prea provocatoare, simplifică-l. Oricum, nu are sens să ai obiective mari de sprint în timp ce nu le îndeplinești până la sfârșitul sprintului.
Valori de calitate a codului
Aceasta va urmări cât de bun este codul în timp. Ajută la menținerea proceselor de dezvoltare sănătoase și scade timpul petrecut pentru rezolvarea problemelor. Sau timpul de inactivitate al dezvoltatorului cauzat de așteptarea execuției codului în timpul activităților de dezvoltare și testare.
Sursa: azuredevopslabs.com
#1. Teste automate
Creați teste unitare automate de către dezvoltatori pentru fiecare modificare pe care o fac.
- Măsurați acoperirea codului prin teste automate – utilizați Azure Pipelines sau SonarCloud pentru a rula testele. Urmăriți o acoperire de 85%. Peste 90% nu este chiar eficient.
- Asigurați-vă că crearea automată a testului unitar face parte din definiția de făcut pentru noile povești.
- Reveniți din urmă cu acoperirea de testare a codului vechi, ca parte a poveștilor de datorii tehnice din restanța.
#2. Complexitatea codului
Evaluați complicațiile inutile pe care le obține codul în timp și remediați-le în mod activ prin poveștile tehnice ale datoriilor. Sau împiedicați-le să se întâmple, dacă este posibil.
Definiți standarde de cod și linii directoare pentru a educa dezvoltatorii să le respecte. Asigurați-vă că respectă regulile de codificare pentru a minimiza creșterea nerațională a complexității codului. A actualizat regulat ghidurile pe baza experienței echipei.
Identificați mirosurile de cod – indicatori ai problemelor potențiale ale codului, cum ar fi codul duplicat, metodele lungi și variabilele neutilizate.
Evaluările inter pares trebuie să asigure că standardele de cod sunt aplicate codului nou creat.
Utilizați instrumente precum tablourile de bord și rapoartele Azure Ado sau SonarCloud pentru a descoperi problemele de cod.
#3. Pași manuali în implementare
Urmăriți câți pași manuali trebuie să facă echipa pentru a lansa codul în medii de testare sau de producție.
- Scopul nostru va fi să atingem 0 aici în timp.
- Creați povești de datorii tehnice, dacă este necesar, pentru a aduce conducta de implementare/lansare până la foaia de parcurs de automatizare. Reduceți treptat pașii manuali rămași în procesele de la sprint la sprint.
Metrica morală
Aceasta este o măsură pentru a urmări modul în care echipa se simte despre munca sa și procesele cu care se confruntă zilnic.
#1. Realizare retrospectivă Sprint
Puteți urmări câte elemente de acțiune au fost finalizate efectiv în următorul sprint.
- Scrum Master va colecta rezultatele întâlnirii retrospective în paginile echipei pentru a urmări elementele de acțiune convenite.
- Echipa urma să țină evidența progresului.
- Managementul de proiect poate examina apoi dacă elementele de acțiune progresează sau ceea ce împiedică echipa să le finalizeze. Apoi modificați mediul pentru a permite echipei să progreseze în acțiunile convenite.
Cel puțin 33% sau 1 (în funcție de ce este mai mare) dintre elementele de acțiune din sprintul anterior vor fi adoptate în sprinturile următoare.
Dacă este mai puțin decât atât, sunt necesare schimbări pentru a permite echipei să implementeze îmbunătățirile asupra cărora au convenit.
Instrumentele de management de proiect conțin șabloane gata de utilizat pentru activități retrospective de sprint. Iată un exemplu de pe monday.com:
Sursa: monday.com
#2. Colaborarea în echipă
Programare perechi de piese.
- Formați un cuplu natural per poveste pentru a lucra împreună, împărtășind observații, cunoștințe și succes. Creați subsarcini în poveștile deținute de diferiți membri ai echipei.
Urmăriți recenziile codului de la inițiativele colegilor.
- Colegii sunt rugați sau iau măsuri proactiv pentru a revizui rezultatul poveștii altcuiva.
Valoarea poate fi extrasă din tabloul monday.com/Asana/Jira din subsarcini.
Cel puțin 50% din poveștile din sprint vor fi împărtășite de membrii echipei. Dacă este mai puțin, investigați motivele și luați măsuri acolo unde are sens.
Pentru evaluări voluntare, urmăriți poveștile cu sarcini secundare dedicate. La început, 20% dintre poveștile de cod revizuite în acest fel reprezintă un început bun. Treptat, pe parcursul sprinturilor, vei încuraja și motiva echipa să lucreze mai colaborativ și să o crești până la 50% din poveștile de cod per sprint ca obiectiv.
#3. Datoria tehnică vs. Povești noi cu funcționalități
Sursa: atlassian.com
Oferirea echipei oportunitatea de a-și rezolva propriile povești de datorii va crește satisfacția echipei cu munca lor.
- Dimpotrivă, acumularea de datorii tehnologice fără un plan de rezolvare progresivă va demotiva echipa în timp. Iar soluția va deveni mai instabilă, complexă și dificil de rezolvat fără o reluare substanțială.
Echipa știe cel mai bine ce nu funcționează bine cu soluția, chiar dacă părțile interesate sau utilizatorii finali nu o văd. Astfel de povești au cel mai mare impact asupra echipei de dezvoltare în sine. Pentru părțile interesate, acestea ar putea fi invizibile. De aceea este important să acordăm echipei șansa de a lucra la povești care să-i ajute să elibereze activitățile de dezvoltare.
Scopul este de a urmări câte povești de datorii tehnice ridicate sunt rezolvate de-a lungul timpului și dacă stocul de astfel de povești doar crește sau nu.
Echipa poate eticheta poveștile ca TechDebt în backlog și le poate acorda prioritate din partea echipei, astfel încât să poată merge în top și să fie selectați în sprinturi.
În funcție de starea în care se află proiectul și de câte datorii tehnologice sunt identificate în backlog, poate doriți să vă asigurați că acumularea TechDebt nu crește cu mai mult de 10% de la sprint la sprint.
Acordați prioritate poveștilor datoriilor tehnologice și includeți-le în sprinturi pentru a menține sub control creșterea datoriilor tehnologice, astfel încât echipa să aibă voie să lucreze la poveștile datoriilor tehnologice 10-20% din timp la fiecare sprint.
Cuvinte finale
Fiecare proiect va avea nevoie în cele din urmă de niște metrici, fie pentru că conducerea vrea să le aibă sau pentru că echipa decide să-și măsoare propriul succes.
Cel mai bun lucru pe care îl puteți face este să începeți să vă construiți biblioteca de valori gata pentru a fi aleasă și utilizată; cu cat mai repede cu atat mai bine. Și, în timp ce faceți asta, asigurați-vă că alegeți întotdeauna valorile care schimbă comportamentul, mai ales.
Apoi, verificați procesele nesănătoase care vă pot distruge sprintul.