Was sind DORA-Kennzahlen?

In diesem Artikel werden wir in die Welt der DORA-Kennzahlen eintauchen, ihre Bedeutung näher untersuchen 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 Entwicklungsteams (Development, kurz Dev) und den Betriebsteams (Operations, kurz Ops). Die DevOps-Bewegung hat sich mit diesem Spannungsverhältnis auseinandergesetzt und fördert seitdem die Zusammenarbeit und das gegenseitige Vertrauen der beiden Bereiche sowie die Bildung multidisziplinärer Teams, um die Lücke zwischen „Dev“ und „Ops“ zu schließen – heraus kam DevOps.

DevOps hat sich seit seinen Anfängen in den Jahren 2007 – 2008 weit verbreitet. Eine Handvoll führender Köpfe der DevOps-Bewegung veröffentlichte den State of DevOps Report von 2014 – 2017 und 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 Bestleistungen zu erzielen.

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

• Deployment Frequency (DF)
• Lead Time for Changes (LT)
• Mean Time to Recovery (MTTR)
• Change Failure Rate (CFR)

Das DORA-Team hat auf Basis der Antworten von über 31.000 Fachleuten über einen Zeitraum von sechs Jahren ermittelt, dass diese wichtigen Kennzahlen den größten Einfluss auf die Softwareentwicklung und -bereitstellung haben.

Anhand der vier DORA-Kennzahlen können Engineering-Führungskräfte die Leistung ihrer Teams mit anderen in der Branche vergleichen. Sie können also feststellen, ob es sich um „Spitzenperformer“ handelt oder ob noch Verbesserungspotenzial besteht (d. h. Teams mit hoher, mittlerer und niedriger Performance). Diese Informationen ermöglichen es den Führungskräften, Verbesserungsmöglichkeiten zu erkennen und entsprechende Änderungen vorzunehmen.

Deployment Frequency (DF)

Die Deployment Frequency (DF) ist eine Kennzahl für den mittleren Durchsatz. Es ist die durchschnittliche Häufigkeit, mit der Code über einen bestimmten Zeitraum in der Produktionsumgebung bereitgestellt wird. Die Deployment Frequency kann verwendet werden, um zu beurteilen, wie oft ein Engineering-Team einen Mehrwert für die Kunden erbringt.

Die Fähigkeit, konsequent und schnell neue Funktionen für die Kunden bereitzustellen, ist unerlässlich, um die Kundenbindung zu erhöhen und Mitbewerbern einen Schritt voraus sein.

Das Messen der Deployment Frequency im Laufe der Zeit kann Teams dabei helfen, Wege zur Verbesserung ihrer Bereitstellungsgeschwindigkeit zu finden. Eine Erkenntnis, die DORA mithilfe dieser Kennzahl gewonnen hat, ist, dass erfolgreichere DevOps-Teams dazu neigen, häufiger kleinere Deployments anstelle von seltenen, großen Deployments durchzuführen.

DevOps-Teams können ihre DF-Kennzahlen nutzen, um ihre Performance mit der anderer Teams zu vergleichen. Leistungsstarke Teams haben im Durchschnitt ein Deployment pro Woche, während es bei Spitzenteams mehrere Deployments an einem einzigen Tag sein können.

Wenn ein Team im Hinblick auf diese Kennzahl schlecht abschneidet, kann es diese Informationen nutzen, um spezifische Verbesserungsmöglichkeiten zu ermitteln: Die Arbeit könnte beispielsweise in kleinere Pakete aufgeteilt oder es können kleinere Pull Requests erstellt werden.

Lead Time for Changes (LT)

Die Lead Time for Changes (LT) misst, wie lange es dauert, bis ein Team eine Änderung implementiert, sobald die Codierung begonnen hat.

Sie beschreibt die Zeit, die zwischen der Zusage für eine Änderung und dem Release dieser Änderung für die Produktion vergeht. Die Mean Lead Time for Changes (MLTC) ist der Mittelwert oder Durchschnitt aller Änderungen, die über einen bestimmten Zeitraum vorgenommen wurden.

Die Messung der MLTC ist wichtig, da sie angibt, wie lange ein Team braucht, um seine Arbeit an die Kunden bereitzustellen. Eine schlechte Performance im Hinblick auf diese Kennzahl bedeutet, dass ein Team nicht in der Lage ist, Änderungen zuverlässig und zeitnah umzusetzen.

Wie andere DORA-Kennzahlen kann auch die Mean Lead Time for Changes für das Benchmarking der Teamleistung nützlich sein. In der Regel können Spitzenteams Änderungen innerhalb eines Tages implementieren, während durchschnittliche Teams etwa eine Woche brauchen. Das Messen 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, diese Kennzahl für jede Phase des Entwicklungsprozesses zu analysieren. Führungskräfte können erkennen, wie lange ihr Team braucht, um Änderungen anzugehen, zu bearbeiten, zu testen und bereitzustellen und anhand von Mustern feststellen, wo Engpässe auftreten könnten.

Wenn ein Team mit der Lead Time for Changes unzufrieden ist, könnte es versuchen, die Arbeit in kleinere Pakete aufzuteilen, kleinere Pull Requests zu erstellen, den Prozess der Codeüberprüfung zu verbessern oder die Test- oder Bereitstellungsprozesse zu automatisieren.

Mean Time to Recovery (MTTR)

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

Die Fähigkeit, die Funktionalität nach einem Problem schnell wieder herzustellen, ist eine wichtige Kompetenz für DevOps-Teams. Es gibt zwei Schlüsselkomponenten für eine erfolgreiche Wiederherstellung: die Fähigkeit, einen Fehler schnell zu erkennen, und die Fähigkeit, ihn dann zu beheben. Die Verbesserung der Beobachtbarkeit – d. h. die Einrichtung von Systemen, die sicherstellen, dass Fehler schnell erkannt werden – ist ein hilfreicher Schritt zur Verbesserung der Mean Time to Recovery.

Wenn es um die MTTR geht, gilt natürlich: je schneller, desto besser. Spitzenteams sind möglicherweise in der Lage, einen Fehler 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 Fehlerbehebung entwickeln und dafür sorgen, dass jedes Teammitglied den Prozess versteht.

Change Failure Rate (CFR)

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

Wenn Teams unter dem Druck stehen, Arbeit umzusetzen und Änderungen schnell zu implementieren, ist es unvermeidlich, dass einige Bugs oder Mängel unentdeckt bleiben. Eine hohe CFR deutet darauf hin, dass dies häufig vorkommt und die Qualität darunter leidet. Laut dem State of DevOps Report 2021 melden die meisten Teams eine CFR von 0 – 15 %.

Auf diese Weise dient die Change Failure Rate als wichtiger Gegenpol zu anderen DORA-Kennzahlen, die sich auf die Geschwindigkeit konzentrieren (wie die Deployment Frequency und die Lead Time for Changes). Eine häufige Bereitstellung ist großartig – aber nicht, wenn dadurch die Qualität ständig leidet und viel Zeit für Verbesserungen aufgewendet werden muss. Die Analyse der CFR kann den Führungskräften helfen, sicherzustellen, dass die Teams sowohl die Stabilität als auch den Durchsatz optimieren.

Viele der Ansätze zur Verbesserung der Change Failure Rate entsprechen denen der anderen DORA-Kennzahlen: Verringerung der Losgröße, Automatisierung der Testprozesse und Verbesserung der Effizienz der Codeüberprüfungsprozesse.

Der Managementexperte Peter Drucker wird mit den Worten zitiert: „Was man nicht messen kann, kann man nicht lenken.“ DORA-Kennzahlen ermöglichen DevOps- und Engineering-Teams, sinnvolle Verbesserungen vorzunehmen, indem sie ihnen eine standardisierte Methode an die Hand geben, um ihre Performance mit der anderer Teams zu vergleichen und spezifische, umsetzbare Verbesserungsmöglichkeiten zu identifizieren.

Die erfolgreiche Optimierung aller vier DORA-Kennzahlen ist ein bewährter Weg, um Stabilität, Qualität und eine hohe Geschwindigkeit zu erreichen. Die Verfolgung der Deployment Frequency und der Lead Time for Changes hilft den Teams, ihre Kapazitäten zu verwalten, die Zuverlässigkeit zu verbessern und konsistent einen Mehrwert zu erbringen.

Die Verbesserung der Mean Time to Recovery kann dazu beitragen, die Kundenzufriedenheit sicherzustellen und eine Abwanderung zu Mitbewerbern zu verhindern. Ein Blick auf die Change Failure Rate über einen längeren Zeitraum kann Führungskräften dabei helfen, sicherzustellen, dass die Teams nicht nur im Hinblick auf die Geschwindigkeit, sondern auch auf die Qualität Optimierungen vornehmen.

Das Verfolgen von DORA-Kennzahlen kann Teams dabei helfen, schnell und zuverlässig qualitativ hochwertigen Code bereitzustellen. Sie können jedoch nicht aufzeigen, ob das Team den richtigen Mehrwert und die richtigen Geschäftsergebnisse erbringt, d. h. das umsetzt, was der Kunde braucht und wünscht. Die DORA-Kennzahlen optimieren einen kleinen Teil eines viel größeren Gesamtbildes: der End-to-End-Prozess von der Kundenanfrage bis zum Release.

DORA-Kennzahlen helfen DevOps-Teams bei der Optimierung von Geschwindigkeit, Qualität und Stabilität in der Softwareentwicklung und -bereitstellung. Allerdings helfen sie den Teams nicht bei der Ausrichtung an den Geschäftsergebnissen wie Umsatz oder Kundenbindung. Das Aufrechterhalten dieser Ausrichtung ist jedoch unerlässlich. Die Geschwindigkeit der Code Deployments spielt keine Rolle, wenn dieser Code nicht auf den tatsächlichen geschäftlichen Mehrwert 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 Value Stream Management (VSM) genannt. Dr. Mik Kersten, CTO bei Planview, hat das Flow Framework® entwickelt, um die Lücke in der Softwarebereitstellung zu schließen und Softwareorganisationen eine Möglichkeit zu geben, die Bereitstellung von geschäftlichem Mehrwert über den gesamten Value Stream hinweg zu messen und zu optimieren.

„Nur einen Bereich des Value Streams zu messen, ist als würde man nur fünf Zentimeter eines 30-cm-Lineals verwenden.“

– John Willis, Senior Director of the 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-Flow des geschäftlichen Mehrwerts sowie die daraus resultierenden Ergebnisse zu messen. Flow-Metriken werden verwendet, um den Flow dieses Mehrwerts über alle Aktivitäten, die zum Software Value Stream beitragen, hinweg zu bewerten. Durch das Messen der Korrelation zwischen Flow-Metriken und Geschäftsergebnissen können Organisationen die Auswirkungen ihrer Investitionen bewerten und Bereiche identifizieren, in denen Flow und Feedbackzyklen zu langsam sind, um auf Marktveränderungen und Mitbewerber zu reagieren.

Flow-Metriken bietet eine präzise Bewertung des Value Stream Flows, um festzustellen, ob die gewünschten Geschäftsergebnisse – beispielsweise im Hinblick auf Umsatz, Kostensenkung, Kundenzufriedenheit und Mitarbeiterengagement – erreicht werden. Die Kennzahlen messen die Geschwindigkeit der Wertschöpfung für Softwareprodukte aus der Perspektive der internen oder externen Kunden.

Im Flow Framework werden vier wichtige Flow-Metriken, die Flow Metrics, zur Messung von Product Value Streams definiert:

1. Die Flow Velocity® misst, ob sich die Werterbringung beschleunigt oder verlangsamt. Sie bezeichnet die Anzahl der Flow Items (Features, Defects, Risks und Debts), die innerhalb eines bestimmten Zeitraums abgeschlossen wurden.
2. Die Flow Time misst die Time-to-Market. Dies ist die Zeit, die vom Beginn der Arbeit bis zur Fertigstellung für ein bestimmtes Flow Item vergeht, einschließlich der aktiven Zeiten und der Wartezeiten.
3. Die Flow Efficiency® identifiziert liegengebliebene Arbeit in einem Value Stream. Diese Metrik beziffert den Anteil aktiver Zeit im Verhältnis zur gesamten Flow Time.
4. Die Flow Load® überwacht die Über- bzw. Unterauslastung von Value Streams. Beides kann die Produktivität beeinträchtigen. Dabei wird die Anzahl der Flow Items gemessen, die innerhalb eines bestimmten Value Streams in Bearbeitung sind (aktiv oder wartend).

Zusätzlich zu den vier Flow Metrics hilft die Flow Distribution®  dabei, die verschiedenen Arten von abgeschlossener Arbeit zu identifizieren. Sie misst das Verhältnis der Flow Items (Features, Defects, Risks und Debts), die innerhalb eines bestimmten Zeitfensters abgeschlossen wurden.

Die im Flow Framework skizzierten Flow Metrics 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 Arbeit umsetzen, was Sie bremst und was Sie tun können, um sich in jeder Phase zu verbessern.

Durch die Kombination von DORA-Kennzahlen und Flow-Metriken können Teams sicherstellen, dass sie einen ganzheitlichen Überblick über den gesamten Softwarebereitstellungsprozess erhalten und nicht nur die Geschwindigkeit und Qualität, sondern auch den geschäftlichen Mehrwert und die Ergebnisse optimieren.