Măsurați sistemul de livrare

Începeți cu decizia necesară

O echipă dorește să știe dacă AI îmbunătățește livrarea. Numărarea liniilor generate răspunde la altă întrebare. Definiți rezultatul util și condițiile de calitate înainte de a alege un indicator.

Pentru un serviciu fictiv de export, rezultatul dorit este livrarea fiabilă a modificărilor acceptate, cu mai puțin efort total. Notați pregătirea, implementarea, verificarea, corectarea și așteptarea. Includeți modificările eșuate sau abandonate.

Folosiți un singur serviciu cu o limită clară. Combinarea unui site experimental cu un serviciu critic de plăți poate produce un număr care nu explică niciunul. Descrieți contextul înainte de a compara perioade sau echipe.

Folosiți definițiile actuale

Modelul actual de livrare DORA conține cinci indicatori. Domeniul lor este performanța livrării, nu valoarea fiecărei funcționalități sau contribuția unei persoane. Definițiile indicatorilor DORA.

Un panou de bord poate folosi altă definiție. Citiți-o înainte de a interpreta rezultatul. Documentația actuală Taiga despre instalări descrie patru indicatori raportați, derivați din înregistrările instalărilor furnizorului. Indicatorul său de recuperare folosește o instalare ulterioară reușită. Aceasta nu este o evidență completă a fiecărui incident din producție. Definițiile Taiga.

Inspectați o secvență fictivă de modificări

Să presupunem că un serviciu face douăsprezece instalări într-o lună. Opt livrează modificări planificate. Patru repară probleme ale lansărilor anterioare. Numărul este doisprezece, dar compoziția contează.

Luna următoare, echipa face zece instalări: nouă modificări planificate și o reparație. Mai puține instalări pot coexista cu mai mult lucru util. Cifrele ilustrează interpretarea; nu sunt un benchmark de performanță.

Inspectați și distribuția. O așteptare lungă pentru verificare poate dispărea într-o medie. O măsurare a recuperării dintr-o singură defecțiune este o dovadă slabă pentru fiabilitatea viitoare. Raportați numărul observațiilor și excepțiile importante.

Legați fluxul de consecințe

Folosiți semnalele serviciului pentru a verifica dacă schimbările livrării afectează utilizatorii. Un pipeline mai rapid nu este suficient dacă exporturile eșuează mai des. Folosiți un SLO adecvat sau alt indicator de rezultat clar definit. Ghidul SLO.

Efortul de verificare și refacerea lucrului ajută la explicarea rezultatului. Dacă AI scurtează implementarea, dar produce diff-uri mari, verificarea poate deveni constrângerea. Dacă obținerea mediilor durează zile, programarea mai rapidă poate avea puțin efect asupra timpului scurs până la livrare.

Alegeți o îmbunătățire care tratează constrângerea observată. De exemplu, oferiți un mediu de testare susținut sau reduceți dimensiunea unei modificări. Definiți un indicator complementar de calitate, pentru ca echipa să detecteze un aparent câștig de viteză cauzat de verificări mai slabe.

Păstrați măsurarea utilă

Evitați clasamentele individuale bazate pe numărul de PR-uri sau codul generat. Aceste măsuri pot recompensa împărțirea artificială a lucrului, evitarea mentenanței dificile sau transferarea efortului de verificare către colegi.

Analizați rezultatul cu persoanele responsabile de serviciul complet. Consemnați ce s-a schimbat în instrument, tipurile de lucru, echipă și mediu. Tratați comparația înainte-după ca dovadă cu limite, nu ca probă automată de cauzalitate.

Scopul este o decizie următoare mai bună. O măsurare mică și fiabilă, care duce la o îmbunătățire verificată, este mai utilă decât un panou mare fără un sens convenit.

Exersați cu zece modificări

Acest set separat de date fictive consemnează zece modificări planificate. Toate orele sunt UTC în data indicată. Un câmp gol pentru corecție înseamnă că în acest set de date nu a fost consemnată nicio corecție.

Comparați timpul dintre codul pregătit și începutul verificării, apoi timpul dintre acceptare și lansare. Identificați cea mai lungă așteptare vizibilă. Investigați cauza înainte de a o numi evitabilă. Aceste ore nu măsoară efortul activ și nu identifică momentul începerii unui incident. O lansare de corecție nu poate stabili singură timpul de recuperare după o instalare eșuată.

Descărcați setul de date fictive (CSV)