Mål systemet til softwareleverance

Start med den beslutning, du skal træffe

Et team vil vide, om AI forbedrer leverancen. Antallet af genererede linjer besvarer et andet spørgsmål. Definér det nyttige resultat og kvalitetsbetingelserne, før du vælger en måling.

For en fiktiv eksporttjeneste er målet pålidelig levering af accepterede ændringer med mindre samlet indsats. Registrér forberedelse, implementering, review, rettelser og ventetid. Medtag ændringer, der fejlede eller blev opgivet.

Brug én tjeneste med en klar afgrænsning. En samlet måling af et eksperimentelt website og en kritisk betalingstjeneste kan forklare ingen af dem. Beskriv konteksten, før du sammenligner perioder eller teams.

Brug aktuelle definitioner

DORA’s aktuelle leverancemodel indeholder fem målinger. De måler leveranceevne, ikke værdien af hver funktion eller enkeltpersoners bidrag. DORA’s måledefinitioner.

Et dashboard kan bruge en anden definition. Læs den, før du fortolker resultatet. Taigas aktuelle dokumentation om udrulning beskriver fire rapporterede målinger udledt af udbyderens udrulningsregistreringer. Gendannelsesmålingen bruger en efterfølgende vellykket udrulning. Den er ikke en komplet registrering af alle produktionshændelser. Taigas definitioner.

Undersøg en fiktiv række ændringer

Antag, at en tjeneste har tolv udrulninger på en måned. Otte leverer planlagte ændringer. Fire reparerer problemer fra tidligere releases. Antallet er tolv, men sammensætningen har betydning.

Næste måned har teamet ti udrulninger: ni planlagte ændringer og én reparation. Færre udrulninger kan forekomme samtidig med mere nyttigt arbejde. Tallene illustrerer fortolkning; de er ikke et benchmark for præstation.

Undersøg også fordelingen. En lang ventetid på review kan forsvinde i et gennemsnit. En gendannelsesmåling fra én fejl er svagt belæg for fremtidig pålidelighed. Rapportér antallet af observationer og væsentlige undtagelser.

Forbind flow med konsekvenser

Brug tjenestesignaler til at kontrollere, om ændringer i leverancen påvirker brugerne. En hurtigere pipeline er ikke tilstrækkelig, hvis eksporter fejler oftere. Brug et passende SLO eller et andet klart defineret resultatmål. SLO-vejledning.

Reviewindsats og omarbejde hjælper med at forklare resultatet. Hvis AI forkorter implementeringen, men skaber store diffs, kan review blive begrænsningen. Hvis miljøer tager dage at få, kan hurtigere kodning have lille effekt på den samlede leveringstid.

Vælg én forbedring, der håndterer den observerede begrænsning. Stil for eksempel et understøttet testmiljø til rådighed, eller reducér ændringens størrelse. Definér en balancerende kvalitetsmåling, så teamet kan opdage en tilsyneladende hastighedsgevinst fra svagere kontroller.

Hold målingerne nyttige

Undgå rangordning af enkeltpersoner baseret på antal PR’er eller genereret kode. Målingerne kan belønne kunstig opdeling af arbejde, undgåelse af vanskelig vedligeholdelse eller overførsel af reviewarbejde til kolleger.

Gennemgå resultatet med dem, der har ansvaret for hele tjenesten. Registrér ændringer i værktøj, opgavetyper, team og miljø. Behandl en før-og-efter-sammenligning som dokumentation med begrænsninger, ikke automatisk bevis for årsag.

Formålet er en bedre næste beslutning. En lille, troværdig måling, der fører til en verificeret forbedring, er mere nyttig end et stort dashboard uden aftalt betydning.

Øv dig med ti ændringer

Dette særskilte fiktive datasæt registrerer ti planlagte ændringer. Alle tidspunkter er UTC på den viste dato. Et tomt rettelsesfelt betyder, at ingen rettelse blev registreret i datasættet.

Sammenlign tiden fra klar kode til start på review, derefter fra accept til release. Find den længste synlige ventetid. Undersøg årsagen, før du kalder den undgåelig. Tidsstemplerne måler ikke aktiv indsats og viser ikke, hvornår en hændelse begyndte. En rettelsesrelease kan ikke alene fastslå gendannelsestiden efter en fejlet udrulning.

Download det fiktive datasæt (CSV)