Wichtiges im Blick behalten: KPIs und Dashboards

In unserem vorherigen Kapitel, Design für Testbarkeit: Die nächste Hürde überwinden, haben wir untersucht, wie Testbarkeit zu einem Schwerpunkt wurde, nachdem anfängliche Engpässe bei der Teamzusammenstellung und dem manuellen Testen behoben waren. Dieses Kapitel markierte einen Wendepunkt in unserer DevOps-Transformation, da wir unsere Aufmerksamkeit auf tiefere Software-Designprinzipien verlagerten, die ein reibungsloseres, schnelleres Testen ermöglichten.

Nun in Kapitel 4 gehen wir in eine entscheidende nächste Phase über: die richtigen KPIs zu definieren und zu verfolgen sowie Dashboards einzurichten, um unseren Fortschritt zu messen. Mit etablierten grundlegenden Praktiken und verbesserter Testbarkeit benötigten wir objektive, datengestützte Wege, um den Arbeitsfluss zu visualisieren, Engpässe zu identifizieren und kontinuierlich zu verbessern.

Warum KPIs und Dashboards in DevOps wichtig sind

Auf unserem Weg zur Optimierung der End-to-End-Lieferung erkannten wir die Notwendigkeit eines visuellen und objektiven Mechanismus, um die Arbeit zu verfolgen und Engpässe aufzudecken. Dies bedeutete, KPIs zu definieren, bei denen es nicht nur um Zahlen ging, sondern darum, umsetzbare Erkenntnisse hervorzuheben und die richtigen Verhaltensweisen zu fördern.

Beim Einrichten von KPIs ist es wichtig zu erkennen, dass Teams und Organisationen dazu neigen, die Kennzahlen zu optimieren, die sie überwachen. Dies steht im Einklang mit dem Goodhartschen Gesetz, das besagt:

„Wenn eine Kennzahl zu einem Ziel wird, ist sie keine gute Kennzahl mehr.“

Dieses Prinzip unterstreicht die Bedeutung, KPIs so auszuwählen, dass sie Teams zu den richtigen Ergebnissen führen, anstatt sie lediglich dazu zu ermutigen, Ziele zu erreichen. Der Zweck dieser KPIs ist es, den Fortschritt auf unser übergeordnetes Ziel hin zu messen. Doch was genau ist dieses Ziel?

Zieldefinition

Wie in The Goal von Eliyahu M. Goldratt erörtert, ist es das Ziel eines Unternehmens, den Nettogewinn zu steigern und gleichzeitig den ROI sowie den Cashflow zu verbessern. Übertragen auf unseren Softwareentwicklungskontext, in dem wir uns derzeit in der Investitionsphase befinden, haben wir das Ziel wie folgt definiert:

 „Ein marktfähiges Softwareprodukt entwickeln und liefern, das nachhaltige Einnahmen generiert.“

Um dieses Ziel zu erreichen, müssen mehrere notwendige Bedingungen erfüllt werden, darunter:

• Time to Market → Schnelle Bereitstellung von Funktionen und Produkten, um Marktchancen zu nutzen.
• Zukünftige Skalierbarkeit → Sicherstellen, dass die Software so konzipiert ist, dass sie mit der Nachfrage wächst, ohne die Leistung zu beeinträchtigen.
• Kostenoptimierung → Entwicklungskosten ausgleichen und gleichzeitig die Wertschöpfung maximieren.
• Return on Investment (ROI) → Sicherstellen, dass das Produkt langfristige finanzielle Vorteile liefert, die die Investition rechtfertigen.

Diese Bedingungen leiteten uns bei der Definition unserer KPIs – der Fokus lag nicht nur auf Geschwindigkeit und Effizienz, sondern auch auf dem Aufbau eines skalierbaren, kosteneffizienten Produkts, das langfristigen Geschäftswert liefert.

Visualisierung des Ablaufs: Dashboards einrichten

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

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

Diese Metriken jedoch auf sinnvolle Weise zu generieren, war anfangs eine Herausforderung, da es an einer systematischen Nachverfolgung der Arbeit über die Teams hinweg mangelte. Die Einführung von Azure DevOps als einzige, gemeinsame Lösung für das Arbeitsmanagement für alle Teams machte hier einen entscheidenden Unterschied.

Wir begannen damit, teamspezifische Dashboards einzurichten, um Folgendes zu verfolgen:

• Alle zugewiesenen Arbeitselemente pro Team.
• Aktuell in Bearbeitung befindliche Arbeit.
• Abgeschlossene Arbeit.
• Fehler, kategorisiert nach Phase und Priorität.

Erste Herausforderung: Uneinheitliche Nutzung

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

Die erste Herausforderung, der wir begegneten, war die inkonsistente Verwendung von Arbeitsaufgabenstatus und Fehlerklassifikationen, obwohl klare Richtlinien vorhanden waren. Verschiedene Teams verwendeten Status unterschiedlich, was es schwierig machte, Probleme im Arbeitsfluss über die Teams hinweg zu identifizieren. Es wurde entscheidend, Konsistenz in die Nachverfolgung der Arbeit zu bringen, um sicherzustellen, dass Dashboards nicht nur für einzelne Teams, sondern auch zur Optimierung des Arbeitsflusses in der gesamten Organisation genutzt werden konnten.

Wir konzentrierten uns dann darauf, Arbeitsaufgaben richtig zu definieren, um sicherzustellen, dass sie genau widerspiegeln konnten, wo sich die Arbeit in der Wertschöpfungskette befindet, während sie gleichzeitig generisch genug waren, um von mehreren Teams verwendet zu werden. Die meisten Tools bieten Standard-Statuskategorien, diese waren jedoch nicht immer ausreichend. Es war wichtig, Statuskategorien zu definieren, die mit unserer Teamstruktur, dem Arbeitsfluss und unseren bekannten Engpässen übereinstimmten.

Arbeitsabläufe analysieren, um Engpässe zu identifizieren

Die ersten Dashboards wurden hauptsächlich eingerichtet, um den Fortschritt der Arbeit sichtbar zu machen und ein klares Bild davon zu erhalten, was in den Teams geschah. Dies umfasste Feature-Stories, User Stories, Fehler und Testpläne. Sie boten zwar eine Momentaufnahme der laufenden Arbeit, lieferten aber noch kein klares Bild des gesamten Arbeits- und Wertflusses.

Die Sichtbarkeit der laufenden Arbeit war ein wichtiger erster Schritt, aber die nächste Herausforderung bestand darin, diese Sichtbarkeit mit flussbasierten Kennzahlen zu verknüpfen, die aufzeigen konnten, wo die Arbeit stockte und wo wir uns verbessern mussten.

Anhand des Status der Arbeitselemente erstellten wir Kennzahlen, die die Anzahl der Arbeitselemente in jedem Zustand zeigten. Zunächst hatten wir nur Informationen über die Anzahl der Arbeitselemente in verschiedenen Zuständen. Eine fortgeschrittenere Analyse – wie die Verfolgung, wie lange Arbeitselemente in jedem Zustand verblieben – erforderte zusätzliche Tools, die wir später einführten. In dieser Anfangsphase begannen wir unsere Analyse jedoch nur mit den Zählungen.

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

• Zu viele Arbeitselemente in Bearbeitung im Vergleich zur Anzahl der Elemente, die innerhalb eines bestimmten Zeitraums abgeschlossen wurden.
• Ein wachsender Rückstand an neuen Arbeitselementen, der weit über das hinausging, was wir realistisch innerhalb der nächsten 3 bis 6 Monate abschließen konnten.
• Teams mit dem größten Rückstand an unfertigen Arbeitselementen, was aufzeigte, wo zusätzliche Aufmerksamkeit und Unterstützung erforderlich waren.

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

KPIs nutzen, um kontinuierliche Verbesserung voranzutreiben

Wir sind in verschiedenen Phasen unserer DevOps-Transformation auf das Thema KPIs zurückgekommen. Mit der Verbesserung unserer Tracking-Fähigkeiten konnten wir detailliertere Kennzahlen generieren, die uns dabei halfen:

• Fortschritt im Zeitverlauf messen, um sicherzustellen, dass wir unserem Ziel näherkamen, ein marktfähiges Softwareprodukt zu entwickeln.
• Abhängigkeiten und Übergaben identifizieren, die den Arbeitsfluss verzögerten.
• Bereiche identifizieren, in denen Teams zusätzliche Unterstützung oder Prozessverbesserungen benötigten.
• Unsere KPIs enger an den vier wichtigsten DevOps-Kennzahlen aus Accelerate ausrichten, um ein objektives Maß für unseren Erfolg zu liefern.

Indem wir Tools, Architektur und Menschen mit den richtigen KPIs in Einklang brachten, schufen wir ein System, das klare Einblicke in unseren Fortschritt ermöglichte, uns half, Engpässe zu identifizieren und zu beseitigen, und sicherstellte, dass wir uns auf die Bereitstellung von langfristigem Geschäftswert konzentrierten.

Was kommt als Nächstes? Branching und Continuous Deployment

Mit unseren etablierten KPIs und Dashboards sind wir nun bereit, den Codefluss durch 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 es uns ermöglichten, schneller und sicherer bereitzustellen.

Bleiben Sie auf dem Laufenden!