Die Teilnehmer waren eine bunt gemischte Gruppe von IT-Führungskräften aus verschiedenen Branchen, darunter E-Commerce und Softwareentwicklung. Trotz ihrer unterschiedlichen Hintergründe waren sich alle einig, dass die Messung der Engineering-Produktivität von verschiedenen Faktoren „abhängt“, wie beispielsweise der Reife des Unternehmens dora metrics.
Es ergaben sich vorhersehbare Vorschläge: Commits, Geschwindigkeitspunkte, Anzahl der Pull Requests, Durchsatz usw. – alles Kennzahlen, die wir uns in den vergangenen zehn Jahren angesehen haben, und alle sind kontextuell „abhängig“ vom Publikum, nämlich davon, wie technisch versiert es ist.
Als ich jedoch die Diskussionsrunde verließ und hörte, wie andere Teilnehmer ihre eigenen „es kommt darauf an“-Kennzahlen für die Produktivität der Ingenieure diskutierten, wurde mir klar, dass ich der Meinung bin, dass solche Kennzahlen von nichts abhängen sollten, auch nicht vom Team, den Nutzern der Kennzahlen oder dem Kontext des Produkts. Sowohl nichttechnische Vorstandsmitglieder als auch hochtechnische Mitarbeiter sollten in der Lage sein, dieselbe Sprache zu verstehen und zu verwenden, um die Produktivität des Ingenieurteams zu bewerten.
Und diese Sprache ist DORA .
Was sind dora metrics?
DevOps-Teams verwenden dora metrics, um die Effizienz des Teams zu bewerten, von „niedrigen“ bis hin zu „Elite“-Leistungen. Das DORA-Framework besteht aus vier Metriken:
- Bereitstellungshäufigkeit: Die Kadenz der Codebereitstellung.
- Vorlaufzeit für Änderungen: Wie lange es dauert, bis ein Commit in die Produktion geht.
- Mittlere Zeit bis zur Wiederherstellung: Wie lange es dauert, den Dienst nach einer Unterbrechung wiederherzustellen.
- Änderungsfehlerrate: Die Rate, mit der Bereitstellungen Produktionsfehler verursachen.
Der Fairness halber muss man sagen, dass die Gruppe möglicherweise noch nichts von den dora metrics gehört hat. Deren Namensgeber, DevOps Research and Assessment LLC, war eine Forschungsorganisation für digitale Transformation, die Ende 2018 von Google übernommen wurde. Ihre am längsten laufende jährliche Forschungskampagne „State of DevOps“ untersuchte, was Hochleistungsteams ausmacht – und warum einige Teams vorhersehbar nicht die gewünschten Ergebnisse erzielen. Nachdem die Gruppe jahrelang diese Daten gesammelt hatte, veröffentlichte sie Accelerate: The Science of Lean Software and DevOps . Darin identifizierten sie die Kennzahlen, die diese Hochleistungsorganisationen am besten informierten und vorhersehbar machten.
Mit anderen Worten: Die Gründer von DORA – Nicole Forsgren , Jez Humble und Gene Kim – haben es geschafft, dass die Entwickler nicht mehr darüber rätseln müssen, welche Produktivitätskennzahlen es für Führungskräfte in der Entwicklung tatsächlich wert sind, verfolgt zu werden.
Sehen wir uns genauer an, was jede dieser Messungen bedeutet, wie sie in der Praxis mit DORA-Dashboards aussehen und wie ein IT-Leiter sie jeweils verbessern kann.
1. Einsatzhäufigkeit
Wie oft stellt Ihr Team Code oder Releases für seine Endbenutzer bereit? Unabhängig davon, ob Sie Ihre Bereitstellungen in Monaten, Wochen, Tagen oder Stunden messen, gibt die Bereitstellungshäufigkeit Aufschluss darüber, wie kontinuierlich Ihr Unternehmen tatsächlich arbeitet.
Allstacks bietet mehrere Möglichkeiten, Ihre Bereitstellungshäufigkeit anzupassen und Einblicke in sie zu erhalten. Wenn ein CTO beispielsweise in einem DORA-Dashboard eine monatliche Übersicht über Bereitstellungen anzeigen möchte, kann er Allstacks verwenden, um diese Ansicht auf höchster Ebene zu erhalten oder seine Bereitstellungen auf täglicher Ebene zu analysieren.
Zu den weiteren nützlichen Ansichten dieser DORA-Software gehören Commit-Häufigkeit, Geschwindigkeit zusammengeführter Pull-Requests und Geschwindigkeit nach Team. Diese zusätzlichen Ansichten helfen dabei, führende Indikatoren für Ihre Fähigkeit zur Bereitstellung in der Produktion zu bewerten.
Unabhängig davon, wie Sie die Daten aufteilen, definiert DORA Elite-Teams als solche, die mehrmals am Tag bereitstellen, und Teams mit geringer Leistung als solche, die weniger als einmal alle sechs Monate bereitstellen.
Die Kenntnis Ihrer Bereitstellungshäufigkeit ist wie das Kennen Ihrer Meilenzeit; Sie können stolz auf Ihr Tempo sein, aber es erfordert Strategie und Sorgfalt, Ihre Laufzeit zu verbessern. Und diese Strategie wird anders sein, wenn Ihr Starttempo 16 Minuten, 12 Minuten, 8 Minuten oder unter sechs Minuten beträgt.
In ähnlicher Weise können Elite-Teams, die eine kontinuierliche Bereitstellung erreichen, ein Tool wie Allstacks verwenden, um aufkommende Engpässe zu überwachen und Warnmeldungen zu nutzen, um Ausreißer proaktiv zu verwalten, die ein Team daran hindern könnten, eine hohe Leistung aufrechtzuerhalten, während Teams mit geringer Leistung prüfen sollten, ob sie wirklich über die Infrastruktur für eine kontinuierliche Bereitstellung verfügen.
2. Vorlaufzeit für Änderungen
Die Vorlaufzeit für Änderungen, manchmal auch „Änderungsvorlaufzeit“ genannt, verfolgt, wie lange ein Team von der Erstellung einer Änderungsanforderung bis zur endgültigen Bereitstellung für den Endbenutzer benötigt – sie ist ein Maß für die Geschwindigkeit und die allgemeine Teameffizienz. Wenn Sie nur eine DORA-Kennzahl verfolgen möchten, weil Sie diese Zahlen manuell mit Tabellenkalkulationen berechnen oder sie über JIRA, GitHub und CircleCI zusammenschustern, würde ich diese empfehlen.
Die Vorlaufzeit für Änderungen ist keine statische Messgröße. Wie bei der Bereitstellungshäufigkeit müssen Sie auswählen, über welchen Zeitraum Sie Ihre Vorlaufzeit messen, und die durchschnittliche Anzahl von Commits über mehrere Zeiträume hinweg nehmen.
Beispielsweise kann eine monatliche Vorlaufzeit für Änderungen einen hilfreichen Kontext für Vorstandssitzungen bieten, während wöchentliche Übersichten für Sprint-Überprüfungen hilfreicher sein können.
Die besten DevOps-Teams verfügen über eine beeindruckende Vorlaufzeit von weniger als einer Stunde für Änderungen. DevOps-Teams mit geringer Leistung hingegen können länger als ein halbes Jahr brauchen, um eine einzige Änderung umzusetzen.
Obwohl es viele Ratschläge gibt, wie Sie Ihre Vorlaufzeit für Änderungen verbessern können, besteht die unmittelbarste und wirkungsvollste Erkenntnis, die ich Ihnen geben kann, darin, einen genauen Blick auf die Infrastruktur Ihres Teams zu werfen. Engineering-Schlamm – manuelle Tests, veralteter Frankencode und Silos zwischen Entwicklern und Qualitätssicherung – führt zu langen Vorlaufzeiten (und auch zu unglücklichen Teams). Es gibt keine schnelle Lösung, weshalb die Überwachung der Vorlaufzeit für Änderungen bei der Ausführung des Änderungsmanagements auf strategischer Ebene unerlässlich ist, um Ihre Mitarbeiter langfristig konzentriert und engagiert zu halten.
3. Mittlere Zeit bis zur Wiederherstellung
Wenn es für das Team unvermeidlich zu einem ungeplanten Ausfall oder einer Dienstunterbrechung kommt, misst die mittlere Wiederherstellungszeit (MTTR), die manchmal auch „Zeit bis zur Wiederherstellung des Dienstes“ genannt wird, die durchschnittliche Zeit, die zur Wiederherstellung des Dienstes benötigt wird.
Die Berechnung der mittleren Wiederherstellungszeit ist relativ einfach: Addieren Sie die gesamte Ausfallzeit über einen bestimmten Zeitraum und dividieren Sie diese durch die Anzahl der Vorfälle. Beispiel: Ihr System fiel während zehn Vorfällen in einer Woche vier Stunden lang aus. Vier Stunden sind 240 Minuten. 240 geteilt durch zehn ist 24, also beträgt Ihre mittlere Wiederherstellungszeit über diesen Wochenzeitraum 24 Minuten.
Bei der Berechnung der technischen Leistungsfähigkeit zeigen die dora metrics, dass Eliteteams ihre Ausfälle in atemberaubender Geschwindigkeit beheben: in weniger als einer Stunde.
MTTR ist eine gemischte technische Kennzahl. Sie eignet sich hervorragend, um die Effizienz Ihres Entwicklungsteams zu ermitteln, aber sie verrät nicht, wo in Ihrem Prozess ein Problem besteht. Wenn beispielsweise Ihre Qualitätssicherung nicht auf Anfragen reagiert oder Ihr Warnsystem wöchentliche Zusammenfassungen zurückhält, kann ein Tool zur Ermittlung der MTTR die Nuancen einer langsameren MTTR-Zeit nicht zusammenfassen.
Dennoch gibt es einige Best Practices zur Verbesserung der MTTR. Dazu gehören:
- Dokumentieren Sie Ihren Vorfallreaktionsplan.
- Stellen Sie sicher, dass Ihr CI/CD-System das Testen und die Warnmeldung bei Vorfällen automatisiert.
- Bilden Sie Ihr Team bereichsübergreifend aus, damit Abwesenheiten nicht zu einer einzelnen Fehlerquelle werden.
- Stellen Sie nach einem Vorfall die Ursache fest und finden Sie heraus, ob er in Zukunft verhindert werden kann.
4. Fehlerrate ändern
Wie oft führen Ihre Codeänderungen zu Vorfällen? Die Änderungsfehlerrate beantwortet diese Frage in Prozent: die Anzahl der fehlgeschlagenen Bereitstellungen im Verhältnis zu allen Bereitstellungen in einem bestimmten Zeitraum. Die Änderungsfehlerrate unterscheidet sich von der Fehlerrate, die Vorfälle umfasst, die nach der Bereitstellung auftreten (normalerweise, wenn ein Benutzer etwas tut, das nichts mit dem Entwicklungsprozess zu tun hat).
Bei Allstacks kontextualisieren wir die Änderungsfehlerrate mit erfolgreichen Zusammenführungs- oder Abschlussraten für PRs und Probleme, um die Gesamtwahrscheinlichkeit erfolgreicher Arbeit vorherzusagen.
Es wäre zwar schön, in einer Welt zu leben, in der unsere Änderungsfehlerrate bei null liegt, weil wir keine Zwischenfälle erleben, aber das ist in keiner Softwareorganisation, in der ich je gearbeitet habe, Realität. DORA definiert Elite-DevOps-Teams als solche, die ihre Fehlerrate unter 15 % halten. Nach den Standards von DORA haben Teams mit hoher, mittlerer und niedriger Leistung alle Änderungsfehlerraten zwischen 16 % und 30 %, was bedeutet, dass Ihr Team entweder zur Elite gehört oder nicht; andere Unterkategorien spielen keine Rolle.
Verbessern Sie Ihre Änderungsfehlerrate mit zwei Tricks.
Teilen Sie Ihre Prozesse zunächst in kleinere Einheiten auf. Das bedeutet häufigere, kleinere Bereitstellungen, wodurch sich Fehler in einer bestimmten Version leichter aufspüren lassen.
Zweitens: Erweitern Sie Ihre Prüfprozesse für Merge Requests. Reduzieren oder eliminieren Sie Ad-hoc-Codeänderungen am Projekt-Repository ohne gezielte Prüfung bottleneck calculator.
Wer sollte dora metrics vermeiden? Wer sollte sie zur Leistungsbewertung im Ingenieurwesen verwenden?
Ich würde lügen, wenn ich sagen würde, dass ich alle Star Wars- Filme für gute Filme halte. Ich würde auch lügen, wenn ich behaupten würde, dass alle Teams DORA verwenden sollten. Hier geht es nicht um Psychospielchen.
Hier ist meine Checkliste für Teams, die DORA nicht verwenden sollten:
- Sie sind klein, haben vielleicht weniger als 20 Entwickler, und Ihr Geschäft verändert sich schnell. dora metrics eignen sich am besten für stabilere Unternehmen, die effektiv Basislinien erstellen können.
- Sie praktizieren DevOps nicht wirklich. Wenn Automatisierung eher Theorie als Praxis ist, wird DORA deutlich machen, dass Ihr Team hinter Spitzenkräften steht. Sparen Sie Ihr Geld und konzentrieren Sie sich auf die Verbesserung Ihrer CI/CD-Pipeline.
- Sie möchten DORA für individuelle Leistungsbeurteilungen verwenden. dora metrics können eigentlich nur Aufschluss über die Leistung eines Teams geben. Wenn Sie auf die individuelle Ebene herunterbrechen, geht der notwendige Kontext für die Leistungsbewertung verloren.
- Sie haben strukturelle Probleme, die eine kontinuierliche Entwicklung verhindern, wie z. B. einen Kundenstamm, der nur einmal pro Quartal Änderungen akzeptieren kann. Sie können DORA immer noch für die technische Leistung nutzen … aber die Kennzahlen müssen auf Ihren Kontrollbereich zugeschnitten sein.
- Ihre Entwickler sind aufgrund einer beschissenen Unternehmenskultur ausgebrannt. DORA wird ihre Produktivität nicht für Sie verbessern.
Und hier ist meine Unicorn-Checkliste für die perfekte Organisation, die ihre Engineering-Leistung mit DORA verbessern möchte:
- Ihre IT-Organisation umfasst über 100 Mitwirkende, von Entwicklern über Qualitätssicherungsmitarbeiter bis hin zu Produktbesitzern.
- Sie haben eine produktive Arbeitskultur . Indikatoren für dieses Umfeld sind ein hohes Maß an Zusammenarbeit, die Bereitschaft, Risiken zu teilen, und eine neugierige (übermäßig strafende) Reaktion auf Misserfolge. Sie messen eNPS.
- Sie verfügen über eine ausgereifte CI/CD-Pipeline und DevOps-Konzepte sind für das Team nichts Neues.
- Sie haben in Sachen Sicherheit einen Schritt nach links gemacht.
So starten Sie schnell mit DORA
Wenn Sie CircleCI verwenden, können Sie Allstacks nutzen, um Ihre Daten auf unseren benutzerdefinierten Dashboards zu prüfen und zu kontextualisieren. Nachdem Sie sich zwei Minuten Zeit genommen haben, um sich für eine kostenlose Testversion anzumelden und Ihre Tools zu verbinden, nehmen Sie sich noch drei weitere Minuten Zeit, um Ihre dora metrics zu ermitteln.
Jeremy, unser CTO, zeigt Ihnen, wie es geht.