Mål leveransesystemet

Begynn med beslutningen dere må ta

Et team vil vite om AI forbedrer leveransen. Å telle genererte linjer svarer på et annet spørsmål. Definer det nyttige resultatet og kvalitetsvilkårene før dere velger et måltall.

For en fiktiv eksporttjeneste er ønsket resultat pålitelig levering av godkjente endringer med mindre samlet innsats. Registrer forberedelse, implementasjon, review, retting og venting. Ta med endringer som feilet eller ble avbrutt.

Bruk én tjeneste med en tydelig grense. Å kombinere et eksperimentelt nettsted og en kritisk betalingstjeneste kan gi et tall som ikke forklarer noen av dem. Beskriv konteksten før dere sammenligner perioder eller team.

Bruk gjeldende definisjoner

DORAs gjeldende leveransemodell inneholder fem måltall. Omfanget er leveranseevne, ikke verdien av hver funksjon eller bidraget fra en enkeltperson. DORAs måltallsdefinisjoner.

Et dashbord kan bruke en annen definisjon. Les den før dere tolker resultatet. Taigas gjeldende utrullingsdokumentasjon beskriver fire rapporterte måltall basert på leverandørens utrullingsregistreringer. Gjenopprettingsmålet bruker en senere vellykket utrulling. Det er ikke en fullstendig registrering av alle produksjonshendelser. Taigas definisjoner.

Undersøk en fiktiv endringssekvens

Anta at en tjeneste gjør tolv utrullinger på en måned. Åtte leverer planlagte endringer. Fire reparerer problemer fra tidligere utgivelser. Antallet er tolv, men sammensetningen betyr noe.

Neste måned gjør teamet ti utrullinger: ni planlagte endringer og én reparasjon. Færre utrullinger kan forekomme sammen med mer nyttig arbeid. Tallene illustrerer tolkning; de er ikke en ytelsesreferanse.

Undersøk også fordelingen. Én lang ventetid på review kan forsvinne i et gjennomsnitt. Et gjenopprettingsmål fra én enkelt feil er svakt bevis for fremtidig pålitelighet. Oppgi antallet observasjoner og vesentlige unntak.

Koble flyt til konsekvenser

Bruk tjenestesignaler til å kontrollere om endringer i leveransen påvirker brukerne. En raskere pipeline er ikke tilstrekkelig hvis eksporter feiler oftere. Bruk et passende SLO eller et annet tydelig definert resultatmål. SLO-veiledning.

Innsats i review og omarbeid bidrar til å forklare resultatet. Hvis AI forkorter implementasjonen, men produserer store differ, kan review bli begrensningen. Hvis det tar dager å skaffe miljøer, kan raskere koding ha liten effekt på samlet leveringstid.

Velg én forbedring som håndterer den observerte begrensningen. Tilby for eksempel et støttet testmiljø eller reduser størrelsen på en endring. Definer et balanserende kvalitetsmål slik at teamet kan oppdage en tilsynelatende hastighetsgevinst som skyldes svakere kontroller.

Hold målingen nyttig

Unngå individuell rangering basert på antall PR-er eller generert kode. Slike mål kan belønne kunstig oppdeling av arbeid, unngåelse av vanskelig vedlikehold eller flytting av review-arbeid til kolleger.

Gjennomgå resultatet med dem som er ansvarlige for hele tjenesten. Dokumenter hva som endret seg i verktøy, oppgavesammensetning, team og miljø. Behandle en før-og-etter-sammenligning som bevis med begrensninger, ikke automatisk bevis på årsakssammenheng.

Formålet er en bedre neste beslutning. En liten, pålitelig måling som fører til en verifisert forbedring, er mer nyttig enn et stort dashbord uten avtalt betydning.

Øv med ti endringer

Dette separate fiktive datasettet registrerer ti planlagte endringer. Alle tider er UTC på datoen som vises. Et tomt rettefelt betyr at ingen retting er registrert i dette datasettet.

Sammenlign tiden fra koden er klar til review starter, deretter fra godkjenning til utgivelse. Finn den lengste synlige ventetiden. Undersøk årsaken før dere kaller den unngåelig. Tidsstemplene måler ikke aktiv innsats og viser ikke når en hendelse begynte. En rettingsutgivelse alene kan ikke fastslå gjenopprettingstid etter mislykket utrulling.

Last ned det fiktive datasettet (CSV)