Mät leveranssystemet

Börja med beslutet du behöver fatta

Ett team vill veta om AI förbättrar leveransen. Att räkna genererade rader besvarar en annan fråga. Definiera användbart resultat och kvalitetsvillkor innan du väljer mått.

För en fiktiv exporttjänst är målet tillförlitlig leverans av accepterade ändringar med mindre total insats. Registrera förberedelse, implementation, granskning, rättning och väntan. Ta med ändringar som misslyckades eller övergavs.

Använd en tjänst med tydlig gräns. Att kombinera en experimentell webbplats och en kritisk betaltjänst kan ge ett tal som förklarar ingendera. Beskriv kontexten innan perioder eller team jämförs.

Använd aktuella definitioner

DORA:s aktuella leveransmodell innehåller fem mått. De gäller leveransförmåga, inte varje funktions värde eller en individs bidrag. DORA:s måttdefinitioner.

En dashboard kan använda en annan definition. Läs den innan du tolkar resultatet. Taigas aktuella driftsättningsdokumentation beskriver fyra rapporterade mått härledda från leverantörens driftsättningsposter. Återställningsmåttet använder en efterföljande lyckad driftsättning. Det är ingen fullständig redovisning av alla produktionsincidenter. Taigas definitioner.

Granska en fiktiv ändringsföljd

Anta att tjänsten gör tolv driftsättningar under en månad. Åtta levererar planerade ändringar. Fyra rättar problem från tidigare releaser. Antalet är tolv, men innehållet spelar roll.

Nästa månad gör teamet tio driftsättningar: nio planerade ändringar och en reparation. Färre driftsättningar kan sammanfalla med mer användbart arbete. Siffrorna illustrerar tolkning; de är inget prestandariktmärke.

Granska också fördelningen. En lång granskningsväntan kan försvinna i ett genomsnitt. Ett återställningsmått från ett enda fel ger svagt underlag för framtida tillförlitlighet. Rapportera antal observationer och väsentliga undantag.

Koppla flöde till konsekvenser

Använd tjänstesignaler för att kontrollera om leveransändringar påverkar användare. En snabbare pipeline räcker inte om exporter misslyckas oftare. Använd ett lämpligt SLO eller annat tydligt definierat resultatmått. SLO-vägledning.

Granskningsinsats och omarbete hjälper att förklara resultatet. Om AI kortar implementationen men skapar stora diffar kan granskning bli begränsningen. Om miljöer tar dagar att få kan snabbare kodning ha liten effekt på förfluten leveranstid.

Välj en förbättring som hanterar den observerade begränsningen. Erbjud exempelvis en testmiljö med stöd eller minska ändringarnas storlek. Definiera ett balanserande kvalitetsmått så att teamet upptäcker skenbar hastighetsvinst från svagare kontroller.

Håll mätningen användbar

Undvik individuell rangordning efter PR-antal eller genererad kod. Måtten kan belöna konstlad uppdelning, undvikande av svårt underhåll eller överflyttning av granskning till kollegor.

Granska resultatet med ansvariga för hela tjänsten. Registrera vad som ändrades i verktyg, arbetsmix, team och miljö. Behandla en före- och efterjämförelse som begränsat underlag, inte automatiskt bevis för orsak.

Syftet är ett bättre nästa beslut. En liten, tillförlitlig mätning som leder till verifierad förbättring är mer användbar än en stor dashboard utan gemensam betydelse.

Öva med tio ändringar

Detta separata fiktiva dataset registrerar tio planerade ändringar. Alla tider är UTC på angivet datum. Ett tomt rättningsfält betyder att ingen rättning registrerades i datasetet.

Jämför tiden från kod klar till granskningsstart och sedan från acceptans till release. Identifiera längsta synliga väntan. Undersök orsaken innan du kallar den undvikbar. Tidsstämplarna mäter inte aktiv insats och visar inte när en incident började. En rättningsrelease ensam fastställer inte återställningstid efter misslyckad driftsättning.

Ladda ned det fiktiva datasetet (CSV)