Verfolgen, was wichtig ist: KPIs und Dashboards

In unserem vorherigen Kapitel, Entwerfen für Testbarkeit: Die nächste Hürde überwindenhaben wir untersucht, wie die Testbarkeit zu einem zentralen Thema wurde, nachdem wir anfängliche Engpässe bei der Teamzusammenstellung und beim manuellen Testen beseitigt hatten. Dieses Kapitel markierte einen Wendepunkt in unserer DevOps-Transformation, als wir unsere Aufmerksamkeit auf tiefer gehende Software-Design-Prinzipien lenkten, die reibungslosere und schnellere Tests ermöglichten.

In Kapitel 4 treten wir nun in die entscheidende nächste Phase ein: die Definition und Verfolgung der richtigen KPIs und die Einrichtung von Dashboards zur Messung unserer Fortschritte. Nachdem wir die grundlegenden Praktiken eingeführt und die Testbarkeit verbessert hatten, brauchten wir objektive, datengesteuerte Möglichkeiten, um den Ablauf zu visualisieren, Einschränkungen zu erkennen und uns kontinuierlich zu verbessern.

Warum KPIs und Dashboards bei DevOps wichtig sind

Im Zuge unserer Bemühungen, die End-to-End-Bereitstellung zu optimieren, erkannten wir die Notwendigkeit eines visuellen und objektiven Mechanismus zur Verfolgung der Arbeit und zur Aufdeckung von Engpässen. Das bedeutete, dass wir KPIs definieren mussten, bei denen es nicht nur um Zahlen ging, sondern darum, verwertbare Erkenntnisse aufzuzeigen und die richtigen Verhaltensweisen zu fördern.

Bei der Festlegung von KPIs ist es wichtig zu erkennen, dass Teams und Organisationen dazu neigen, die von ihnen überwachten Messgrößen zu optimieren. Dies entspricht dem Goodhart'schen Gesetz, das besagt:

"Wenn eine Maßnahme zu einem Ziel wird, hört sie auf, eine gute Maßnahme zu sein".

Dieser Grundsatz unterstreicht, wie wichtig es ist, KPIs auszuwählen, die die Teams zu den richtigen Ergebnissen führen, anstatt sie zu ermutigen, einfach nur Ziele zu erreichen. Der Zweck dieser KPIs ist es, den Fortschritt in Richtung unseres übergeordneten Ziels zu messen. Aber was genau ist dieses Ziel?

Definition des Ziels

Wie in "The Goal " von Eliyahu M. Goldratt beschrieben, besteht das Ziel eines Unternehmens darin, den Nettogewinn zu steigern und gleichzeitig die ROI und Cashflow zu verbessern. Übertragen auf unseren Softwareentwicklungskontext, wo wir uns derzeit in der Investitionsphase befinden, haben wir das Ziel wie folgt identifiziert:

 "Ein marktfähiges Softwareprodukt zu entwickeln und zu liefern, das nachhaltige Einnahmen generiert."

Um dieses Ziel zu erreichen, müssen mehrere Voraussetzungen erfüllt sein, unter anderem:

• Markteinführungszeit → Schnelle Bereitstellung von Funktionen und Produkten, um Marktchancen zu nutzen.
• Zukünftige Skalierbarkeit → Sicherstellung, dass die Software so konzipiert ist, dass sie mit der Nachfrage wächst, ohne die Leistung zu beeinträchtigen.
• Kostenoptimierung → Ausgleich der Entwicklungskosten bei gleichzeitiger Maximierung der Wertschöpfung.
• Return on Investment (ROI) → Sicherstellung, dass das Produkt langfristige finanzielle Vorteile bringt, die die Investition rechtfertigen.

An diesen Bedingungen orientierten wir uns bei der Definition unserer KPIs - wir konzentrierten unsnicht nur auf Geschwindigkeit und Effizienz, sondern auch auf die Entwicklung eines skalierbaren, kosteneffizienten Produkts, das einen langfristigen Geschäftswert liefert.

Visualisierung des Flusses: Einrichten von Dashboards

Wie in Accelerate von Nicole Forsgren, Jez Humble und Gene Kim beschrieben, war es unser Ziel, ein Dashboard einzurichten, das die vier wichtigsten DevOps-Kennzahlen visualisieren und verfolgen kann:

• Bereitstellungshäufigkeit → Wie oft Teams Code in die Produktion einbringen.
• Vorlaufzeit für Änderungen → Wie schnell der Code von der Übergabe in die Produktion übergeht.
• Change Failure Rate → Der Prozentsatz der Einsätze, die zu Fehlern führen.
• Mittlere Wiederherstellungszeit (MTTR) → Wie schnell sich Teams von Fehlern erholen.

Allerdings war es anfangs eine Herausforderung, diese Metriken auf aussagekräftige Weise zu generieren, da es an einer systematischen Nachverfolgung der Arbeit zwischen den Teams mangelte. Hier hat die Einführung von Azure DevOps als einzige, gemeinsame Arbeitsverwaltungslösung für alle Teams einen entscheidenden Unterschied gemacht.

Wir begannen mit der Einrichtung von teamspezifischen Dashboards zur Überwachung:

• Alle zugewiesenen Arbeitsaufgaben pro Team.
• Die Arbeiten sind noch nicht abgeschlossen.
• Abgeschlossene Arbeiten.
• Defekte, kategorisiert nach Stadium und Priorität.

Erste Herausforderung: Inkonsistente Nutzung

Trotz klarer Richtlinien verwendeten die Teams Status und Fehlerkategorien unterschiedlich. Diese Inkonsistenz machte eine teamübergreifende Flussanalyse nahezu unmöglich.

Die erste Herausforderung, auf die wir stießen, war die inkonsistente Verwendung von Workitem-Status und Fehlerklassifizierungen, obwohl es klare Richtlinien gab. Die verschiedenen Teams verwendeten die Zustände unterschiedlich, was es schwierig machte, Probleme im Arbeitsfluss zwischen den Teams zu erkennen. Eine einheitliche Verfolgung der Arbeit war von entscheidender Bedeutung, um sicherzustellen, dass Dashboards nicht nur für einzelne Teams, sondern für die Optimierung des Arbeitsflusses im gesamten Unternehmen genutzt werden konnten.

Anschließend konzentrierten wir uns auf die Definition von Arbeitselementen, um sicherzustellen, dass sie den genauen Stand der Arbeit in der Wertschöpfungskette widerspiegeln und gleichzeitig allgemein genug sind, um von mehreren Teams verwendet zu werden. Die meisten Tools bieten Standard-Statuskategorien, die jedoch nicht immer ausreichend waren. Es war wichtig, Statuskategorien zu definieren, die mit unserer Teamstruktur, den Arbeitsabläufen und unseren bekannten Engpässen übereinstimmten.

Analyse von Arbeitsabläufen zur Identifizierung von Engpässen

Die ersten Dashboards dienten in erster Linie dazu, die laufenden Arbeiten zu visualisieren, um ein klares Bild davon zu erhalten, was in den einzelnen Teams vor sich ging. Dazu gehörten Feature Stories, User Stories, Defects und Testpläne. Diese boten eine Momentaufnahme der laufenden Arbeit, aber sie lieferten immer noch kein klares Bild des gesamten Arbeitsflusses und Wertes.

Die Sichtbarkeit der laufenden Arbeit war ein wichtiger erster Schritt, aber die nächste Herausforderung bestand darin, diese Sichtbarkeit mit flussbasierten Metriken zu verbinden, die aufzeigen konnten, wo die Arbeit stecken blieb und wo wir uns verbessern mussten.

Anhand des Status der Arbeitsaufgaben haben wir Metriken erstellt, die die Anzahl der Arbeitsaufgaben in jedem Status anzeigen. Ursprünglich hatten wir nur Informationen über die Anzahl der Arbeitsaufgaben in den verschiedenen Zuständen. Für fortgeschrittenere Analysen - wie z. B. die Verfolgung der Verweildauer von Arbeitsaufgaben in den einzelnen Zuständen - waren zusätzliche Werkzeuge erforderlich, die wir später einführten. In diesem Anfangsstadium begannen wir unsere Analyse jedoch nur mit den Zählungen.

Selbst mit diesen Basisdaten erwiesen sich die Dashboards als wertvoll, um die wichtigsten Engpässe zu ermitteln:

• Zu viele in Arbeit befindliche Aufgaben im Vergleich zur Anzahl der Aufgaben, die innerhalb eines bestimmten Zeitraums erledigt werden.
• Ein wachsender Rückstand an neuen Aufgaben, der weit über das hinausging, was wir realistischerweise innerhalb der nächsten 3 bis 6 Monate erledigen konnten.
• Teams mit dem größten Rückstand an unerledigten Aufgaben, was darauf hinweist, wo zusätzlicher Fokus und Unterstützung erforderlich sind.

Jede dieser Erkenntnisse erforderte eine andere Lösung, aber die Möglichkeit, den Arbeitsfluss zu visualisieren, war ein großer Durchbruch. Diese Verbesserung brachte den Tools-Aspekt unseres DevOps-Dreiecks weiter und gab den Anstoß für Fortschritte bei den anderen beiden Aspekten - Architektur und Menschen.

Verwendung von KPIs zur Förderung der kontinuierlichen Verbesserung

Während unserer DevOps-Umstellung kamen wir in mehreren Phasen auf das Thema KPIs zurück. Als sich unsere Tracking-Fähigkeiten verbesserten, konnten wir detailliertere Metriken erstellen, die us halfen:

• Messung der Fortschritte im Laufe der Zeit, um sicherzustellen, dass wir uns unserem Ziel, ein marktfähiges Softwareprodukt zu entwickeln, nähern.
• Ermittlung von Abhängigkeiten und Übergaben, die zu Verzögerungen im Arbeitsablauf führten.
• Aufzeigen von Bereichen, in denen Teams zusätzliche Unterstützung oder Prozessverbesserungen benötigen.
• Wir richten unsere KPIs enger an den vier DevOps-Kennzahlen von Accelerate aus, um eine objektive Messung unseres Erfolgs zu ermöglichen.

Indem wir Tools, Architektur und Mitarbeiter mit den richtigen KPIs in Einklang brachten, schufen wir ein System, das einen klaren Einblick in unsere Fortschritte ermöglichte, us half,Engpässe zu erkennen und zu beseitigen, und sicherstellte, dass wir uns weiterhin auf die Bereitstellung eines langfristigen Geschäftswerts konzentrierten.

Was kommt als Nächstes? Verzweigung und kontinuierliche Bereitstellung

Mit unseren KPIs und Dashboards sind wir nun in der Lage, den Codefluss durch die Umgebungen und in die Produktion zu optimieren. In Kapitel 5 werden wir uns damit befassen, wie wir Branching und Continuous Deployment angegangen sind und welche kulturellen und technischen Veränderungen us eine schnellere und sicherere Bereitstellung ermöglicht haben.

Bleiben Sie dran!