Wenn die DevOps-Messung in die Irre führt Wie man KPIs im agilen Kontext richtig liest

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Eine DevOps-Transformation ist die Summe kleinerer Projekte – deren Fortschritt mit KPIs, sprich Key-Performance-Indikatoren oder Leistungskennzahlen, gemessen werden sollte. Doch manchmal führen die Messungen zu vorschnellen oder falschen Reaktionen. Warum?

Die Messung des Projekterfolgs ist ein dynamischer Prozess, bei dem immer wieder andere Kennzahlen in den Vordergrund rücken. Dabei darf ein Key Performance Indicator nicht alleine betrachtet werden – er zeigt nur einen kleinen Teil der Wahrheit. Es gilt, die Abhängigkeiten der KPIs zu erfassen.

Keinem ist damit geholfen, in blinden Aktionismus zu verfallen, wenn eine Kennzahl aus dem Ruder läuft. Alle KPIs sollten mit Vorsicht gesetzt und gelesen werden: so wird etwa die Häufigkeit der Deployments variieren, denn manche Aufgaben sind komplexer und relevanter als andere und dauern entsprechend länger.

Teils muss auch eine höhere Anforderung an Security und Compliance beachtet werden, was die Lead Time nochmals ändert. Nicht zuletzt deshalb sollte man sich die Freiheit geben, die Vorgaben auch der Realität anzupassen und auch die Methoden immer wieder anpassen und nachjustieren.

Das Problem mit der Geschwindigkeit

Bei der Deployment Frequency, also der Geschwindigkeit, mit der Updates, neue Funktionen und Software-Verbesserungen mit größerer Effizienz und Genauigkeit erstellt werden, gilt: je schneller, desto agiler – und desto einfacher wird es, auf Wünsche der Anwender einzugehen.

Viele Unternehmen machen den Fehler, dieselbe Frequenz für alle Projekte zu erwarten, doch tatsächlich variiert die Komplexität der Tasks dafür zu sehr. Ein plötzlicher Rückgang in dieser Leistungskennzahl kann ein Zeichen dafür sein, dass der Arbeitsablauf unausgewogen ist oder durch andere Projekte oder Personalprobleme belastet wird.

Die Reaktion auf den Rückgang kann ebenfalls fatal sein: Was passiert beispielsweise, wenn ein Projektmanager sieht, dass seine Delivery zu langsam ist und vom Team hört, dass die Testautomatisierung sehr viel Zeit kostet?

Stellt er dann die Tests zurück, kann das schnell auf Kosten von Sicherheit und Qualität gehen. Schnellere Deployment Time und damit auch eine höhere Deployment Frequency sollten nicht auf Kosten der Genauigkeit gehen – Schnelligkeit lohnt nicht, wenn sie mit hohen Fehlerraten einhergeht.

Das Interpretationsrisiko besteht auch bei anderen KPIs, die Geschwindigkeit messen: ist die Lead Time zu lang, kann das heißen, dass das Team nicht anpassungsfähig und produktiv genug ist. Es kann aber auch heißen, dass die Aufgaben nicht klar verteilt wurden oder andere Projekte Vorrang hatten.

Eine Messung der Deployment Frequency oder der Deployment Time kann zudem irreführend sein, wenn Sie nicht auch den Umfang der Änderungen zwischen den Deployments (Change Volume) messen. Ein ständiger Strom minimaler Änderungen bringt viele Unterbrechungen und lenkt von größeren, wirkungsvolleren Changes ab.

Der richtige Umgang mit Fehlern

Gerade ein KPI wie Deployment Frequency sollte nicht ohne einen Blick auf die Fehlerrate gesehen werden. Fehler gibt es immer, aber wenn die Change Failure Rate stark ansteigt, kann das auch bei häufigen Deployments unter dem Strich zu einem Verlust an Einnahmen und Kundenzufriedenheit führen.

Tiefer lässt die Defect Escape Rate blicken, denn sie zeigt die Anzahl der Fehler, die während der Produktion und während bzw. nach dem Deployment gefunden werden. Diese Hinweise auf Probleme im Test Data Management oder im Entwicklungs-Prozess ermöglichen es, die Qualitätsprüfungen wasserdichter zu machen.

Auch wenn diese Fehler schnell behoben werden können (das zeigt die Mean Time to Recovery), ist noch immer eine Frage offen: hat das Team in jeder Iteration – Kanban, Scrum, Cyles usw. – funktionierende Software an real existierende Anwender ausgerollt und Informationen bzw. Feedback wieder eingesammelt?

Selbst die Leistungskennzahl Customer Ticket Volume zeigt nicht die wirkliche Kundenzufriedenheit: Hier wird nur gemessen, wie viele Probleme Anwender in der Praxis haben. Gibt es also einen Prozess, der das Feedback der Anwender tatsächlich in Arbeit ummünzt und das in weniger als einem Monat? Werden daraus Tickets, Issues und Tasks für Entwicklerteams generiert?

Nicht vereinfachen!

Die Vielzahl und Abhängigkeiten der wichtigen KPIs kann verwirren. Es ist aber nicht unbedingt eine Lösung, die Messgrößen in Charts zu sehr zu vereinfachen. Ein Beispiel: Das Burndown Chart soll zeigen, ob das Team auf dem richtigen Weg ist, seine Ziele zu erreichen. Nur: Das Chart geht davon aus, dass die Arbeit auf vorhersehbare und reibungslose Weise durchgeführt werden kann – und das ist falsch.

Projekte bleiben manchmal nicht in der Zeit. Dennoch könnte es als Frühwarnsystem für das Team dienen, wenn etwas aus dem Ruder zu laufen droht und man Gegenmaßnahmen ergreifen muss. Wird die Darstellung aber vom Management verwendet, um einem Team mitten im Sprint eine Ursachenforschung aufzuzwingen, so ist das kontraproduktiv.

Was dann passiert ist klassisch: ein Unternehmen wirft mehr Ressourcen in das Projekt, um das Problem zu lösen. Leider ist das kontraproduktiv. Der Einsatz neuer Mitarbeiter in einem Projekt führt oft zu einem Produktivitätseinbruch. Der Review der geleisteten Arbeit, die Einarbeitungszeit der Neuen und das Vermitteln von Wissen wird das bereits verspätete Team weiter verlangsamen.

Zudem bringen zusätzliche Ressourcen versteckte Kosten mit sich: Internes Personal wird die eigene Arbeit liegen lassen, die Struktur des vergrößerten Teams wird instabil, was eine kontinuierliche Verbesserung erschwert, wenn nicht gar unmöglich macht. Und externes Personal ist schwer zu finden, teuer und muss sich ebenfalls einarbeiten. Projektleiter sind gut beraten, über andere Optionen nachzudenken: Kann man den Rahmen weiter setzen oder die Frist verschieben? Oder das Projekt abspecken und auf ein sinnvolles Inkrement reduzieren?

Überblick dank Dashboard

Dennoch benötigt man einen kontinuierlichen Blick auf die KPIs, um die Projekte zu bewerten. Alle relevanten Tools zahlen auf KPIs ein: Tools zum Projektfortschritt, Issue Tracking, Versionskontrolle, CI/CD-Automatisierung, Codeanalyse und Testing.

Ein Dashbord hilft, den Überblick zu behalten: Damit kann ein Projektverantwortlicher den Grad der Automatisierung und den Stand der DevOps-Transformation sowie die Prozessreife überwachen. Projekt-Dashboards kompilieren Zahlen und aktualisieren sie laufend. Die Informationen werden in zentralisierten Ansichten gesammelt, von denen jede einen neuen Blickwinkel auf den Softwareentwicklungssprint oder das Release bietet – wie z.B. Projektmanagement, Entwicklung oder Qualitätssicherung.

Momentaufnahmen stellen den aktuellen Status dar, während die Trendansichten eine Zeitlinie mit historischer Perspektive bieten. Geradezu essenziell sind die Alert-Funktionen als Voraussetzung, frühzeitig nachbessern zu können.

Das alles baut darauf, dass die richtigen Zahlen vorliegen. Sind die metrischen Daten nicht verfügbar, wird es kritisch: Entweder nutzen die Teams die Tools nicht richtig oder, noch schlimmer, sie setzen die empfohlenen Methoden überhaupt nicht ein. Um also zuverlässige Informationen aus der Toolkette zu erhalten, ist Disziplin auf der Projektseite erforderlich.

• Der Fortschritt muss regelmäßig aktualisiert werden.

• Das Team muss die Tools gemäß den Best Practices verwenden - zum Beispiel sollten Commits zur Versionskontrolle und automatisierte Testfälle mit den entsprechenden Jira-Ticket-IDs gekennzeichnet werden.

• Die Automatisierung muss auch das Qualitäts-Tracking umfassen.

• Die Teams müssen CI/CD-integrierte Tools wie statische Code-Analyse und Schwachstellen-Scans von Open-Source-Komponenten verwenden.

Doch selbst wenn alles rund läuft – die Toolchain funktioniert und wird erwartungsgemäß genutzt, die KPIs liegen vor und das Dashboard bietet die richtigen Übersichten –, sollte man zwei Probleme immer im Hinterkopf behalten: KPIs und Metriken zeigen niemals die gesamte Wahrheit.

Manche Faktoren beim Agilen Projektmanagement sind einfach schwer zu messen – kulturelle und menschliche Aspekte beispielsweise. Und es bleibt auch immer eine Herausforderung, KPIs gegeneinander abzuwägen und die richtigen Ursachen für Entwicklungen herauszulesen. DevOps ist eben nicht nur ein Zahlenspiel, es ist eine riesige Transformation.

* Boris Schulz ist DevOps Lead bei Eficode. Den Prozessverbesserungsansatz lernte er vor vielen Jahren in einer Firma ohne Systemadministration kennen und lieben. Heute ist DevOps der Treiber einer ganzen Industrie und sein Wissen ist stark gefragt. Er hat für die unterschiedlichsten Firmen bereits Teams und Abteilungen mit DevOps, Ops, Entwicklern, DBAs, QA-Engineers und Interner IT geleitet und in einer ruhigen Minute ein NOC aufgebaut. Die daraus resultierende Erfahrung teilt er sehr gerne und es gibt wenige Themen. zu denen er nicht zumindest eine erhellende Geschichte beitragen kann.

(ID:46990321)