Wichtiges im Blick behalten: KPIs und Dashboards

In unserem vorherigen Kapitel, Designing for Testability: Breaking the Next Barrier, haben wir untersucht, wie die Testbarkeit nach der Beseitigung anfänglicher Engpässe bei der Teamorganisation und dem manuellen Testen zu einem zentralen Schwerpunkt wurde. Dieses Kapitel markierte einen Wendepunkt in unserer DevOps-Transformation, da wir unseren Fokus auf tiefgreifendere Software-Designprinzipien verlagerten, die reibungslosere und schnellere Tests ermöglichten.

Im nun folgenden Kapitel 4 treten wir in die nächste wichtige Phase ein: die Definition und Verfolgung der richtigen KPIs sowie die Einrichtung von Dashboards zur Messung unserer Fortschritte. Da grundlegende Vorgehensweisen etabliert waren und sich die Testbarkeit verbesserte, benötigten wir objektive, datengestützte Methoden, um den Arbeitsfluss zu visualisieren, Hindernisse zu erkennen und uns kontinuierlich zu verbessern.

Warum KPIs und Dashboards im Bereich DevOps wichtig sind

Auf unserem Weg zu einer effizienteren End-to-End-Bereitstellung haben wir erkannt, dass wir einen visuellen und objektiven Mechanismus benötigen, um die Arbeit nachzuverfolgen und Engpässe aufzudecken. Das bedeutete, KPIs zu definieren, die sich nicht nur auf nackte Zahlen stützen, sondern aussagekräftige Erkenntnisse liefern und die richtigen Verhaltensweisen fördern.

Bei der Einrichtung von KPIs ist unbedingt zu beachten, dass Teams und Organisationen dazu neigen, diejenigen Messwerte zu optimieren, die sie überwachen. Dies steht im Einklang mit dem Goodhartschen Gesetz, das besagt:

„Wenn ein Messwert zu einem Ziel wird, hört er auf, ein guter Messwert zu sein.“

Dieses Prinzip unterstreicht, wie wichtig es ist, KPIs auszuwählen, die Teams zu den richtigen Ergebnissen führen, anstatt sie einfach dazu zu motivieren, Vorgaben zu erfüllen. Der Zweck dieser KPIs besteht darin, den Fortschritt auf dem Weg zu unserem übergeordneten Ziel zu messen. Doch wie lautet dieses Ziel genau?

Definition des Ziels

Wie in Das Ziel von Eliyahu M. Goldratt erörtert, besteht das Ziel eines Unternehmens darin, den Nettogewinn zu steigern und gleichzeitig den ROI und den Cashflow zu verbessern. Wenn wir dies auf unseren Softwareentwicklungskontext übertragen, in dem wir uns derzeit in der Investitionsphase befinden, haben wir das Ziel wie folgt definiert:

 „Entwicklung und Bereitstellung eines vermarktbaren Softwareprodukts, das nachhaltige Umsätze generiert.“

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

• Time-to-Market → 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 dass die Leistung beeinträchtigt wird.
• Kostenoptimierung → Ausgleich der Entwicklungskosten bei gleichzeitiger Maximierung des Wertbeitrags.
• Return on Investment (ROI) → Sicherstellen, dass das Produkt langfristige finanzielle Vorteile bringt, die die Investition rechtfertigen.

Diese Bedingungen waren maßgeblich dafür, wie wir unsere KPIs definiert haben – wobei der Schwerpunkt nicht nur auf Geschwindigkeit und Effizienz lag, sondern auch auf der Entwicklung eines skalierbaren, kostengünstigen Produkts, das langfristigen Geschäftswert schafft.

Visualisierung des Arbeitsflusses: Einrichtung von Dashboards

Wie im Buch 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:

• Deployment-Häufigkeit → Wie oft Teams Code in der Produktion bereitstellen.
• Durchlaufzeit für Änderungen → Wie schnell Code vom Commit bis zur Produktion gelangt.
• Fehlerrate bei Änderungen → Der Prozentsatz der Deployments, die Fehler verursachen.
• Mittlere Wiederherstellungszeit (MTTR) → Wie schnell sich Teams von Fehlern erholen.

Die aussagekräftige Erstellung dieser Kennzahlen erwies sich jedoch zunächst als schwierig, da die Arbeit teamübergreifend nicht systematisch erfasst wurde. Hier brachte die Einführung von Azure DevOps als einheitliche, gemeinsame Lösung für das Arbeitsmanagement aller Teams eine entscheidende Wende.

Wir haben damit begonnen, teamspezifische Dashboards einzurichten, um Folgendes zu verfolgen:

• Alle zugewiesenen Arbeitselemente pro Team.
• Arbeiten, die sich derzeit in Bearbeitung befinden.
• Abgeschlossene Arbeiten.
• Nach Status und Priorität kategorisierte Fehler.

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 uneinheitliche Verwendung von Arbeitselement-Status und Fehlerklassifizierungen, obwohl klare Richtlinien vorlagen. Da verschiedene Teams die Status unterschiedlich nutzten, war es schwierig, Fluss- und Ablaufprobleme teamübergreifend zu erkennen. Es wurde von entscheidender Bedeutung, einheitliche Maßstäbe für die Nachverfolgung der Arbeit zu etablieren, um sicherzustellen, dass Dashboards nicht nur für einzelne Teams, sondern zur Optimierung des Arbeitsflusses im gesamten Unternehmen eingesetzt werden konnten.

Wir konzentrierten uns darauf, Arbeitselemente so zu definieren, dass sie genau widerspiegeln, wo sich die Arbeit in der Wertschöpfungskette befindet, und gleichzeitig allgemein genug bleiben, um von mehreren Teams genutzt werden zu können. Die meisten Tools bieten Standard-Statuskategorien, die jedoch nicht immer ausreichten. Es war wichtig, Statuskategorien zu definieren, die zu unserer Teamstruktur, unserem Arbeitsfluss und unseren bekannten Engpässen passten.

Analyse des Workflows zur Identifizierung von Engpässen

Die ersten Dashboards wurden hauptsächlich eingerichtet, um die laufenden Arbeiten zu visualisieren – um ein klares Bild davon zu erhalten, was in den Teams geschah. Dazu gehörten Feature-Stories, User Stories, Fehler und Testpläne. Diese boten eine Momentaufnahme der laufenden Arbeit, vermittelten jedoch noch kein klares Bild des gesamten Arbeits- und Wertflusses.

Die Sichtbarkeit der laufenden Arbeiten war ein wichtiger erster Schritt, aber die nächste Herausforderung bestand darin, diese Sichtbarkeit mit flussbasierten Kennzahlen zu verknüpfen, die aufzeigen, wo Arbeit stecken blieb und wo Verbesserungen erforderlich waren.

Anhand des Status der Arbeitselemente haben wir Kennzahlen erstellt, die die Anzahl der Arbeitselemente in den jeweiligen Phasen anzeigen. Anfangs verfügten wir nur über Informationen zur Anzahl der Arbeitselemente in den verschiedenen Status. Eine fortgeschrittenere Analyse – wie beispielsweise die Verfolgung, wie lange Arbeitselemente in den jeweiligen Status verblieben – erforderte zusätzliche Tools, die wir später einführten. In dieser Anfangsphase begannen wir unsere Analyse jedoch ausschließlich mit den Mengenzahlen.

Selbst mit diesen grundlegenden Daten erwiesen sich die Dashboards als wertvoll, um wichtige Engpässe zu identifizieren:

• Zu viele laufende Arbeitselemente im Vergleich zur Anzahl der in einem bestimmten Zeitraum fertiggestellten Elemente.
• Ein wachsender Rückstau an neuen Arbeitselementen, der das realistischerweise in den nächsten 3 bis 6 Monaten Machbare bei Weitem überstieg.
• Teams mit dem größten Rückstau an unvollständigen Arbeitselementen, was darauf hindeutet, wo zusätzlicher Fokus und Unterstützung erforderlich waren.

Jede dieser Erkenntnisse erforderte eine andere Lösung, aber die Möglichkeit, den Arbeitsfluss zu visualisieren, war ein wichtiger Durchbruch. Diese Verbesserung brachte den Tool-Aspekt unseres DevOps-Dreiecks voran und lieferte den Anstoß für Fortschritte in den anderen beiden Bereichen – Architektur und Mitarbeiter.

Einsatz von KPIs zur Förderung kontinuierlicher Verbesserungen

Wir sind im Laufe unserer DevOps-Transformation in mehreren Phasen auf das Thema KPIs zurückgekommen. Da sich unsere Tracking-Möglichkeiten verbesserten, konnten wir detailliertere Kennzahlen generieren, die uns dabei halfen:

• Messen Sie den Fortschritt im Zeitverlauf, um sicherzustellen, dass wir unserem Ziel der Entwicklung eines marktfähigen Softwareprodukts näherkommen.
• Identifizieren Sie Abhängigkeiten und Übergaben, die zu Verzögerungen im Arbeitsfluss führten.
• Ermitteln Sie Bereiche, in denen Teams zusätzliche Unterstützung oder Prozessverbesserungen benötigten.
• Richten Sie unsere KPIs stärker an den vier wichtigsten DevOps-Metriken aus Accelerate aus, um ein objektives Maß für unseren Erfolg zu erhalten.

Durch die Abstimmung von Tools, Architektur und Mitarbeitern auf die richtigen KPIs haben wir ein System geschaffen, das klare Einblicke in unsere Fortschritte bot, uns dabei half, Engpässe zu erkennen und zu beseitigen, und sicherstellte, dass wir uns weiterhin auf die Bereitstellung von langfristigem Geschäftswert konzentrierten.

Wie geht es weiter? Branching und kontinuierliche Bereitstellung

Mit unseren KPIs und Dashboards sind wir nun bereit, den Fluss des Codes durch die Umgebungen und in die Produktion zu optimieren. In Kapitel 5 befassen wir uns eingehend damit, wie wir Branching und Continuous Deployment angegangen sind und welche kulturellen und technischen Veränderungen es uns ermöglicht haben, schneller und sicherer zu deployen.

Seien Sie gespannt!