DORA-Kennzahlen meistern: Ein praktischer Leitfaden zur Messung und Verbesserung der Softwarebereitstellung

Erfassung der DORA-Kennzahlen

Datenerfassung: Manuell vs. automatisiert

Die automatisierte Datenerfassung ist der beste Weg, um ungenaue Kennzahlen zu vermeiden, die wiederum zu falschen Geschäftsentscheidungen führen können. Allerdings ist es aufgrund von Einschränkungen unter Umständen nicht möglich, jeden für die Berechnung einer Kennzahl relevanten Parameter zu automatisieren. In solchen Fällen sollten Sie sich auf einen manuellen Ansatz einigen, der sinnvoll ist und den Branchenstandards entspricht.

Lieferzeit:

Gemessen anhand der Zeit, die eine Funktion benötigt, um von der Geschäftsanforderung in die Produktion zu gelangen. Dies lässt sich durch den Einsatz mehrerer Tools in jedem Schritt ermitteln.

• Automatisierung von Tests und Bereitstellungen(CI/CD-Pipelines).
• Die Losgrößen reduzieren(kleinere, häufigere Änderungen).
• Verbesserung der Prozesse zur Code-Prüfung und -Freigabe.
• Engpässe überwachen(z. B. lange QA , manuelle Freigaben)

Manuelle Methode:

Wenn die erforderlichen Tools/Plugins für die automatische Berechnung der Durchlaufzeit nicht verfügbar sind , kann ein manueller Ansatz gewählt werden. Sie können die Durchlaufzeitin Azure DevOps (ADO) oder ähnlichen Systemen anhand von Rohdatenauszügenmanuell berechnen . Hier ist eine Schritt-für-Schritt-Anleitung:

Datenextraktion

• Quelle: ADO -Work-Item-Abfrage oder API.

Geltungsbereich:

• Filtere nachFunktionen/User Stories, die als„Erledigt“markiert sind(d. h. in der Produktion bereitgestellt wurden).

Auszug:

• Erstellungsdatum (Datum, an dem das Workitem angefordert wurde).
• Datum der Schließung/Abschluss(wenn als „Erledigt“ markiert).

Formel für die Durchlaufzeit von Feature/User Story:

• Durchlaufzeit ( pro Artikel) = Abschlussdatum – Erstellungsdatum

Formel für den Durchschnitt auf Projektebene

• Durchschnittliche Vorlaufzeit = Summe (Vorlaufzeit pro Artikel) ÷ Gesamtzahl der Artikel

* Hinweis: Wenn geplante Funktionen im Voraus erstellt werden, gibt die Vorlaufzeit-Kennzahl kein realistisches Bild wieder; in solchen Fällen kann die Durchlaufzeit als alternative Kennzahl herangezogen werden.

Häufigkeit der Bereitstellung:

• Zählen Sie die Anzahl der Produktivbereitstellungen in einem bestimmten Zeitraum (z. B. pro Tag, Woche oder Monat).

Datenextraktion:

• Verwenden Sie CI/CD-Tools (z. B. GitHub Actions), um die Anzahl der Bereitstellungen zu protokollieren.

Formel für die Bereitstellungshäufigkeit:

• Gesamtzahl der Einsätze /Anzahl der Monate

Formel für den Durchschnitt auf Projektebene:

• Anzahl der Projektbereitstellungen / Anzahl der Monate

*Hinweis: Gemäß der branchenüblichen Definition werden Hotfix- Bereitstellungen bei der Zählung der Bereitstellungen nicht berücksichtigt.

Fehlerquote ändern:

Was gilt als „fehlgeschlagene Bereitstellung“?

• Rollbacks (Rücknahme einer Version aufgrund von Problemen).
• Hotfixes (dringende Patches nach der Bereitstellung).

Verfolgungsmethode:

• Integration mitCI/CD-Pipelines (z. B. Jenkins, GitHub Actions) zur Erkennung von Fehlern bei der Bereitstellung.
• Verwenden Sie Tools fürdas Vorfallmanagement (z. B. ADO, Jira, ServiceNow).

 Formel zur Berechnung der Ausfallrate:

• Anzahl der fehlgeschlagenen Änderungen ÷ Gesamtzahl der Änderungen × 100.

Manuelle Methode:

Um die Anzahl der fehlgeschlagenen Änderungen zu berechnen, kann die Anzahl der Supportfälle herangezogen werden, die als„Softwarefehler“eingestuft wurden. Diese Zahl geteilt durch die Gesamtzahl der veröffentlichten Änderungen ergibt den CFR.

Unternehmen müssen die Vorfälle regelmäßig klassifizieren lassen, damit die Kennzahl genau ist.

Durchschnittliche Wiederherstellungszeit (MTTR):

Was gilt als „Erholungszeit“?

• Start:Wenn der Fehler erkannt wird (Alarm ausgelöst).
• Ende:Wenn das System vollständig wiederhergestellt ist (z. B. Rollback abgeschlossen, Hotfix bereitgestellt).

Verfolgungsmethode:

• Tools für das Vorfallmanagement(z. B. ADO, Jira).
• Überwachungssysteme(z. B. CloudWatch, Prometheus) zur Erfassung der Lösungszeit

Formel zur Berechnung der MTTR:

• Summe der Wiederherstellungszeiten ÷ Anzahl der Ausfälle

Manuelle Methode:

Die Summe der Wiederherstellungszeiten lässt sich anhand der Supportfälle ermitteln, die als„Softwarefehler“ klassifiziert sind. Als Zähler kann die Differenz zwischen „Erstellungsdatum“ und „Schließungsdatum“ in Tagen herangezogen werden.

Die Anzahl der als„Softwarefehler“klassifizierten Vorfälle kann als Nenner herangezogen werden.

ADO, CI/CD und Überwachungssysteme miteinander verbinden

Die regelmäßige Erfassung dieser Kennzahlen und deren Optimierung helfen Unternehmen dabei, ihre Software-Veröffentlichungsprozesse effizienter zu gestalten.

Mit leistungsfähigen Tools und Plugins sowie deren Integration lassen sich die meisten dieser Aufgaben automatisieren, Kennzahlen generieren und fundierte Entscheidungen treffen.

Azure DevOps (ADO) stellt die erforderlichen metadata zur Erfassung der Rohdaten für die Berechnung dieser Kennzahlen. Das DevOps-Team muss eine sorgfältige Bewertung unter Berücksichtigung der zukünftigen Geschäftsanforderungen vornehmen.

Visualisierungstools und Dashboards

Azure DevOps (ADO) bietet Dashboard-Funktionen mit diesen metadata und Widgets, um einige dieser Kennzahlen zu erfassen. Es ist jedoch unerlässlich, sicherzustellen, dass metadata für jedes Arbeitselement aktualisiert metadata , um genaue Kennzahlen zu generieren.

Für eine verbesserte Visualisierung und Berichterstellung für die Interessengruppen können alternative Tools wie Power BI und Grafana eingesetzt werden.

Herausforderungen und Überlegungen für Organisationen

Datenerhebung und Einsatz von Tools

Datenintegrität und Einschränkungen der Tools

Herausforderungen:

• Inkonsistente Datenquellen:DevSecOps-Pipelines beziehen Daten aus unterschiedlichen Tools (CI/CD-Systeme, Scanner, Incident-Tracker), was zu zeitlichen Diskrepanzen, Fehlalarmen oder Lücken führt.
• Verzerrung durch manuelle Berichterstattung:Von Menschen zusammengestellte Kennzahlen (z. B. Störungsmeldungen) sind oft nicht standardisiert, was Trends wiedie MTTR(Mean Time to Recovery) verzerrt.

Lösung:

• Rückverfolgbarkeit sicherstellen:Verwenden Sie unveränderliche metadata z. B.Pipeline-IDs von Azure DevOps, Git-Commits), um Daten zu Codeänderungen zu extrahieren.
• Validierung durch werkzeugübergreifende Korrelation:Kombination von Daten aus SonarQube (Codequalität), ADO zur Erkennung von Anomalien und Branchenstandards zur Validierung von Metrikdaten

Verfügbarkeit von Tools und Plugins

Herausforderung:

• Unternehmen haben möglicherweise keinen Zugang zu integrierten DevSecOps-Tools (z. B. SAST-/DAST-Scanner, Deployment-Tracker) oder haben Schwierigkeiten mit den Lizenzkosten.

Lösung:

• Nutzen Sieden Azure DevOps Marketplacefür Plugins (z. B.OWASP ZAP,SonarQube).
• Nutzen SieOpen-Source-Alternativen, wenn das Budget begrenzt ist.

Konfiguration von ADO für die Erfassung von Metadata

Herausforderung:

• Die Rohdaten von ADO (Builds, Releases, Arbeitselemente) müssen ordnungsgemäß mit Tags versehen bzw. verknüpft werden, um Kennzahlen wieDurchlaufzeitoderBereitstellungshäufigkeit zu generieren.

Lösung:

• Pflichtfelderin Arbeitsaufträgen und regelmäßige Aktualisierungen durchsetzen
• Verwenden SieADO Analytics ViewsoderPower BI-Konnektoren, um metadata der Pipeline abzufragen.

Wirksame Aktualisierungen bei Änderungen des Status von Arbeitsaufgaben

Herausforderung:

• Manuelle Statusaktualisierungen (z. B. „Erledigt“ → „Genehmigt“) verzögern Kennzahlen wiedie Durchlaufzeit.

Lösung:

• Automatisieren Sie Übergängemithilfe von ADO-WebhooksoderAzure Functions(z. B. automatische Aktualisierung beim Zusammenführen von Pull-Anfragen).
• Ordne Zuständeden DevSecOps-Prüfpunktenzu (z. B. den Zustand „Sicherheitsüberprüfung“ vor der Bereitstellung).

Es liegen nicht genügend Daten vor, um Kennzahlen zu erstellen

Herausforderung:

• Lückenhafte Daten (z. B. seltene Bereitstellungen, geringe Anzahl von Vorfällen pro Projekt) verzerren die Trends.

Lösung:

• Legen Sie Mindestschwellenwerte fest(z. B. „Nur verfolgen, wenn >5 Vorfälle der Kategorie ‚Softwarefehler‘“).

Kennzahlen, die für Entscheidungen nicht aussagekräftig sind

Herausforderung:

• Eitelkeitskennzahlen (z. B. „MTTR von 120 Tagen“) führen nicht zu konkreten Maßnahmen.

Lösung:

• Konzentrieren Sie sich aufergebnisorientierte Kennzahlen, die durch ausreichende Daten untermauert sind

Widerstand innerhalb der Organisation und Missbrauch

Widerstand innerhalb der Organisation

Herausforderungen:

• Angst vor Bloßstellung:Teams könnten sich gegen Kennzahlen wehren, die Ineffizienzen aufzeigen (z. B.einehoheFehlerquote bei Änderungenaufgrund von Sicherheitsablehnungen).
• Tool-Überlastung:Die Einführung neuer DevSecOps-Tools, metadata erfassender metadata und Plugins (z. B. SAST-Scanner) kann auf Widerstand stoßen, wenn sie als störend oder unnötig empfunden werden.
• Fehlausgerichtete Anreize:Die Führung belohnt eine Kennzahl gegenüber anderen. „Durchlaufzeit“ allein kann in die Irre führen

Maßnahmen zur Risikominderung:

• Rahmenkennzahlen als Instrumente zur Verbesserung:
  • Heben Sie hervor, wie diese Kennzahlen dem Unternehmen langfristig helfen und wie sie dazu dienen, die Leistung zu vergleichen oder zu messen
• Pilotkennzahlen:
  • Beginnen Sie mit weniger kritischen Projekten, um den Nutzen vor der unternehmensweiten Einführung zu demonstrieren, und konzentrieren Sie sich auf Kennzahlen, die einen geschäftlichen Mehrwert bieten.

Langfristige Ziele der Organisation im Vergleich zu den aus Kennzahlen abgeleiteten Ergebnissen

Herausforderung:

• Fehlausrichtung:Die kurzfristige Optimierung von Kennzahlen (z. B. die Erhöhungder Bereitstellungshäufigkeit) kann im Widerspruch zu langfristigen Zielen stehen (z. B. Abbau technischer Schulden, Reifegrad der Compliance).
• Eitelkeitskennzahlen vs. Wertschöpfung:Teams geben möglicherweise Kennzahlen den Vorrang, die gut aussehen, anstatt auf aussagekräftige Ergebnisse zu achten.

Lösung:

Kaskadierung von Kennzahlen zu strategischen Themen:

• Ordnen Sie Kennzahlen (z. B.Durchlaufzeit) den Geschäftszielen zu (z. B. „Schnellere Markteinführung für Produkte, bei denen die Einhaltung gesetzlicher Vorschriften entscheidend ist“).

Herausforderung:

Die „Metrik-Falle“ bei der Festlegung einer Roadmap: Eine zu starke Konzentration auf eine einzige Kennzahl (z. B.MTTR) kann dazu führen, dass systemische Probleme (z. B. unzureichende Testautomatisierung) übersehen werden.

Lösung:

Gewichtete Metrik-Portfolios:

• Stellen Sie die Kennzahlen in Einklang mit den langfristigen Zielen des Unternehmens (z. B. Bereitstellungshäufigkeit), der Stabilität (Fehlerquote bei Änderungen) und der Durchlaufzeit

Kennzahlen und Teamkultur in Einklang bringen

Die kulturellen Risiken einer übermäßigen Messung

Herausforderungen:

• Angst vor der Leistungsmessung:Teams könnten Kennzahlen als Überwachung empfinden, was zu Stress und Burnout führen kann.
• Das System ausnutzen:Der Druck, bestimmte Ziele zu erreichen (z. B.die Häufigkeit von Bereitstellungen), kann dazu führen, dass Abkürzungen genommen werden (z. B. das Überspringen von Sicherheitsscans).
• Innovationshemmnis:Eine übermäßige Konzentration auf Kennzahlen kann Experimente behindern (z. B. aus Angst, dass fehlgeschlagene Bereitstellungendie Fehlerquote bei Änderungen erhöhen).

Lösung:

• Psychologische Sicherheit steht an erster Stelle:
  • Betonen Sie, dass KennzahlenDiagnosewerkzeuge sind und keine Leistungsbewertungen.
  • Fördern Sie das „Lernen aus Fehlern“ (z. B. Nachbesprechungen nach Vorfällen, diedie MTTR verbessern).
• Teamorientiertes Metrikdesign:
  • Beziehen Sie die Ingenieure in die Auswahl der Kennzahlen ein (lassen Sie sie beispielsweise entscheiden, ob sieder Durchlaufzeitoderder ZykluszeitVorrang vor der Fehlerquote bei Änderungen einräumen möchten).

Kennzahlen im Vergleich zu Teamkompetenzen und Schulungsbedarf

Kompetenzlücken, die die Messung behindern

Herausforderung:

Den Teams fehlen die Fähigkeiten, um wichtige Kennzahlen zu verbessern (z. B. langeDurchlaufzeitenaufgrund mangelnder Vertrautheit mit Sicherheitstools)

Lösungen:

• Kompetenzbasierte Metriksegmentierung:
  • Beispiel: Erfassen Siedie Durchlaufzeitseparat für Teams, die neue SAST-Tools einsetzen
• Schulungen nach Bedarf:
  • Auslösebedingungen für das Training automatisieren (z. B.: Wenndie Rate der fehlgeschlagenen Pipelines aufgrund von Sicherheitsproblemen>15 % beträgt, modulares Training zuweisen).
• Kennzahlen zum Mentoring:
  • Ermittle den prozentualen Anteil der Paarprogrammierungssitzungen, um den Wissensaustausch zu fördern.

Kennzahlen, die das Wachstum des Teams außer Acht lassen

Herausforderung:

• Eine übermäßige Fokussierung auf Output-Kennzahlen (z. B.die Häufigkeit von Bereitstellungen) führt dazu, dass der Aufbau von Kompetenzen vernachlässigt wird.

Lösungen:

• Ausgleich zwischen Ergebnis- und Wachstumskennzahlen:
  • Vergleichedie Häufigkeit des Einsatzesvon Paaren mit dem prozentualen Anteil des Teams, das zum Code der Pipeline beiträgt.
• Kennzahlen zur beruflichen Laufbahn:
  • Beispiel: Erfassen Sie den Prozentsatz der Ingenieure, die Sicherheitsüberprüfungen leiten, um das Verantwortungsbewusstsein zu fördern.

Referenzen

• „Accelerate“ von Forsgren, Humble & Kim
• Azure DevOps-Dokumentation
• DevOps-Forschungs- und Bewertungsberichte (DORA)