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

Messen von DORA-Metriken

Datenerfassung: Manuell im Vergleich zu automatisiert

Die automatisierte Datenerfassung ist der beste Weg, um ungenaue Messwerte zu vermeiden, die wiederum zu falschen Geschäftsentscheidungen führen. Die Automatisierung jedes einzelnen Parameters bei der Berechnung einer Metrik ist jedoch aufgrund von Einschränkungen möglicherweise nicht immer möglich. In solchen Fällen sollten Sie sich auf einen vernünftigen, an Branchenstandards ausgerichteten manuellen Ansatz einigen.

Durchlaufzeit:

Gemessen anhand der Zeit, die eine Funktion benötigt, um von einer Geschäftsanfrage zur Produktion zu gelangen. Dies kann durch den Einsatz mehrerer Tools bei jedem Schritt gemessen werden.

• Tests und Bereitstellungen automatisieren (CI/CD-Pipelines).
• Batch-Größen reduzieren (kleinere, häufigere Änderungen).
• Code-Review- und Freigabeprozesse verbessern.
• Engpässe überwachen (z. B. lange QA-Zyklen, manuelle Freigaben)

Manuelle Methode:

Wenn erforderliche Tools/Plugins für die automatisierte Berechnung der Durchlaufzeit nicht verfügbar sind, kann ein manueller Ansatz gewählt werden. Sie können die Durchlaufzeit in Azure DevOps (ADO) oder ähnlichen Systemen mithilfe von manuellen Rohdatenexporten berechnen. Hier ist eine Schritt-für-Schritt-Anleitung:

Datenextraktion

• Quelle: ADO-Arbeitselementabfrage oder API.

Umfang:

• Filtern Sie nach Funktionen/User Stories , die als Erledigt  markiert sind (d. h. in der Produktion bereitgestellt wurden).

Extrahieren:

• Erstelldatum (wann das Arbeitselement angefordert wurde).
• Datum des Abschlusses/der Fertigstellung (wann es als „Erledigt“ markiert wurde).

Formel für die Durchlaufzeit von Funktionen/User Stories:

• Durchlaufzeit (pro Element) = Datum des Abschlusses - Erstelldatum

Formel für den Projektdurchschnitt

• Durchschnittliche Durchlaufzeit = Summe (Durchlaufzeit pro Element) ÷ Gesamtzahl der Elemente

* Hinweis: In Fällen, in denen geplante Funktionen im Voraus erstellt werden, spiegelt die Metrik der Durchlaufzeit dies möglicherweise nicht korrekt wider; in diesen Fällen kann die Zykluszeit als alternative Metrik verwendet werden.

Bereitstellungshäufigkeit:

• Zählen Sie die Anzahl der Bereitstellungen in der Produktion über einen 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 Bereitstellungen/Anzahl der Monate

Formel für den Projektdurchschnitt:

• Anzahl der Bereitstellungen des Projekts/Anzahl der Monate

*Hinweis: Gemäß der Branchendefinition sind Hotfix-Bereitstellungen von der Zählung der Bereitstellungen ausgeschlossen.

Fehlerrate von Änderungen:

Was gilt als „fehlgeschlagene Bereitstellung“?

• Rollbacks (Rückgängigmachung einer Freigabe aufgrund von Problemen).
• Hotfixes (dringende Korrekturen nach der Bereitstellung).

Nachverfolgungsmethode:

• Integration in die CI/CD-Pipeline zur Markierung von Bereitstellungsfehlern (z. B. Jenkins, GitHub Actions).
• Verwendung von Incident-Management-Tools (z. B. ADO, Jira, ServiceNow).

 Formel für die Rate von fehlerhaften Änderungen:

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

Manuelle Methode:

Zur Berechnung der Anzahl fehlgeschlagener Änderungen kann die Anzahl der Support-Vorfälle herangezogen werden, die als „Softwarefehler“ eingestuft sind. Dies, geteilt durch die Gesamtzahl der veröffentlichten Änderungen, ergibt die Fehlerrate.

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

Mittlere Wiederherstellungszeit (MTTR):

Was zählt als „Wiederherstellungszeit“?

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

Nachverfolgungsmethode:

• Incident-Management-Tools (z. B. ADO, Jira).
• Überwachungssysteme (z. B. CloudWatch, Prometheus) zur Aufzeichnung der Behebungszeiten.

Formel zur Berechnung der MTTR:

• Summe der Wiederherstellungszeiten ÷ Anzahl der Ausfälle

Manuelle Methode:

Die Summe der Wiederherstellungszeiten lässt sich anhand der Support-Vorfälle ermitteln, die als „Softwarefehler“ eingestuft sind. Als Zähler kann die Differenz in Tagen zwischen dem „Erstelldatum“ und dem „Schließungsdatum“ verwendet werden.

Als Nenner kann die Anzahl der Vorfälle verwendet werden, die als „Softwarefehler“ eingestuft sind.

Verknüpfung von ADO, CI/CD und Überwachungssystemen

Das regelmäßige Erfassen dieser Kennzahlen und deren Optimierung helfen Unternehmen dabei, Effizienz bei der Softwarebereitstellung zu erreichen.

Der Einsatz effektiver Tools und Plugins sowie deren Integration tragen dazu bei, die meisten dieser Aufgaben zu automatisieren, Kennzahlen zu generieren und geeignete Entscheidungen zu treffen.

Azure DevOps (ADO) stellt die erforderlichen Metadata bereit, um die Rohdaten für die Berechnung dieser Kennzahlen zu erfassen. Das DevOps-Team muss dies unter Berücksichtigung der zukünftigen Geschäftsanforderungen sorgfältig evaluieren.

Visualisierungstools und Dashboards

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

Alternative Tools wie Power BI oder Grafana können für eine verbesserte Visualisierung und Berichte für Stakeholder eingesetzt werden.

Herausforderungen und Überlegungen für Unternehmen

Datenerfassung und Nutzung von Tools

Datenintegrität und Tool-Einschränkungen

Herausforderungen:

• Inkonsistente Datenquellen: DevSecOps-Pipelines rufen Daten aus verschiedenen Tools ab (CI/CD-Systeme, Scanner, Incident-Tracker), was zu nicht übereinstimmenden Zeitplänen, Fehlalarmen oder Lücken führt.
• Verzerrung durch manuelle Berichterstattung: Von Menschen zusammengestellte Messwerte (z. B. Störfallberichte) sind oft nicht standardisiert, was Trends wie MTTR (Mean Time to Recover) verfälscht.

Lösung:

• Nachvollziehbarkeit sicherstellen: Verwenden Sie unveränderliche Metadata (z. B. Azure DevOps Pipeline-IDs, Git-Commits), um Daten zu Codeänderungen zu extrahieren.
• Mit toolübergreifender Korrelation validieren: Kombinieren Sie Daten von SonarQube (Code-Qualität), ADO zur Kennzeichnung von Anomalien und Industriestandards zur Validierung von Metrikdaten.

Verfügbarkeit von Tools & Plugins

Herausforderung:

• Unternehmen haben möglicherweise keinen Zugriff auf integrierte DevSecOps-Tools (z. B. SAST/DAST-Scanner, Deployment-Tracker) oder kämpfen mit Lizenzkosten.

Lösung:

• Nutzen Sie den Azure DevOps Marketplace für Plugins (z. B. OWASP ZAP, SonarQube).
• Verwenden Sie Open-Source-Alternativen, wenn das Budget begrenzt ist.

Konfiguration von ADO zur Erfassung von Metadata

Herausforderung:

• Die Rohdaten von ADO (Builds, Releases, Arbeitselemente) erfordern eine ordnungsgemäße Kennzeichnung/Verknüpfung, um Metriken wie Lead Time oder Deployment Frequency zu generieren.

Lösung:

• Pflichtfelder erzwingen in Arbeitselementen und regelmäßige Aktualisierungen.
• Verwenden Sie ADO Analytics Views oder Power BI Connectors, um Pipeline-Metadata abzufragen.

Effektive Aktualisierungen bei Statusänderungen von Arbeitselementen

Herausforderung:

• Manuelle Statusaktualisierungen (z. B. Erledigt → Genehmigt) verzögern Metriken wie Cycle Time.

Lösung:

• Übergänge automatisieren mithilfe von ADO Webhooks oder Azure Functions (z. B. automatische Aktualisierung beim Zusammenführen von PRs).
• Ordnen Sie Stati DevSecOps-Gates zu (z. B. Sicherheitsüberprüfungsstatus vor der Bereitstellung).

Unzureichende Daten zur Erstellung von Messwerten

Herausforderung:

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

Lösung:

• Mindest Schwellenwerte definieren (z. B. „Nur verfolgen, wenn > 5 Vorfälle in der Kategorie Softwarefehler“).

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

Herausforderung:

• Schmuckmetriken (z. B. „MTTR von 120 Tagen“) treiben keine Maßnahmen voran.

Lösung:

• Konzentrieren Sie sich auf ergebnisorientierte Metriken, die durch ausreichende Daten gestützt werden

Organisatorischer Widerstand und Missbrauch

Organisatorischer Widerstand

Herausforderungen:

• Angst vor Offenlegung: Teams sträuben sich möglicherweise gegen Metriken, die Ineffizienzen aufzeigen (z. B. hohe Änderungsfehlerrate aufgrund von Sicherheitsablehnungen).
• Tool-Überlastung: Die Einführung neuer DevSecOps-Tools, zu erfassender Metadata & Plugins (z. B. SAST-Scanner) kann auf Ablehnung stoßen, wenn sie als störend oder unnötig empfunden wird.
• Falsch ausgerichtete Anreize: Die Führungsebene belohnt eine Metrik mehr als andere. Die alleinige Betrachtung der „Durchlaufzeit“ kann in die Irre führen

Minderungsstrategien:

• Metriken als Verbesserungswerkzeuge darstellen:
  • Betonen Sie, wie diese Metriken dem Unternehmen langfristig helfen und wie sie die Leistung vergleichen oder messen
• Metriken testen:
  • Beginnen Sie mit unkritischen Projekten, um den Nutzen vor einer unternehmensweiten Einführung zu demonstrieren, und konzentrieren Sie sich auf Metriken, die einen Geschäftswert bieten.

Langfristige Unternehmensziele im Vergleich zu kennzahlbasierten Ergebnissen

Herausforderung:

• Falsche Ausrichtung: Die kurzfristige Optimierung von Kennzahlen (z. B. die Verbesserung der Deployment Frequency) kann im Widerspruch zu langfristigen Zielen stehen (z. B. dem Abbau technischer Schulden oder der Reife im Bereich Compliance).
• Scheinkennzahlen vs. Wertschöpfung: Teams priorisieren möglicherweise Kennzahlen, die gut aussehen, anstatt sich auf aussagekräftige Ergebnisse zu konzentrieren.

Lösung:

Übertragung von Kennzahlen auf strategische Themen:

• Zuordnung von Kennzahlen (z. B. Lead Time) zu Geschäftszielen (z. B. „Schnellere Markteinführung für compliance-kritische Produkte“).

Herausforderung:

Die Kennzahlen-Falle bei der Erstellung der Roadmap: Die übermäßige Fokussierung auf eine einzelne Kennzahl (z. B. MTTR) kann dazu führen, dass systemische Probleme (z. B. unzureichende Testautomatisierung) ignoriert werden.

Lösung:

Gewichtete Kennzahlen-Portfolios:

• Bringent Sie Kennzahlen in Einklang mit den langfristigen Zielen des Unternehmens (z. B. Deployment Frequency) und der Stabilität (Change Fail Rate), anstatt nur auf die Lead Time zu achten.

Abstimmung von Kennzahlen und Teamkultur

Die kulturellen Risiken einer Übermetrifizierung

Herausforderungen:

• Angst vor Messung: Teams empfinden Kennzahlen möglicherweise als Überwachung, was zu Stress und Burnout führt.
• Ausnutzen des Systems: Der Druck, Vorgaben zu erreichen (z. B. Deployment Frequency), kann dazu verleiten, Abkürzungen zu nehmen (z. B. das Überspringen von Sicherheitsscans).
• Erstickung der Innovation: Eine übermäßige Fokussierung auf Kennzahlen kann Experimente hemmen (z. B. aus Angst, dass fehlgeschlagene Deployments die Change Fail Rate negativ beeinflussen).

Lösung:

• Psychologische Sicherheit an erster Stelle:
  • Betonen Sie, dass Kennzahlen Diagnosetools und keine Leistungsbewertungen sind.
  • Feiern Sie „Lernen aus Fehlern“ (z. B. durch Analysen nach Zwischenfällen, die die MTTR verbessern).
• Von Teams geleitetes Kennzahlen-Design:
  • Beteiligen Sie Ingenieure an der Auswahl von Kennzahlen (z. B. indem sie wählen können, ob Lead Time oder Cycle Time für sie Priorität vor der Change Failure Rate hat).

Kennzahlen im Vergleich zu Teamkompetenzen und Schulungsbedarf

Kompetenzlücken, die Kennzahlen blockieren

Herausforderung:

Teams fehlen die Fähigkeiten zur Verbesserung wichtiger Kennzahlen (z. B. langsame Lead Time aufgrund von Unkenntnis der Sicherheitstools).

Lösungen:

• Kompetenzbasierte Kennzahlen-Segmentierung:
  • Beispiel: Getrennte Erfassung der Lead Time für Teams, die neue SAST-Tools einführen.
• Bedarfsgerechte Schulung (Just-in-Time):
  • Automatisieren Sie Schulungsauslöser (z. B. Zuweisung modularer Schulungen, wenn die Failed Pipeline Rate Due to Security >15 % beträgt).
• Kennzahlen zum Mentoring:
  • Messen Sie % der Pair-Programming-Sitzungen, um den Wissensaustausch zu fördern.

Kennzahlen, die das Teamwachstum ignorieren

Herausforderung:

• Eine zu starke Fokussierung auf Leistungskennzahlen (z. B. Bereitstellungshäufigkeit) wertet den Kompetenzaufbau ab.

Lösungen:

• Leistungs- und Wachstumsmetriken ausgleichen:
  • Kombinieren Sie Bereitstellungshäufigkeit mit % des Teams, das Code für die Pipeline beisteuert.
• Kennzahlen zur Karriereentwicklung:
  • Beispiel: Verfolgen Sie % der Entwickler, die Sicherheitsüberprüfungen leiten, um Eigenverantwortung zu fördern.

Quellenangaben

• Accelerate von Forsgren, Humble & Kim
• Azure DevOps-Dokumentation
• DevOps Research and Assessment (DORA)-Berichte