Was sind DORA-Metriken?

In diesem Artikel werden wir in die Welt der DORA-Metriken eintauchen, ihre Bedeutung erforschen und herausfinden, wie sie genutzt werden können, um die Qualität der Softwarebereitstellung zu verbessern.

Auch innerhalb der Softwareentwicklung gab es in der Vergangenheit immer wieder Spannungen zwischen den Entwicklungs- und den Betriebsteams. Die DevOps-Bewegung hat sich mit diesem Spannungsverhältnis auseinandergesetzt und fördert die Zusammenarbeit, das Vertrauen und die Bildung multidisziplinärer Teams, um die Silos zwischen "Dev" und "Ops" aufzubrechen - daher auch DevOps.

DevOps hat sich seit seinen Anfängen in 2007-2008weit verbreitet. Eine Handvoll führender Köpfe der DevOps-Bewegung veröffentlichte den State of DevOps Report von 2014-2017und schloss sich später zu einem Start-up namens DevOps Research and Assessment - auch bekannt als DORA - zusammen. (DORA wurde inzwischen von Google Cloud übernommen und veröffentlicht weiterhin den Jahresbericht).

Jez Humble, Gene Kim und Dr. Nicole Forsgren gründeten DORA mit dem Ziel, ihre DevOps-Forschung zu nutzen, um ein besseres Verständnis der Praktiken, Prozesse und Fähigkeiten zu erlangen, die es Teams ermöglichen, bei der Softwareentwicklung und -bereitstellung Spitzenleistungen zu erzielen.

Die Gründer von DORA haben vier Schlüsselmetriken identifiziert, die für den Erfolg von DevOps unerlässlich sind:

• Häufigkeit des Einsatzes (DF)
• Vorlaufzeit für Änderungen (LT)
• Mittlere Zeit bis zur Wiederherstellung (MTTR)
• Ausfallrate ändern (CFR)

Das DORA-Team hat anhand der Antworten von über 31,000 Fachleuten im Laufe von sechs Jahren ermittelt, dass diese kritischen Metriken den größten Einfluss auf die Softwareentwicklung und -bereitstellung haben.

Anhand der vier DORA-Kennzahlen können Führungskräfte aus dem Ingenieurwesen die Leistung ihrer Teams mit anderen in der Branche vergleichen, d.h. sie können feststellen, ob es sich um "Elite-Performer" handelt oder ob es noch Raum für Verbesserungen gibt (Teams mit hoher, mittlerer und niedriger Leistung). Diese Informationen ermöglichen es den Führungskräften, Verbesserungsmöglichkeiten zu erkennen und entsprechende Änderungen vorzunehmen.

Häufigkeit des Einsatzes (DF)

Die Bereitstellungshäufigkeit (DF) ist ein Maß für den durchschnittlichen Durchsatz. Es ist die durchschnittliche Häufigkeit, mit der Code über einen bestimmten Zeitraum in der Produktion eingesetzt wird. Die Einsatzhäufigkeit kann verwendet werden, um zu beurteilen, wie oft ein Entwicklungsteam einen Mehrwert für die Kunden liefert.

Wenn Sie in der Lage sind, Ihren Kunden neue Funktionen konsequent und schnell zur Verfügung zu stellen, können Sie die Kundenbindung erhöhen und der Konkurrenz einen Schritt voraus sein.

Die Messung der Bereitstellungshäufigkeit im Laufe der Zeit kann Teams dabei helfen, Wege zur Verbesserung ihrer Liefergeschwindigkeit zu finden. Eine Erkenntnis, die DORA gewonnen hat, ist, dass erfolgreichere DevOps-Teams dazu neigen, häufiger kleinere Implementierungen durchzuführen (im Gegensatz zu selteneren großen Implementierungen).

DevOps-Teams können ihre DF-Metriken nutzen, um ihre Leistung mit der anderer Teams zu vergleichen. Leistungsstarke Teams stellen im Durchschnitt einmal pro Woche bereit, während Spitzenteams innerhalb eines einzigen Tages mehrmals bereitstellen können.

Wenn ein Team bei dieser Kennzahl schlecht abschneidet, kann es diese Informationen nutzen, um spezifische Verbesserungsmöglichkeiten zu ermitteln: Zum Beispiel, indem es die Arbeit in kleinere Stapel aufteilt oder kleinere Pull-Anfragen erstellt.

Vorlaufzeit für Änderungen (LT)

Die Vorlaufzeit für Änderungen (LT) oder mittlere Vorlaufzeit für Änderungen (MTLC) misst, wie lange es dauert, bis ein Team eine Änderung implementiert, sobald die Codierung begonnen hat.

Die Vorlaufzeit für Änderungen wird anhand der Zeit gemessen, die zwischen der Zusage für eine Änderung und der Freigabe dieser Änderung für die Produktion verstreicht. Die mittlere Vorlaufzeit für Änderungen ist der Mittelwert oder Durchschnitt aller Änderungen, die über einen bestimmten Zeitraum vorgenommen wurden.

Die Messung der MLTC ist wichtig, weil sie angibt, wie lange ein Team braucht, um seine Arbeit an die Kunden zu liefern. Eine schlechte Leistung bei dieser Kennzahl bedeutet, dass ein Team nicht in der Lage ist, Änderungen zuverlässig und zeitnah umzusetzen.

Wie andere DORA-Kennzahlen kann auch die mittlere Vorlaufzeit für Änderungen für das Benchmarking der Teamleistung nützlich sein. In der Regel können Spitzenteams Änderungen innerhalb eines Tages umsetzen, während durchschnittliche Teams etwa eine Woche brauchen. Das Verständnis dieser Kennzahl kann den Führungskräften helfen, ein besseres Verständnis der Teamkapazität zu erlangen und die Erwartungen realistisch anzupassen, wenn sich Änderungen ergeben.

Es gibt viele Faktoren, die sich auf die MLTC auswirken können. Deshalb ist es wichtig, die Vorlaufzeiten für jede Phase des Entwicklungsprozesses zu analysieren. Führungskräfte können Muster analysieren, wie lange ihr Team braucht, um Änderungen zu öffnen, zu bearbeiten, zu testen und bereitzustellen, um zu verstehen, wo Engpässe auftreten könnten.

Wenn ein Team mit der Vorlaufzeit für Änderungen unzufrieden ist, könnte es versuchen, die Arbeit in kleinere Batches aufzuteilen, kleinere Pull Requests zu erstellen, den Code-Review-Prozess zu verbessern oder die Test- oder Bereitstellungsprozesse zu automatisieren.

Mittlere Zeit bis zur Wiederherstellung (MTTR)

Die mittlere Wiederherstellungszeit (Mean Time to Recovery, MTTR) misst die Zeit, die ein Team benötigt, um ein System nach einem Ausfall in der Produktionsumgebung wieder in den normalen Funktionszustand zu versetzen.

Die Fähigkeit, sich schnell von einem Fehler zu erholen, ist eine wesentliche Fähigkeit für DevOps-Teams. Es gibt zwei Schlüsselkomponenten für die Wiederherstellung: die Fähigkeit, einen Fehler schnell zu erkennen und ihn dann zu beheben. Die Verbesserung der Beobachtbarkeit, d.h. die Einrichtung von Systemen, die sicherstellen, dass Ausfälle schnell erkannt werden, ist ein hilfreicher Schritt zur Verbesserung der mittleren Zeit bis zur Wiederherstellung.

Wenn es um MTTR geht, gilt natürlich: je schneller, desto besser. Leistungsstarke Teams sind möglicherweise in der Lage, einen Ausfall in weniger als einer Stunde zu beheben. Die meisten Teams benötigen jedoch wahrscheinlich mehrere Stunden oder sogar einen ganzen Tag.

Um diese Kennzahl zu verbessern, sollten Teams einen klaren Aktionsplan für die Behebung von Fehlern entwickeln und dafür sorgen, dass jedes Teammitglied den Prozess versteht.

Ausfallrate ändern (CFR)

Die vierte und letzte DORA-Kennzahl ist die Change Failure Rate (CFR), eine Berechnung zur Quantifizierung des Prozentsatzes der Implementierungen, die einen Fehler in der Produktion verursacht haben. Der CFR wird ermittelt, indem die Anzahl der Vorfälle durch die Gesamtzahl der Einsätze geteilt wird.

Wenn Teams unter dem Druck stehen, Arbeit abzuliefern und Änderungen schnell zu implementieren, ist es unvermeidlich, dass einige Bugs oder Defekte unentdeckt bleiben. Wenn der CFR hoch ist, deutet dies darauf hin, dass dies häufig vorkommt und die Qualität darunter leidet. Laut dem 2021 State of DevOps Report melden die meisten Teams eine Fehlerquote bei Änderungen von 0-15%.

Auf diese Weise dient CFR als kritischer Gegenpol zu anderen DORA-Kennzahlen, die sich auf die Geschwindigkeit konzentrieren (d.h. auf die Häufigkeit der Bereitstellung und die Vorlaufzeit für Änderungen). Eine häufige Bereitstellung ist großartig, aber nicht, wenn das bedeutet, dass die Qualität ständig leidet - und Sie dann Zeit für Korrekturen aufwenden müssen. Die Analyse von CFR kann den Verantwortlichen helfen, sicherzustellen, dass die Teams sowohl die Stabilität als auch den Durchsatz optimieren.

Viele der Ansätze zur Verbesserung der Fehlerquote bei Änderungen entsprechen denen, die für andere DORA-Kennzahlen vorgeschlagen wurden: Verringerung der Chargengröße, Automatisierung der Testprozesse und Verbesserung der Effizienz der Code-Review-Prozesse.

Der Managementexperte Peter Drucker wird mit den Worten zitiert: "Man kann nicht managen, was man nicht misst." DORA-Metriken ermöglichen DevOps- und Engineering-Teams sinnvolle Verbesserungen, indem sie ihnen eine standardisierte Methode an die Hand geben, um ihre Leistung mit der anderer Teams zu vergleichen und spezifische, umsetzbare Verbesserungsmöglichkeiten zu identifizieren.

Die Optimierung für den Erfolg in jeder der vier DORA-Metriken ist ein bewährter Weg, um Stabilität, Qualität und Geschwindigkeit zu erreichen. Die Verfolgung der Bereitstellungshäufigkeit und der Vorlaufzeit für Änderungen hilft den Teams, ihre Kapazitäten zu verwalten, die Zuverlässigkeit zu verbessern und konsistent Werte zu liefern.

Die Verbesserung der mittleren Wiederherstellungszeit kann dazu beitragen, die Kundenzufriedenheit zu gewährleisten und die Abwanderung zu verhindern. Ein Blick auf die Fehlerquote bei Änderungen im Laufe der Zeit kann Führungskräften dabei helfen, sicherzustellen, dass die Teams nicht nur auf Geschwindigkeit, sondern auch auf Qualität optimieren.

Die Beherrschung der DORA-Metriken kann Teams dabei helfen, schnell und sicher hochwertigen Code zu veröffentlichen. Sie können jedoch nicht aufzeigen, ob Ihr Team den richtigen Wert und die richtigen Geschäftsergebnisse liefert, d.h. was der Kunde braucht und will. Die DORA-Metriken optimieren einen kleinen Teil eines viel größeren Prozesses: die End-to-End-Reise von der Kundenanfrage bis zur Freigabe.

DORA-Metriken helfen DevOps-Teams bei der Optimierung von Geschwindigkeit, Qualität und Stabilität in der Softwareentwicklung und -bereitstellung, aber sie helfen den Teams nicht, sich an den Geschäftsergebnissen wie Umsatz oder Kundenbindung zu orientieren. Die Aufrechterhaltung dieser Ausrichtung ist unerlässlich. Es spielt keine Rolle, wie schnell Sie Code bereitstellen können, wenn dieser Code nicht auf den tatsächlichen Geschäftswert abgestimmt ist.

Um den Kundennutzen wirklich zu optimieren, müssen die Teams in der Lage sein, den gesamten Entwicklungsprozess von Anfang bis Ende zu verstehen und zu visualisieren. In der Softwareentwicklung wird dieses Konzept Wertstrommanagement (VSM)genannt. Dr. Mik Kersten, CTO von Planview, hat das Flow Framework® entwickelt, um die Lücke in der Softwarebereitstellung zu schließen und Softwareunternehmen eine Möglichkeit zu geben, die Bereitstellung von Geschäftswerten über den gesamten Wertstrom hinweg zu messen und zu optimieren.

"Nur einen Bereich des Wertstroms zu messen ist so, als würde man nur zwei Zoll eines 12-Zoll-Lineals verwenden."

- John Willis, Senior Director des Global Transformation Office bei Red Hat, Co-Autor von The DevOps Handbook, Mik+One: Project to Product Podcast, Episode 17

Das Flow Framework basiert auf der Notwendigkeit, den End-to-End-Fluss des Geschäftswerts und die daraus resultierenden Ergebnisse zu messen. Flussmetriken werden verwendet, um den Fluss des Geschäftswerts über alle Aktivitäten zu bewerten, die zum Software-Wertstrom beitragen. Durch die Messung der Korrelation zwischen Flussmetriken und Geschäftsergebnissen können Unternehmen die Auswirkungen ihrer Investitionen bewerten und Bereiche identifizieren, in denen Fluss- und Feedbackzyklen zu langsam sind, um auf Marktveränderungen und Wettbewerb zu reagieren.

Flow Metrics bietet eine präzise Bewertung, ob der Wertstromfluss angemessen ist, um die gewünschten Geschäftsergebnisse zu unterstützen, wie z.B. Umsatz, Kostensenkung, Kundenzufriedenheit und Mitarbeiterengagement. Sie bewerten das Tempo der Wertschöpfung von Softwareprodukten aus der Sicht Ihrer (internen oder externen) Kunden.

Es gibt vier wichtige Flow Metrics zur Messung von Produktwertströmen:

1. Flow Velocity®  misst, ob die Wertabgabe beschleunigt oder verlangsamt wird. Flow Velocity ist die Anzahl der Flow Items (Features, Defekte, Risiken und Schulden), die innerhalb eines bestimmten Zeitraums abgeschlossen wurden.
2. Flow Time misst die Zeit bis zur Markteinführung. Flow Time misst die Zeit, die von 'Arbeitsbeginn' bis 'Arbeitsende' für ein bestimmtes Flow Item vergeht, einschließlich der aktiven und der Wartezeiten.
3. Flow Efficiency®  identifiziert Verschwendung in einem Wertstrom. Die Flow-Effizienz ist das Verhältnis der aktiven Zeit zur gesamten Flow-Zeit.
4. Flow Load®  überwacht die Über- und Unterauslastung von Wertströmen, die zu einer verringerten Produktivität führen können. Flow Load misst die Anzahl der in Bearbeitung befindlichen (aktiven oder wartenden) Flow Items innerhalb eines bestimmten Wertstroms.

Zusätzlich zu den vier Flussmetriken hilft Flow Distribution®  dabei, die verschiedenen Arten von Arbeit zu identifizieren, die in bestimmten Zeiträumen erledigt wurden. Flow Distribution misst das Verhältnis von Flow Items (Features, Defects, Risk oder Debt), die innerhalb eines bestimmten Zeitfensters abgeschlossen wurden.

Die im Flow Framework skizzierten Flussmetriken sollen die DORA-Metriken nicht ersetzen, sondern vielmehr ergänzen. Wie bei jedem Prozess benötigen Sie aussagekräftige, umfassende Daten, um zu verstehen, wie schnell Sie liefern, was Sie bremst und was Sie tun können, um sich in jeder Phase zu verbessern.

Durch die Kombination von DORA-Metriken mit Flow Metrics können Teams sicherstellen, dass sie einen ganzheitlichen Überblick über den gesamten Softwareentwicklungsprozess erhalten und nicht nur die Geschwindigkeit und Qualität, sondern auch den Geschäftswert und die Ergebnisse optimieren.