Meet het leveringsproces

Begin met de beslissing die u moet nemen

Een team wil weten of AI de levering verbetert. Het aantal gegenereerde regels beantwoordt een andere vraag. Definieer het nuttige resultaat en de kwaliteitsvoorwaarden voordat u een meetwaarde kiest.

Voor een fictieve exportservice is het gewenste resultaat: geaccepteerde wijzigingen betrouwbaar leveren met minder totale inspanning. Leg voorbereiding, implementatie, review, correctie en wachttijd vast. Neem ook mislukte en afgebroken wijzigingen mee.

Gebruik één service met een duidelijke afbakening. Een experimentele website en een kritieke betaaldienst samenvoegen kan een getal opleveren dat geen van beide verklaart. Beschrijf de context voordat u perioden of teams vergelijkt.

Gebruik actuele definities

Het huidige leveringsmodel van DORA bevat vijf meetwaarden. Ze gaan over leveringsprestaties, niet over de waarde van elke functie of de bijdrage van een individu. Definities van DORA-meetwaarden.

Een dashboard kan een andere definitie gebruiken. Lees die voordat u het resultaat interpreteert. De huidige deploymentdocumentatie van Taiga beschrijft vier gerapporteerde meetwaarden op basis van deploymentrecords van de provider. De herstelmeting gebruikt een volgende geslaagde deployment. Dat is geen volledig overzicht van alle productie-incidenten. Definities van Taiga.

Bekijk een fictieve reeks wijzigingen

Stel dat een service in een maand twaalf deployments uitvoert. Acht leveren geplande wijzigingen. Vier herstellen problemen uit eerdere releases. Het aantal is twaalf, maar de samenstelling doet ertoe.

De volgende maand voert het team tien deployments uit: negen geplande wijzigingen en één reparatie. Minder deployments kunnen samengaan met meer nuttig werk. Deze cijfers laten zien hoe interpretatie werkt; het zijn geen prestatienormen.

Bekijk ook de verdeling. Eén lange wachttijd voor review kan in een gemiddelde verdwijnen. Een herstelmeting op basis van één storing is zwak bewijs voor toekomstige betrouwbaarheid. Vermeld het aantal waarnemingen en belangrijke uitzonderingen.

Verbind doorstroming met gevolgen

Gebruik servicesignalen om te controleren of wijzigingen in het leveringsproces gebruikers raken. Een snellere pipeline is niet voldoende als exports vaker mislukken. Gebruik een passende SLO of een andere duidelijk gedefinieerde resultaatmeting. Richtlijnen voor SLO’s.

Reviewinspanning en herstelwerk helpen het resultaat te verklaren. Als AI de implementatie verkort maar grote diffs oplevert, kan review de beperkende factor worden. Als het dagen duurt om omgevingen te krijgen, kan sneller programmeren weinig effect hebben op de totale doorlooptijd.

Kies één verbetering die de waargenomen beperking aanpakt. Bied bijvoorbeeld een ondersteunde testomgeving of verklein de wijziging. Definieer een aanvullende kwaliteitsmeting waarmee het team schijnbare tijdwinst door zwakkere controles kan herkennen.

Houd metingen bruikbaar

Vermijd ranglijsten van medewerkers op basis van PR-aantallen of gegenereerde code. Zulke metingen kunnen kunstmatig opknippen belonen, lastig onderhoud ontmoedigen of reviewwerk naar collega’s verschuiven.

Beoordeel het resultaat met de mensen die verantwoordelijk zijn voor de volledige service. Leg vast wat veranderde in de tool, de samenstelling van het werk, het team en de omgeving. Beschouw een vergelijking voor en na als bewijs met beperkingen, niet als automatisch bewijs van een oorzakelijk verband.

Het doel is een betere volgende beslissing. Een kleine, betrouwbare meting die tot een gecontroleerde verbetering leidt, is nuttiger dan een groot dashboard zonder gedeelde betekenis.

Oefen met tien wijzigingen

Deze afzonderlijke fictieve dataset bevat tien geplande wijzigingen. Alle tijden zijn UTC op de vermelde datum. Een leeg correctieveld betekent dat in deze dataset geen correctie is vastgelegd.

Vergelijk de tijd tussen code gereed en het begin van de review, en daarna tussen acceptatie en release. Zoek de langste zichtbare wachttijd. Onderzoek de oorzaak voordat u die vermijdbaar noemt. Deze tijdstempels meten geen actieve inspanning en tonen niet wanneer een incident begon. Een correctierelease alleen kan de hersteltijd na een mislukte deployment niet aantonen.

Download de fictieve dataset (CSV)