Das Liefersystem messen

Beginnen Sie mit der anstehenden Entscheidung

Ein Team möchte wissen, ob KI die Lieferung verbessert. Generierte Zeilen zu zählen, beantwortet eine andere Frage. Definieren Sie das nützliche Ergebnis und die Qualitätsbedingungen, bevor Sie eine Kennzahl wählen.

Für einen fiktiven Exportdienst ist das gewünschte Ergebnis eine verlässliche Lieferung angenommener Änderungen mit weniger Gesamtaufwand. Erfassen Sie Vorbereitung, Implementierung, Review, Korrektur und Warten. Beziehen Sie fehlgeschlagene oder aufgegebene Änderungen ein.

Nutzen Sie einen Dienst mit klarer Grenze. Eine experimentelle Website und einen kritischen Zahlungsdienst zusammenzufassen, kann eine Zahl erzeugen, die keinen von beiden erklärt. Beschreiben Sie den Kontext vor Vergleichen von Zeiträumen oder Teams.

Nutzen Sie aktuelle Definitionen

DORAs aktuelles Liefermodell enthält fünf Kennzahlen. Sie betreffen die Lieferleistung, nicht den Wert jeder Funktion oder den Beitrag einer Einzelperson. DORA-Kennzahlendefinitionen.

Ein Dashboard kann eine andere Definition verwenden. Lesen Sie diese vor der Interpretation. Taigas aktuelle Deployment-Dokumentation beschreibt vier ausgewiesene Kennzahlen aus Deployment-Datensätzen des Anbieters. Die Wiederherstellungskennzahl nutzt ein nachfolgendes erfolgreiches Deployment. Das ist keine vollständige Erfassung aller Produktionsincidents. Taiga-Definitionen.

Untersuchen Sie eine fiktive Änderungsfolge

Angenommen, ein Dienst hat zwölf Deployments in einem Monat. Acht liefern geplante Änderungen. Vier beheben Probleme früherer Veröffentlichungen. Die Anzahl ist zwölf, aber ihre Zusammensetzung ist relevant.

Im nächsten Monat führt das Team zehn Deployments aus: neun geplante Änderungen und eine Reparatur. Weniger Deployments können mit mehr nützlicher Arbeit einhergehen. Diese Zahlen veranschaulichen die Interpretation. Sie sind kein Leistungsmaßstab.

Prüfen Sie auch die Verteilung. Eine lange Review-Wartezeit kann im Durchschnitt verschwinden. Eine Wiederherstellungskennzahl aus einem einzelnen Fehler ist ein schwacher Nachweis für künftige Zuverlässigkeit. Geben Sie die Anzahl der Beobachtungen und wesentliche Ausnahmen an.

Verbinden Sie Ablauf und Folgen

Nutzen Sie Dienstsignale, um zu prüfen, ob Änderungen an der Lieferung Nutzer betreffen. Eine schnellere Pipeline reicht nicht, wenn Exporte häufiger scheitern. Verwenden Sie ein geeignetes SLO oder eine andere klar definierte Ergebniskennzahl. SLO-Leitfaden.

Review-Aufwand und Nacharbeit helfen, das Ergebnis zu erklären. Verkürzt KI die Implementierung, erzeugt aber große Diffs, kann das Review zum Engpass werden. Dauert die Bereitstellung von Umgebungen Tage, kann schnelleres Programmieren die gesamte Lieferzeit kaum beeinflussen.

Wählen Sie eine Verbesserung, die den beobachteten Engpass behandelt. Stellen Sie zum Beispiel eine unterstützte Testumgebung bereit oder verkleinern Sie Änderungen. Definieren Sie eine ergänzende Qualitätskennzahl, damit das Team scheinbare Geschwindigkeitsgewinne durch schwächere Prüfungen erkennt.

Halten Sie Messung nützlich

Vermeiden Sie Personenranglisten anhand von PR-Anzahlen oder generiertem Code. Diese Messgrößen können die künstliche Zerlegung von Aufgaben, das Meiden schwieriger Wartung oder die Verlagerung von Review-Aufwand auf Kollegen belohnen.

Besprechen Sie das Ergebnis mit den Verantwortlichen des vollständigen Dienstes. Dokumentieren Sie Änderungen an Werkzeug, Aufgabenmix, Team und Umgebung. Behandeln Sie einen Vorher-Nachher-Vergleich als Nachweis mit Grenzen, nicht als automatischen Kausalitätsbeweis.

Das Ziel ist eine bessere nächste Entscheidung. Eine kleine, verlässliche Messung, die zu einer geprüften Verbesserung führt, ist nützlicher als ein großes Dashboard ohne vereinbarte Bedeutung.

Üben Sie mit zehn Änderungen

Dieser separate fiktive Datensatz erfasst zehn geplante Änderungen. Alle Zeiten sind UTC am angegebenen Datum. Ein leeres Korrekturfeld bedeutet, dass in diesem Datensatz keine Korrektur erfasst wurde.

Vergleichen Sie die Zeit von fertigem Code bis zum Review-Beginn und anschließend von der Annahme bis zur Veröffentlichung. Finden Sie die längste sichtbare Wartezeit. Untersuchen Sie ihre Ursache, bevor Sie sie als vermeidbar bezeichnen. Diese Zeitstempel messen keinen aktiven Aufwand und zeigen nicht, wann ein Incident begann. Eine Korrekturveröffentlichung allein kann die Failed Deployment Recovery Time nicht belegen.

Fiktiven Datensatz herunterladen (CSV)