Metrici de dezvoltare software Agile și KPI – uri care ajută la optimizarea livrării produselor

timp de citire: 13 minute

abordarea agilă a dezvoltării de software a fost mult timp o practică obișnuită. Conform sondajului online HP, 16% dintre profesioniștii IT optează pentru agil pur, 51% se apleacă spre it, iar 24% adoptă o abordare hibridă agilă. Astăzi, dezvoltarea cascadei este menționată cel mai adesea ca un diferențiator agil, ceea ce nu este agil. Am discutat pe larg principalele diferențe în cartea noastră albă privind metodologiile agile de management al proiectelor.

în ciuda adaptabilității și flexibilității managementului agil și a răspunsului său rapid la schimbări, fluxul de lucru poate rămâne centralizat și controlat. KPI-urile Agile (Key performance Indicators) oferă îndrumări pentru planificarea strategică, evaluarea și îmbunătățirea proceselor operaționale.

sistemele tradiționale de gestionare a valorii tind să se concentreze pe finalizarea sarcinilor în cadrul programului și costului categoric. Cu toate acestea, cu agile, clienții și membrii echipei văd rezultate imediate și ajustează intervalele de timp și efortul de a livra un produs care corespunde cerințelor programului. Ce instrumente și tehnici necesită astfel de cunoștințe? Iată prezentarea generală a evaluării performanței valorilor de dezvoltare agile.

Agile software development KPI

în acest articol, nu vom explora toate valorile posibile de dezvoltare agile și KPI. În plus, puteți inventa propriile dvs. care se potrivesc cel mai bine proiectului dvs. Cu toate acestea, vom descrie cele mai comune KPI-uri utilizate în mai multe aspecte de dezvoltare software:

• viteză
• Sprint burndown
• eliberare burndown
• ciclu de timp
• Flux cumulativ
• eficiența fluxului
• cod de acoperire prin teste automate
• testare automatizare împotriva testării manuale
• McCabe cyclomatic complexitate (MCC)
• putinei Cod

măsurarea lucrărilor în curs

viteza

viteza măsoară cantitatea de muncă (o serie de caracteristici) finalizată într-un sprint. Deși nu este un instrument de predicție sau comparație, velocity oferă echipelor o idee despre cât de multă muncă se poate face în următorul sprint.

Indicele de viteză este unic pentru fiecare echipă și ar trebui să fie setat pentru a evalua cât de realist este angajamentul. De exemplu, dacă restanța proiectului are 200 de puncte de poveste și, în medie, echipa completează 10 puncte de poveste pe sprint, înseamnă că echipa va necesita aproximativ 20 de sprinturi pentru a finaliza proiectul.

cu cât urmăriți mai mult viteza, cu atât este mai mare acuratețea corespondenței dintre obligații și Costuri

pentru o echipă care tocmai a adoptat metodologia agile sau chiar s-a angajat într-un produs nou, estimările vitezei primelor sprinturi vor fi probabil neregulate. Dar, pe măsură ce echipele câștigă experiență, viteza va atinge vârful și apoi va atinge un platou de flux previzibil și speranță de performanță. O scădere a fluxului consecvent va indica probleme în dezvoltare și va dezvălui nevoia de schimbare.

Sfaturi pentru utilizarea metricii vitezei

combaterea inconsecvenței după 3-5 sprinturi. Dacă viteza rămâne inconsistentă după o perioadă lungă de timp, luați în considerare evaluarea atât a factorilor externi, cât și a celor interni care împiedică estimarea clară.

modificați urmărirea vitezei după modificările echipei și ale sarcinii. Când un membru al echipei părăsește proiectul sau se adaugă mai mulți membri/SARCINI, recalculați viteza sau reporniți Calculul în întregime.

trei sprinturi sunt suficiente pentru previziunile timpurii. Pentru a prezice performanța viitoare, utilizați media celor trei sprinturi anterioare.

Sprint burndown chart

Sprint burndown chart arată cantitatea de muncă rămasă de făcut înainte de sfârșitul unui sprint. Instrumentul este deosebit de valoros, deoarece afișează progresul către obiectiv în loc să listeze elementele finalizate. De asemenea, este foarte util în descoperirea greșelilor de planificare pe care o echipă le-a făcut la începutul unui sprint.

pe graficul de sub linia neagră reprezintă linia prognozată (tendință ideală) care arată rata la care echipa trebuie să ardă punctele de poveste pentru a finaliza sprintul la timp. Linia albastră indică cantitatea totală de muncă și progresul acesteia pe tot parcursul sprintului. Puteți vedea că în zilele cinci și șase, o echipă nu a reușit să realizeze progresul prognozat. Cu toate acestea, în ziua a șaptea, problema a fost abordată și lucrarea a revenit pe drumul cel bun. Astfel de actualizări în curs de desfășurare permit echipelor să abordeze problemele emergente în timpul întâlnirilor zilnice de stand-up.

pe lângă performanța de lucru în sine, diagrame burndown poate dezvălui probleme de planificare

Sfaturi pentru a aborda Sprint burndown

puncte de poveste ar trebui să fie chiar în domeniul de aplicare. Dacă fluxul de lucru nu este consecvent, este posibil ca unele activități să fi fost defalcate în bucăți inegale. Domeniul de aplicare al abaterii dintre o tendință ideală și realitate evidențiază în mod distinct această problemă.

cont pentru sarcini neplanificate. Diagrama burndown este utilă pentru înțelegerea domeniului de aplicare al sarcinilor ascunse și nedescoperite. Dacă volumul de muncă crește în loc să scadă, proiectul are multe sarcini neevaluate sau neplanificate care ar trebui abordate.

utilizați o diagramă burndown pentru a evalua încrederea echipei. Având în vedere tarifele actuale, întrebați echipa dvs. cât de încrezători sunt în ceea ce privește finalizarea sprintului la timp. Cu cât aplicați mai mult această valoare, cu atât sunt mai precise estimările sprintului.

estimarea versiunii cu o diagramă burndown

o diagramă burndown de lansare indică cantitatea de lucru care trebuie finalizată înainte de o versiune. Graficul ilustrează prezentarea generală a progresului și vă permite să implementați modificări pentru a asigura livrarea la timp.

o versiune tradițională a graficului este similară cu diagrama Sprint burndown, dar oferă o imagine de ansamblu asupra întregului proiect în care axa y este sprinturi și axa x este o măsură a muncii rămase (zile, ore sau puncte de poveste). Dar, ce se întâmplă dacă se adaugă mai multă muncă la proiect sau munca estimată nu corespunde așteptărilor?

în graficul de mai jos, o echipă a planificat să finalizeze un proiect în patru sprinturi și a avut inițial 45 de puncte de poveste. În timp ce progresul a decurs conform planificării în timpul primului și al doilea sprint, la al treilea sprint munca estimată a crescut, ceea ce se reflectă pe axa y în valori negative. În timpul celui de-al treilea sprint, au apărut 5 noi puncte de poveste. Nu au fost finalizate, iar al patrulea sprint a adăugat încă 5 puncte de poveste. Prin urmare, progresul și timpul de eliberare trebuiau ajustate.

release burndown chart este foarte eficient pentru situații cu o mulțime de cerințe în schimbare și permite unei echipe să rămână pe drumul cel bun în timpul fiecărui sprint

cum poate ajuta release burndown chart?

predicție în timp real la lansare. Odată ce proiectul dvs. suferă modificări, ceea ce se întâmplă de fiecare dată cu produse în curs de dezvoltare iterativ, trebuie să vedeți cum aceste modificări au impact asupra datei de lansare. Diagrama burndown de lansare permite prezicerea datei de lansare în timp real în funcție de actualizările din domeniul de lucru.

predicții limită. Puteți estima dacă echipa poate finaliza o lansare a produsului la timp sau puteți anticipa că termenul limită ar trebui să se deplaseze în continuare, având în vedere sarcinile adăugate.

estimarea numărului de sprinturi. Evaluarea numărului de sprinturi necesare pentru a termina lucrarea este, de asemenea, un factor important de luat în considerare cu graficul de ardere a lansării.

evaluarea sănătății procesului și găsirea blocajelor

timpul ciclului

metrica timpului ciclului descrie cât timp a fost cheltuit pentru o sarcină, inclusiv de fiecare dată când lucrarea a trebuit redeschisă și finalizată din nou. Calcularea timpului ciclului oferă informații despre performanța generală și permite estimarea finalizării sarcinilor viitoare. În timp ce timpul de ciclu mai scurt ilustrează o performanță mai bună, echipele care livrează într-un ciclu consecvent sunt evaluate cel mai mult.

folosind graficul de mai jos puteți identifica timpul mediu necesar pentru a finaliza o activitate, puteți desena o linie mediană sau limită de control care nu ar trebui depășită și puteți observa ce activități au durat neobișnuit de mult până la finalizare.

abaterea standard trasează o linie între numărul normal și nerecomandat de zile pentru a finaliza activitatea

de asemenea, puteți stiva toate ciclurile pentru o anumită perioadă și puteți extrage informații comparând-o cu alte date. Prin efectuarea unei investigații suplimentare, puteți face concluzii cu privire la calitatea muncii.

aici puteți vedea că numărul de sarcini finalizate din martie până în iunie a crescut, la fel ca și numărul de erori

cum se utilizează timpul ciclului

căutați asemănări. O bună practică este de a găsi elemente similare care necesită perioade de ciclu imprevizibile pentru a fi finalizate, dezvăluind probleme recurente, fie în inginerie, fie în management.

desenați predicții. Puteți lua decizii bazate pe date prin prezicerea timpului pentru a finaliza noi sarcini pe baza celor similare din trecut.

urmăriți ritmul. Diagrama descrie modul în care mențineți același ritm de lucru și definiți dacă există probleme interne care reduc viteza de lucru.

diagrama de flux cumulativă (CFC)

metrica de flux cumulativă este descrisă de zona diagramei care arată numărul de tipuri diferite de sarcini în fiecare etapă a proiectului cu axa x indicând datele și axa y care arată numărul de puncte de poveste. Scopul său principal este de a oferi o vizualizare ușoară a modului în care sarcinile sunt distribuite în diferite etape. Liniile de pe diagramă ar trebui să rămână mai mult sau mai puțin uniforme, în timp ce trupa cu sarcinile „terminate” ar trebui să crească continuu.

graficul prezintă o mulțime de informații critice, cum ar fi blocaje bruște sau creșteri în oricare dintre benzile

CFC va fi de mare folos pentru echipele Kanban ca o simplă vizualizare a muncii echipei. Graficul corespunde, de asemenea, fluxului de lucru în trei pași al Kanban. Aici, de asemenea, harta trei categorii principale DE SARCINI: to-do, în curs de desfășurare, și finalizat.

mai mult, graficul ajută la identificarea momentului în care limitele work-in-progress (WIP) sunt depășite. Fiind unul dintre cele mai valoroase instrumente în dezvoltarea agilă, limitele WIP sunt menite să cultive cultura lucrărilor de finisare și să elimine multitasking-ul prin stabilirea cantității maxime de lucru pentru fiecare stare a proiectului.

ce probleme sunt subliniate de CFC?

• creșterea întârzierilor indică sarcinile nerezolvate care sunt fie o prioritate prea mică pentru a fi abordate în acest moment, fie sunt depășite
• fluxul inconsecvent și blocajele bruște indică zonele care ar trebui netezite în etapele ulterioare
• lățimea fiecărei benzi arată timpul mediu al ciclului
• lărgirea semnificativă a zonei „în curs” poate însemna că echipa nu va putea termina ciclul de lucru întregul proiect la timp

eficiența fluxului

eficiența fluxului este o metrică foarte utilă în dezvoltarea Kanban, cea mai mare parte trecută cu vederea de dezvoltare Echipe. În timp ce eficiența fluxului completează fluxul cumulativ, oferă informații despre distribuția dintre perioadele efective de lucru și perioadele de așteptare. Este un caz rar când un dezvoltator lucrează la un singur lucru la un moment dat fără să aștepte. Realitatea este de obicei mai complexă. Și „work-in-progress” este un nume care nu se potrivește întotdeauna cu statutul.

de exemplu, codul poate avea multe dependențe și nu puteți începe să lucrați cu o caracteristică înainte ca alta să fie terminată sau prioritățile dvs. să se schimbe sau așteptați aprobarea părților interesate. Măsurarea timpului pe care îl așteptați împotriva muncii poate fi chiar mai utilă decât eficientizarea proceselor legate de munca reală.

analizând indicatorii de eficiență cei mai mici, puteți înțelege principalele blocaje

cum se utilizează formula de calcul a eficienței fluxului

. Dacă nu aplicați un software de management de proiect care încorporează aceste valori, puteți calcula eficiența fluxului prin această formulă simplă: Work/(work+wait) * 100%. Apoi îl puteți vizualiza digital sau chiar puteți desena graficul pe tabla albă de birou.

definiți eficiența normală a debitului. Ca și în cazul tuturor celorlalte valori, este imposibil să revendicați cifre normale pentru toate proiectele. Unii spun că nota de 15% este în regulă pentru majoritatea proiectelor, ceea ce înseamnă practic că un punct de poveste sau un alt articol de lucru așteaptă 85% față de 15% Timp de procesare. David J. Anderson, expert în management de la școala de Management LeanKanban, sugerează că 40% și mai mult ar trebui să fie ținta pentru majoritatea echipelor.

descompune detalii de lucru înainte de a stabili eficiența fluxului. Graficul va permite vizualizarea perioadelor exacte de timp în care eficiența dvs. a fost cea mai mică. Și aceste date trebuie analizate foarte atent, deoarece cauza reală și remedierea ei nu sunt dezvăluite atât de ușor. Înainte de a începe acțiuni intense, faceți o investigație amănunțită a cauzelor.

măriți eficiența fluxului cu analiza blocantului. Un bun mijloc de a realiza punctul anterior este de a spori eficiența fluxului cu analiza blocant clustering. Dacă unele lucrări sunt blocate, merită un autocolant colorat sau o altă formă de semnal vizual pentru a aduce aceste blocante în atenția echipei, astfel încât să poată reacționa la ele.

puteți marca câte zile o parte din lucrare este blocată și puteți acorda prioritate rezoluției

de obicei, blocanții se acumulează în clustere, deoarece au multe dependențe între ele. O mai bună analiză a blocanților se poate face dacă le clusterizați pornind de la asemănări la nivel înalt, cum ar fi blocante interne și externe și apoi specificând în continuare prin design, conținut lipsă sau alte caracteristici lipsite. Analiza Blocker este o modalitate simplă de a investiga văile în eficiența fluxului.

măsurarea calității codului

acoperirea Codului

acoperirea Codului definește câte linii de cod sau blocuri sunt executate în timpul rulării testelor automate. Acoperirea codului este o valoare critică pentru practica de dezvoltare bazată pe teste (TDD) și livrarea continuă. În mod tradițional, metrica este interpretată printr-o abordare simplă: cu cât acoperirea codului este mai mare, cu atât mai bine. Pentru a măsura acest lucru, veți avea nevoie de unul dintre instrumentele disponibile, cum ar fi salopetele. Dar toate funcționează cam la fel: pe măsură ce executați teste, instrumentul va detecta care dintre liniile de cod sunt numite cel puțin o dată. Procentul de linii numite este acoperirea codului.

combinezoane, de exemplu, va rupe în jos acoperirea cod la fiecare măsurare fișier și de a evidenția linii acoperite și neacoperite

cum se utilizează acoperire cod

se concentreze pe linii neacoperite și nu supraestima cele acoperite. Dacă linia de cod este apelată o dată sau chiar mai mult, nu înseamnă neapărat că funcția pe care o acceptă funcționează perfect și utilizatorii vor rămâne mulțumiți. Apelarea unei linii de cod nu este întotdeauna suficientă pentru a închide sarcina de testare. Pe de altă parte, procentul de linii neacoperite arată ceea ce nu a fost acoperit deloc și poate merita testarea.

prioritizează codul acoperit și nu vizează 100%. Deși acest lucru pare contraintuitiv, acoperirea 100% nu înseamnă că ați testat corect codul. Proiectul dvs. are codul care contează și restul unei baze de cod. Deoarece automatizarea testării este de obicei o inițiativă costisitoare, ar trebui să acorde prioritate caracteristicilor și bucăților de cod corespunzătoare.

test automation against manual testing

această măsurătoare definește câte linii de cod dintr-o caracteristică sunt deja acoperite cu teste automate împotriva celor care sunt testate manual. Aceasta urmează direct metrica anterioară, dar are un caz de utilizare specific. Proporția de automatizare a testului împotriva testării manuale este utilizată numai atunci când aveți nevoie critică de automatizare pentru a acoperi regresiile. Testarea regresiei se face pentru a verifica dacă ceva s-a rupt după actualizările caracteristicilor. Și dacă produsul dvs. suferă îmbunătățiri constante – ceea ce ar trebui-testarea regresiei ar trebui automatizată. Dacă nu este, specialiștii dvs. de QA manual vor trebui să repete aceleași scenarii de testare în mod repetat după fiecare comitere de actualizare.

puteți utiliza aceleași instrumente utilizate pentru acoperirea codului pentru a desena această valoare

conturarea acoperirii automate a testului pe caracteristică vă va permite să acordați prioritate caracteristicilor care 1) pot suferi de regresie după actualizări și 2) pentru care testele automate sunt critice. De obicei, nu aveți suficient timp și resurse umane pentru a acoperi totul prin teste automate simultan, cu excepția cazului în care lucrați în cadrul de dezvoltare bazat pe teste. Deci, este mai bine să acordați prioritate caracteristicilor care vor afecta cu siguranță experiența utilizatorului.

complexitatea Ciclomatică McCabe (MCC) a codului

măsurătorile de complexitate a Codului sunt utilizate pentru a evalua riscurile de probleme în timpul testării și întreținerii codului. Cu cât complexitatea codului este mai mare, cu atât devine mai dificil să se asigure că are un număr acceptabil de erori și păstrează o întreținere ridicată. Cea mai comună abordare a măsurării complexității codului este metrica complexității Ciclomatice McCabe (MCC). Una dintre formulele pentru a atrage rezultate de complexitate pentru MCC este următoarea:

MCC = margini-noduri + declarații de retur

MCC pe imagine este egal cu 3

cu această valoare, dezvoltatorii nu sunt estimarea complexitatea lor cod de subiectiv uita la ea. Pe măsură ce abilitățile inginerilor diferă, evaluările lor variază, ceea ce face ca refactorizarea codului sau remedierea erorilor să fie mai dificilă pe termen lung. Există multe instrumente de măsurare MCC pe piață care pot fi combinate cu alte valori de complexitate a codului, cum ar fi adâncimea ierarhiei codului și numărul de linii de cod.

MCC utilizează specificul și capcanele

echilibrează percepția umană și mașină a complexității codului. Unul dintre principalele motive pentru a utiliza MCC este de a face codul lizibil pentru colegii Dezvoltatori. Lizibilitatea codului reduce riscurile de integrare pe termen lung a noilor dezvoltatori care trebuie să se ocupe de codul vechi. De asemenea, va simplifica refactorizarea pe drum. Problema aici este că modelul MCC poate considera inacceptabile unele metode complexe, dar lizibile. Și dacă forțați un dezvoltator să refactorizeze metode complexe în multe sub-metode, puteți obține rezultate opuse: multe metode cu logică simplă pot deveni și mai dificil de înțeles pentru un om decât o singură metodă, dar complexă.

nu faceți din MCC o metrică restrictivă. Unele organizații practică comiterea codului de terminare care nu trece testul MCC. Deși acest lucru poate crește simplitatea codului, este firesc să aveți cod complex la nivelurile claselor, metodelor și funcțiilor. Blocarea lor în întregime nu este întotdeauna benefică. O bună practică este de a stabili KPI de complexitate generală a codului pentru dezvoltatori, ceea ce îi va încuraja să abordeze codificarea mai conștient și să se gândească la simplitate.

aplicați MCC pentru revizuirea codului. O altă practică valoroasă pentru testele MCC este aplicarea acesteia în timpul revizuirilor de cod pentru a restrânge domeniul de activitate la revizuirea bucăților de cod specifice în care riscurile de defecte sunt cele mai mari.

Cod putinei

Cod putinei este o vizualizare foarte util de tendințe și fluctuații care se întâmplă la o bază de cod, atât în ceea ce privește procesul de ansamblu și timpul înainte de o versiune. Putinei măsoară cât de multe linii de cod au fost adăugate, eliminate, sau modificate. Uneori graficele arată toate cele trei măsurători.

acest exemplu de la Microsoft include toate cele trei parametri, dar le puteți utiliza selectiv

deși Cod putinei de urmărire poate părea o metrică oarecum primitiv, permite evaluarea stabilității cod la diferite stadii de dezvoltare. Ar trebui să vă așteptați la cea mai mică stabilitate în timpul sprinturilor timpurii și la cea mai mare stabilitate – cu cea mai mică putină concomitentă – chiar înainte de eliberare. Dacă codul dvs. este extrem de instabil și data lansării se apropie, sună alarma.

Cod putinei cazuri de utilizare

uita-te pentru regularități. Vârfurile regulate ale modificărilor de cod pot dezvălui că abordarea generării de sarcini nu este suficient de concentrată și produce multe sarcini mari în mod recurent.

vârfurile neregulate, dar înalte necesită investigații. Dacă aveți vârfuri neregulate, dar puternice în modificările de cod, puteți investiga ce sarcini au cauzat astfel de vârfuri seismice în codul dvs. și puteți reconsidera nivelul dependențelor, mai ales dacă numărul de linii de cod noi a crescut și numărul de linii modificate.

acordați atenție tendințelor. Stabilitatea produsului dvs. devine destul de critică înainte de lansare. După cum am menționat, rata de putinei ar trebui să aibă o tendință de scădere mai aproape echipa ta ajunge la o eliberare. O tendință de creștere înseamnă o posibilă instabilitate a produsului după lansare, deoarece este probabil ca noul Cod să nu fie supus unor teste suficiente.

urmărește progresul, nu controlează

la fel ca orice alți indicatori de performanță, valorile agile nu au întotdeauna răspunsuri distincte sau sfaturi acționabile care să vă sigileze succesul. Cu toate acestea, ar trebui să utilizați cunoștințele pe care le oferă pentru a începe o discuție, pentru a efectua o evaluare și pentru a vă oferi propriul plan în abordarea problemelor problematice.

în timp ce valorile oferă o perspectivă numerică asupra performanței unei echipe și a satisfacției generale cu munca, nu vă fixați pe ele. Având în vedere că valorile agile nu sunt standardizate, nu are rost să comparăm succesele diferitelor echipe. Mai degrabă asigurați-vă că îmbrățișați feedback-ul echipei dvs., inițiați discuții regulate și hrăniți o atmosferă de obiective și sprijin comune.