Am Anfang stand die Frage, ob Software Delivery Performance mit Geschäftserfolg korreliert. Zwischen 2014 und 2017 begeben sich die drei IT-Wissenschaftler*innen Nicole Forsgren, Jez Humble und Gene Kim auf die Suche nach einer Antwort auf diese Frage. Diese Artikelreihe beschreibt ihre Forschungsreise, die gefundenen Antworten sowie die daraus zu ziehenden Schlüsse.
Was ist Software Delivery Performance?
Ins Deutsche lässt sich Software Delivery Performance in etwa mit Leistungsfähigkeit bei der Software-Bereitstellung übersetzen. Die deutsche Version klingt im Vergleich zum englischen Original ein wenig holprig, drückt aber gut aus, worum es geht. Der Begriff Leistungsfähigkeit beschreibt, wie gut jemand in etwas ist. Und der Begriff Software-Bereitstellung steht für mehr, als die eigentliche Entwicklung der Software: Bereitstellung beinhaltet auch deren Auslieferung. Entsprechend beschreibt der Begriff Software Delivery Performance die Leistungsfähig eines Team bei der Entwicklung und Auslieferung von Software in Produktion.
Software Delivery Performance messen
Das Messen der Leistungsfähigkeit von Softwareteams ist schwierig. Ansätze, wie der Vergleich von Velocity, das Zählen von Lines of Code oder das Messen der Auslastung von Teams waren in der Vergangenheit nur mäßig erfolgreich. Bei der Suche nach besseren Messkriterien legten die Autor*innen zwei Kernanforderungen zugrunde:
1. Globale über lokale Ergebnisse. Ein Beispiel für ein globales Ergebnis ist die vollständige Auslieferung eines Features in Produktion. Hingegen ist die Übergabe des Features von der Entwicklung ans Operations-Team ein lokales Ergebnis.
2. Ergebnisse über Leistung. Statt des investierten Aufwands, wie z.B. Arbeitszeit, werden Ergebnisse, wie gelieferte Features gemessen.
Im Zuge ihrer Forschung haben die Autor*innen vier Kriterien zur Messung von Software Delivery Performance festgelegt, die die oben genannten Kriterien erfüllen: Lead Time, Deployment Frequency, Mean Time to Restore und Change Failure Rate. Die vier Kriterien werden in der DevOps-Forschung The Four Key Metrics genannt.
The Four Key Metrics
Lead Time
Lead Time bezeichnet die Zeit, die vom Commit bis zum Deployment des Features in Produktion vergeht. Die hier verwendete Lead Time weicht von der aus dem Lean Software Development bekannten Lead Time-Definition insofern ab, als dass sie den Commit-Zeitpunkt und nicht den Beginn der Entwicklung als Startzeitpunkt verwendet. Der Grund für diese Redefinition ist, dass Commit-Zeitpunkte klar definiert und damit einfacher mess- und vergleichbar sind.
Deployment Frequency
Deployment Frequency misst die Anzahl der Produktions-Deployments bezogen auf unterschiedliche Zeitintervalle, z.B. mehrmals am Tag oder zwischen einmal pro Woche und einmal pro Monat.
Mean Time to Restore
Mean Time to Restore misst die Zeit vom Entdecken eines Problems oder Fehlers bis zu dessen Behebung. Anders formuliert: Wie lange dauert es, den Service oder die App wieder funktionsfähig zu bekommen?
Change Failure Rate
Die Change Failure Rate misst den Anteil der Änderungen, die zu einem Fehler in Produktion führen. Ein Fehler ist dabei definiert als: Es muss etwas getan werden, z.B ein Rollback oder Hotfix.
Annahme: Wer häufig deployed macht auch häufig etwas kaputt
Ausgehend von den Four Key Metrics haben die Autor*innen Fragebögen entwickelt und Softwareteams rund um die Welt befragt. Basierend auf den Ergebnisse von mehr als 23.000 Umfragen haben die Autoren*innen die teilnehmenden Teams in High, Medium und Low Performers unterteilt. Die folgenden Daten basieren auf den Ergebnissen des Jahres 2017:
High Performers:
Deployment Frequency: Mehrmals am Tag
Lead Time: Weniger als eine Stunde
Mean Time to Restore: Weniger als eine Stunde
Change Failure Rate: 0-15%
Medium Performers:
Deployment Frequency: Zwischen einmal in der Woche und einmal im Monat
Lead Time: Zwischen einmal in der Woche und einmal im Monat
Mean Time to Restore: Weniger als ein Tag
Change Failure Rate: 0-15%
Low Performers:
Deployment Frequency: Zwischen einmal in der Woche und einmal im Monat
Lead Time: Zwischen einmal in der Woche und einmal im Monat
Mean Time to Restore: Zwischen einem Tag und einer Woche
Change Failure Rate: 31-45%
Lead Time und Deployment Frequency messen das Tempo und Mean Time to Restore und Change Fail Percentage die Stabilität der Software Delivery Performance. Ein Team mit hoher Liefergeschwindigkeit liefert Features schnell in Produktion aus. Ein Team mit hoher Lieferstabilität sorgt zudem dafür, dass die gelieferten Features stabil sind und wenig Seiteneffekte haben.
Nun könnte man davon aus gehen, je höher das Tempo ist, desto geringer sind Qualität und Stabilität. Tatsächlich widerlegen die gesammelten Daten diese Annahme. Teams, die mit hoher Geschwindigkeit Software liefern, machen auch deutlich weniger kaputt, als langsam liefernde Teams.
Warum ist das alles wichtig?
Dieser Beitrag beschreibt die Four Key Metrics zum Messen von Software Delivery Performance. Die Kriterien helfen dabei Entwicklungsteams hinsichtlich ihrer Lieferleistung zu beurteilen und zu vergleichen. Aber bedeuten die gewonnenen Erkenntnisse auch, dass Teams, die häufig deployen, auch bessere Features bauen, diese schnelle ausliefern und die Kunden zufriedener sind? Die Antwort auf diese und weitere Fragen finden Sie im zweiten Beitrag dieser Reihe, der in den kommenden Wochen erscheint.
