17 valori Agile importante de care ar trebui să-și pese echipa ta

Metricurile au fost mult timp un punct de dezbatere de către agiliști.

În ciuda faptului că dezvoltarea agilă este empirică din cauza furnizării continue de software de calitate, birourile PMO, managerii de proiect și clienții deopotrivă solicită în continuare raportări detaliate de stare, așa cum ar face-o pentru orice proiect bazat pe cascadă. Deși nevoia de afaceri este un motiv pentru supraveghere, dezvoltarea agilă în sine contribuie la un nivel de incertitudine pe care unii oameni doresc întotdeauna să-l reducă.

În efortul de a contracara această tendință, mulți agilisti susțin că măsurătorile nu ar trebui folosite deloc și că numai producția de software în sine ar trebui considerată criteriul succesului. Susținătorii acestei abordări susțin că echipele de dezvoltare și managerii de proiect vor juca instinctiv sistemul manipulând poveștile utilizatorilor și estimările astfel încât să producă aparența de eficiență ridicată și să ascundă problemele reale. Cu toate acestea, există un adagiu care spune că ceea ce se măsoară, se face.

Principalul motiv pentru care apare acest joc este că organizațiile se bazează prea mult pe una sau două valori, în loc să aibă o soluție cuprinzătoare de măsurători. În acest articol, vom discuta despre valorile dovedite că produc cea mai bună inteligență disponibilă privind performanța echipei, calitatea, valoarea și chiar agilitatea. Vom vorbi chiar și despre unele valori despre care poate nu ați auzit niciodată, pe baza celor mai recente cercetări și a celor mai inovatoare studii de caz.

Pentru ce sunt folosite valorile agile?

Valorile agile sunt folosite pentru a urmări starea, calitatea, productivitatea, eficiența, valoarea și chiar agilitatea în sine. Cel mai important, ele sunt folosite pentru a informa deciziile de afaceri. Indiferent de tipul de proiect la care lucrați, raportarea va fi întotdeauna importantă atât pentru părțile interesate externe, cât și interne. Metricurile pot avea un impact asupra deciziilor la toate nivelurile, de la managementul produselor până la managementul personalului și, ca atare, trebuie să fie precise, informative și impartiale. Înainte de a ne aprofunda în metrici, trebuie mai întâi să stabilim o bază pe care se bazează toate astfel de măsurători.

Triunghiul de fier vs. Triunghiul Agil

În abordările bazate pe plan, măsurătorile s-au bazat pe vechiul „triunghi de fier” al scopului, programului și costului. Majoritatea fiecărei valori se încadrează în una dintre aceste trei categorii. În lumea agilă, acest triunghi a fost răsturnat. Proiectele sunt definite prin furnizarea de valoare și calitate în cadrul anumitor constrângeri. Bugetul sau costul este doar una dintre aceste constrângeri, printre altele, spre deosebire de a fi un obiectiv principal pentru livrare.

Este important aici să înțelegem relația dintre valoare și calitate. Mulți oameni se luptă cu definirea valorii. În primul rând, există două tipuri de calitate: intrinsecă și extrinsecă.

• Calitatea intrinsecă se referă la percepția internă a produsului de către echipele de dezvoltare, testare și management. De obicei, este ilustrat cu valori de defect, pe care le descriem mai târziu.
• Calitatea extrinsecă este calitatea produsului așa cum este percepută de utilizatorul final. Cât de bine se potrivește produsul nevoilor lor și satisface așteptările. Un alt termen pentru această calitate extrinsecă este valoarea.

Deci, este important să înțelegem că calitatea, așa cum este descrisă în triunghiul agil, este calitate intrinsecă sau internă din punct de vedere al dezvoltării, în timp ce valoarea în triunghi este într-adevăr o formă de calitate extrinsecă. Înțelegerea acestei relații este importantă pentru dezvoltarea unor măsuri agile bune.

17 valori cheie agile de urmărit

Următoarea listă de șaptesprezece valori combină valorile agile cele mai frecvent utilizate și respectate de timp cu măsuri mai noi bazate pe cercetări recente. Principala concluzie aici este că orice soluție de măsurare agilă ar trebui să fie cuprinzătoare.

Bazându-te pe doar una sau două, nu va oferi o imagine completă a ceea ce se întâmplă. Cea mai mare greșeală pe care o fac mulți manageri este să se concentreze prea mult pe două sau trei, sau doar pe o singură măsură pentru întregul lor proiect. Unele organizații nu folosesc altceva decât diagrame de viteză sau arde.

Credeți sau nu, se întâmplă. O soluție de metrică bună ar trebui să acopere toate cele trei puncte ale triunghiului agil. Aceste 17 vă vor oferi instrumentele pentru a face exact asta și multe altele.

Timp blocat

Timpul blocat este definit ca perioada de timp în care o anumită poveste de utilizator – sau uneori o sarcină – este blocată. Rezolvarea blocajelor este esențială pentru a facilita fluxul de lucru într-un mediu agil, iar această măsurătoare poate ajuta la măsurarea timpului necesar pentru a le rezolva. Blocajele ar trebui rezolvate rapid.

Creșterea timpului blocat ar putea însemna că o poveste de utilizator nu a fost descompusă corespunzător sau că există o dependență de o resursă externă care a fost neplanificată. Timpul blocat poate fi redus cu o descompunere mai atentă a poveștii utilizatorului, prioritizarea și planificarea sprintului.

Elanul afacerii

Multe dintre valorile discutate aici există de ceva timp. Majoritatea sunt concentrate la nivel de proiect, echipă sau WIP (lucru în curs). Cu toate acestea, pe măsură ce tehnologia este mai integrată în viața noastră de zi cu zi și piețele pentru acele produse devin hiper-accelerate, organizațiile caută valori mai sofisticate care să identifice tendințele pieței, să evalueze îmbunătățirea procesului, să prezică concurența și, în esență, să măsoare agilitatea. Momentul afacerilor este unul dintre acestea. Momentul în acest context poate fi exprimat prin numărul total de puncte pentru o lansare înmulțit cu cronologia acesteia.

Pe măsură ce o organizație devine mai agilă, ea câștigă avânt cu fiecare lansare. Timpii ciclului tind să se scurteze, iar așteptările privind livrarea cresc. Momentul afacerii poate fi folosit pentru sincronizarea pieței sau ca un indicator al stării de sănătate a unei anumite linii de produse sau a unui program. Dacă impulsul începe să scadă, acesta este un indicator pentru management că o anumită piață începe să se desfășoare și o nouă linie de produse trebuie dezvoltată. Organizațiile agile trebuie să caute continuu noi piețe pentru a rămâne competitive.

Acoperirea codului

Acoperirea codului este o măsură a cât de mult din cod este de fapt executat în timpul testării. Acesta este de obicei instrumentat și calculat ca parte a unei strategii de testare automată. Metrica ar trebui să furnizeze procentul total de cod executat în timpul fiecărei etape de testare (unitate, sistem etc.), precum și un total al tuturor fazelor.

Acoperirea codului nu ar trebui folosită greșit ca un indicator pentru cât de bine a fost testat un produs. Mai degrabă, scopul acestei metrici este de a facilita automatizarea testelor și de a monitoriza livrarea continuă. Măsurătorile de asigurare a calității ar trebui să includă o varietate de metrici, dintre care nu în ultimul rând sunt aparițiile defectelor discutate mai târziu.

Grafic de control

Denumită uneori un proces-comportament sau diagramă Shewhart, o diagramă de control monitorizează performanța unui proces pentru a determina dacă este sub control sau nu este sub control – în funcție de limitele superioare, inferioare și medii de control care au fost stabilite.

Aceste limite sunt calculate prin estimarea abaterii standard a datelor eșantionului, înmulțind acea abatere cu trei, apoi adăugând-o la medie pentru a crea limita superioară și scăzând-o din medie pentru a crea limita inferioară. Axa Y a diagramei este numărul de apariții sau probleme dintr-un anumit eșantion, în timp ce axa X enumeră fiecare eșantion. Diagramele de control au apărut în producție ca o formă de control al calității și există de aproape 100 de ani.

Populare printre discipolii six sigma, diagramele de control pot măsura eșecul sau succesul controlului calității sau al altor procese de fabricație. Deși nu sunt populare în lumea agilă, diagramele de control ar putea fi folosite pentru a măsura defectele găsite pe iterație sau lansare pentru a identifica problemele de testare a QA sau pentru a măsura timpii de ciclu pentru o serie de versiuni pentru a se asigura că se încadrează în niveluri acceptabile.

Diagrama fluxului cumulativ

O diagramă de flux cumulativă ilustrează cât de multă muncă, segmentată după tip, este alocată unei echipe în timp. Scopul său este de a monitoriza cât de bine curge munca în sistem. În această diagramă, munca este împărțită în diferite tipuri, de exemplu: de făcut, în curs și terminat. De asemenea, ar putea fi împărțit în cerințe, dezvoltare, testare și așa mai departe. Oricum este segmentată, diagrama de flux cumulativă arată o linie pentru fiecare tip de lucru, numărul de articole de lucru de pe axa Y și axa X fiind o funcție de timp.

Fluxul bun este ilustrat de toate aceste linii care rulează în paralel. Dacă una dintre linii se confruntă cu o creștere bruscă sau trece peste alta, acest lucru ar putea indica un blocaj. Obținerea unui flux bun este conceptul central din spatele kanban. Diagrama de flux cumulativ ajută la identificarea blocajelor pentru a facilita fluxul continuu și pentru a se asigura că WIP nu scăpa de sub control în niciun punct al sistemului.

Durata ciclului

Durata ciclului poate fi definită ca timp pentru a produce o lansare de software, de la concept până la finalizare. Împreună cu timpul și viteza, timpul ciclului este un indicator foarte bun de nivel înalt al sănătății agile și al succesului transformării agile. Pe măsură ce o organizație progresează în călătoria sa agilă, durata ciclului ar trebui să scadă treptat, de obicei la șase luni sau mult mai puțin. Creșterile duratei ciclului, în special atunci când sunt observate în mod constant peste una sau două versiuni, ar trebui să fie un motiv de îngrijorare și revizuire.

Epic și eliberați arderea

Diagramele de ardere epice și de lansare sunt similare cu burndown-ul de sprint mereu popular, discutat mai jos. Un grafic de ardere ilustrează cât de multă muncă rămâne pentru o anumită perioadă de timp sau, în acest exemplu, pentru o anumită epopee. În dezvoltarea agilă, o epopee este o poveste de utilizator mai mare, compusă din povești mai mici ale utilizatorilor sau bucăți de muncă.

Pe măsură ce munca este finalizată, numărul de povești ale utilizatorilor din epopee este redus treptat până ajunge la zero. Acest lucru poate fi util în cazurile în care trebuie atinse etape pentru a îndeplini cerințele contractuale și pentru a factura clientul. În mod similar, o ardere a versiunii poate urmări progresul muncii angajate pentru o anumită ediție. Aceasta poate fi folosită pentru a asigura livrarea la timp sau pentru a identifica necesitatea de a modifica din timp un termen limită.

Implementări eșuate

O implementare eșuată este una care are ca rezultat oricare dintre următoarele:

• Serviciul care afectează întrerupere
• Nu îndeplinește așteptările clienților, ducând adesea la respingerea versiunii.
• Afectează grav capacitatea de utilizare, funcționarea sau experiența utilizatorului produsului.
• Rezultă o revenire la versiunea anterioară.

Evident, rata de implementare eșuată, afișată ca procent din totalul implementărilor, ar trebui să fie menținută la minimum. Orice creștere a acestei valori ar trebui să fie un motiv de îngrijorare. Ratele de schimbare și apariția defectelor trebuie revizuite pentru a izola cauzele fundamentale.

Perioada de graţie

Timpul de livrare măsoară timpul necesar pentru a finaliza o sarcină, din momentul în care este creată și până la punctul în care este finalizată. Pe scurt, identifică cât timp este nevoie pentru a face lucrurile. Populară printre practicanții kanban, această măsurătoare poate ajuta la identificarea eficienței pentru a muta sarcinile mai rapid prin sistem. Poate fi folosit și ca măsurătoare de nivel înalt pentru a determina cât de bine funcționează livrarea continuă. Timpul de livrare, împreună cu timpul și viteza ciclului, pot fi utilizate împreună pentru a oferi o imagine holistică a performanței livrării.

Scorul net al promotorului (NPS)

Un scor net de promovare este menit să ajute la evaluarea satisfacției clienților. De obicei, este calculat pe baza datelor obținute printr-un sondaj. Scopul este de a afla câți clienți ți-ar recomanda produsul. Procentul de respondenți care votează „nu” este scăzut din alegătorii „da” pentru a crea scorul.

Pe lângă măsurarea satisfacției clienților, scorul net al promotorului poate ajuta la identificarea clienților mai dispuși să colaboreze la produse sau tehnologii inovatoare pentru lansările viitoare. Astfel de clienți pot deveni un avantaj competitiv, deoarece feedbackul și suportul lor pot ajuta companiile să introducă produse noi pe piață înainte ca concurența să o facă.

Inteligență de calitate

La începutul articolului am discutat despre triunghiul agil și rolul pe care îl joacă calitatea în el. Inteligența calității poate lua mai multe forme, dar este compusă de obicei dintr-o varietate de valori de urmărire a defectelor. Defectele pot fi monitorizate pe baza locului și când apar, frecvența și gravitatea lor.

Una dintre cele mai populare este rata de evadare a defectelor, care este raportul dintre defectele găsite de client și numărul total de defecte descoperite într-o versiune. Deși un număr mare de defecte ar trebui să fie îngrijorător, indiferent de modul în care sunt găsite, este întotdeauna cel mai bine să le detectați înainte ca clientul să o facă.

Sprint burndown

Diagramele de ardere de sprint oferă o măsură zilnică a muncii care este finalizată și a muncii care rămâne de făcut într-un sprint dat. Acesta compară cantitatea de muncă finalizată cu estimările inițiale. Datorită naturii empirice a dezvoltării agile, valoarea diagramei de ardere este destul de limitată.

În ciuda popularității sale, mulți antrenori agili se îndepărtează de a-l folosi la fel de mult ca înainte. Poate servi ca un ghid bun sau un punct de stare pentru situațiile în care echipele de dezvoltare se opun angajamentelor lor, dar ar trebui folosit în tandem cu alte valori pentru a obține o imagine completă a ceea ce se întâmplă.

Debit

Cantitatea de produs (numărul de articole de lucru) livrată clientului într-o anumită unitate de timp este denumită debit. Acest lucru poate fi măsurat lunar, trimestrial, per lansare, iterație și așa mai departe. Valoarea acestei valori este că poate fi folosită pentru a determina cât de mult software poate fi livrat pentru un anumit interval de timp. De asemenea, poate fi folosit pentru a urmări consistența livrării dintr-o perspectivă de echipă și organizațională.

Analiza empirică a datelor istorice poate fi utilizată pentru a estima performanța livrării. Cu cât sunt mai multe date istorice disponibile, cu atât sunt probabil mai precise proiecțiile. Cel mai important, această măsurătoare poate fi utilizată și pentru a prognoza veniturile, având în vedere că valoarea funcționalității caracteristicilor furnizate este bine înțeleasă în termeni financiari. Pentru ca această măsură să funcționeze, definiția „terminat” trebuie să fie bine definită. Doar software-ul livrat clientului îndeplinește această cerință.

Valoare livrată

La începutul articolului am discutat despre modul în care valoarea constă în calitatea extrinsecă, sau percepția produsului de la utilizatorul final. Cum influențează produsul afacerea clientului? Valorile agile bune se bazează pe rezultate, iar în lumea afacerilor, asta se traduce de obicei în dolari și cenți. Așa cum atribuim puncte de poveste fiecărei povești de utilizator ca o modalitate de a estima munca necesară, putem, de asemenea, adăuga puncte de valoare ca măsură relativă pentru a indica ceea ce primește utilizatorul final când lucrarea este terminată.

O modalitate de a face acest lucru este cu o diagramă de ardere care ilustrează numărul de puncte de valoare acumulate pe măsură ce fiecare poveste este finalizată. Punctele de valoare pot fi atribuite fiecărei povești sau caracteristici pe baza percepției clienților pe măsură ce sunt create criteriile de acceptare. Venitul așteptat (sau banii economisiți) pentru client în cadrul proiectului poate fi împărțit la numărul total de puncte valorice din ediție.

De exemplu, dacă există 200 de puncte de valoare într-un proiect și se așteaptă ca clientul să câștige 1 milion de dolari în venituri, atunci fiecare punct de valoare valorează 5.000 de dolari. Suma totală a fiecărei povești și valoarea lor acumulată pot fi ilustrate în graficul de ardere. Deși impactul real al produsului poate să nu fie evident până la lansare, această metodă poate oferi informații financiare convingătoare atât pentru management, cât și pentru clienți.

Viteză

Viteza este probabil prima măsurătoare despre care aud cei mai mulți dintre noi după ce am fost introduși în dezvoltarea agilă. Deși este probabil cea mai populară măsură agilă, este și cea mai utilizată greșit. Echipele de sprint sunt renumite pentru viteza de joc, deoarece se bazează foarte mult pe ea pentru raportarea performanței lor. Viteza este definită ca cantitatea de software produsă în fiecare iterație sau sprint. Această cantitate este de obicei exprimată ca puncte de poveste, iar software-ul produs trebuie să fie o porțiune de cod funcțională gata de producție.

Echipele deseori viteza jocului prin manipularea dimensiunii și estimarea poveștilor utilizatorilor sau prin descompunerea lucrărilor pe orizontală, în loc de verticală, prin crearea de povești pentru modificările bazei de date, lucrul frontal, middleware și multe altele. pentru a elimina dependențele de alții și pentru a obține credit pentru finalizarea muncii. Problema cu această abordare este că aceste tipuri de povești ale utilizatorilor sunt într-adevăr sarcini și, deși echipele primesc credit, valoarea afacerii pentru client nu a fost livrată.

Viteza jocului poate fi prevenită folosind o serie de alte valori ca un control și echilibru unul față de celălalt. De prea multe ori organizațiile se bazează numai pe viteză sau pe un set foarte mic de metrici, în loc de o suită mai mare de măsurători pentru a forma o soluție PPM, program și management de proiect.

Vorticitate (agil)

O întrebare cu care se luptă mulți agilisti și manageri de proiect este „cât de agile suntem?” De fapt, căutarea răspunsului la măsurarea agilității în sine a fost sfântul Graal al agiliștilor de pretutindeni. Vorticitatea agilă este o măsură nouă care face exact asta. Pe baza a peste 10 ani de cercetare a studiilor de caz, vorticitatea agilă a fost dezvoltată printr-o metodă calitativă sofisticată numită teoria fundamentată.

Folosind un set cuprinzător de măsuri, agilitatea pieței și a procesului organizațional poate fi măsurată una față de cealaltă pentru a determina vorticitatea lor sau punctul în care converg. Vorticitatea zero înseamnă că agilitatea organizației se potrivește cu piața. Vorticitatea mare înseamnă că piața se mișcă mult mai repede decât organizația sau echipele dvs. și, prin urmare, este mult de lucru. Infograficul de mai jos demonstrează această relație folosind un experiment de gândire vârtej pentru a ilustra piețele hiper-accelerate de astăzi.

Vârsta articolului de lucru

Un articol de lucru ar putea fi definit ca un pachet de lucru, caracteristică utilizabilă sau, așa cum ar fi în majoritatea contextelor agile, o poveste de utilizator. Ceasul începe să ticăie vârsta unui articol de lucru de îndată ce acesta este conceput pentru prima dată. Urmărirea vechimii elementelor de lucru, indiferent dacă acestea sunt în curs de desfășurare sau sunt în așteptare, poate ajuta la identificarea problemelor cu cerințele.

Dacă un articol de lucru pare să devină mai vechi decât rudele lui, deoarece este împins de la un sprint la altul, ar putea exista o problemă cu descompunerea. Poate că trebuie redefinit sau mai bine înțeles? Este posibil ca articolele de lucru care stau în așteptare pentru perioade lungi de timp să fie eliminate sau redefinite.

Îngrijirea continuă a restanțelor este esențială pentru planificarea și prioritizarea sprintului. Un număr tot mai mare de cerințe de îmbătrânire în stoc ar putea însemna probleme cu modul în care cerințele sunt dezvoltate și descompuse. Managementul defectuos al cerințelor este una dintre cauzele principale ale eșecului în transformările agile.

Cerințele scrise prost pot face ca prioritizarea și estimarea să fie extrem de dificile, ducând la datorii tehnice scăpate de sub control, utilizarea scăzută a caracteristicilor și pierderi financiare. Dezvoltarea cerințelor bine înțelese, prioritizate și de mare valoare este în mare măsură o formă de artă și prost înțeleasă chiar și de cei mai buni dintre agilisti. Într-adevăr, este, fără îndoială, unul dintre cei mai mari blocanți pentru succesul transformării agile.

Concluzie

În acest articol, am stabilit fundația pentru valorile agile, necesitatea unei soluții cuprinzătoare și 17 recomandări pentru a crea una. Indiferent dacă utilizați toate măsurătorile discutate sau doar un subset, este important ca orice soluție să ia în considerare publicul pentru date. Unele valori, cum ar fi viteza, sunt cel mai bine păstrate în cadrul echipelor scrum. Alte valori, cum ar fi vorticitatea agilă și impulsul afacerii, sunt concepute pentru managementul executiv sau, respectiv, de produs.

Asigurați-vă întotdeauna că înțelegeți pe deplin și comunicați cu acuratețe ceea ce spun valorile și urmăriți unde duc datele. O modalitate de a genera și susține valori bune este cu un cadru robust agil.