Agile Metriken als strategisches Element für den Projekterfolg

Noch immer herrscht die weitläufige Meinung, dass absolute Zahlen bezogen auf die Produktqualität (z.B. Anzahl der Fehler) oder Sprint-Qualität (z.B. Anzahl erfolgreich geschlossener Stories) ausreichen um effektiv und effizient das Testing steuern zu können. Die zweite Informationsebene zum operativen Test Management ist die Priorisierung der Fehler. Meistens in Stufen von eins bis vier, oder in Kategorien von A bis D. An dieser Stellte sei angemerkt, dass hier nicht die Kategorisierung des Risk-based Testing (RBT) gemeint ist. RBT wird in der Testvorbereitung zur Priorisierung der Testausführung eingesetzt. In der Ergebnisbetrachtung, nach Testausführung, wird RBT herangezogen, um das Restrisiko anhand der verbliebenen Testfälle und offenen Fehler zu bestimmen. Ich möchte nicht verheimlichen, dass ich ein grosser Fan von RBT bin.

Besser als bei jeder Status-Ampel kann man zu jedem Zeitpunkt berechnen, wie hoch das Restrisiko wäre, wenn man in diesem Augenblick das Testing abbrechen würde. Das halte ich für sehr transparent und ermöglicht Ressourcen zielgerichteter einzusetzen. Auf RBT werde ich noch wesentlich ausführlicher in einem weiteren Beitrag eingehen. Hier soll es um Metriken im agilen Umfeld gehen. Ich plädiere für ein Vorgehen, dass ähnlich der rückwärts gewandten Planung entspricht. Was ist das Ziel und wie kommen wir dort hin? Damit wird verhindert, dass ein für agile Teams zu entwerfender Metrik-Katalog zu einer akademischen Übung wird.

Aus Sicht der IT ist der GQM-Ansatz (Goal – Question – Metrik) schon sehr alt. Dennoch stellt dieser Ansatz immer noch das effektivste und effizienteste Vorgehen dar, um nicht nur Lebenszyklen von Produkten, sondern auch die damit verbundenen Entwicklungs-, Support- und Management-Prozesse messbar zu machen. Mit dem GQM-Ansatz hat man einen Blueprint, um in transparenter Weise sinnvolle und vor allem zielführende Metriken zu etablieren die Sprint-übergreifend Verbesserungen ermöglichen. Erst mit dieser Toolbox ist man am Ende eines Sprints, der in etwa einem PDCA-Zyklus entspricht, in der Lage eine objektive und vor allem einheitliche Bestandsaufnahme bezüglich der Produkt- und Prozessqualität durchzuführen. Mit der Messung des aktuell abgeschlossenen Sprints und der historischen Betrachtung sämtlicher zuvor durchgeführten Sprints lässt sich das verbleibende Verbesserungspotential in Form von Kennlinien eruieren. Die Anwesenheit von Metriken würde salopp gesagt den Ansatz “Von der Hand in den Mund leben” implizieren. Ich plädiere für ein Metrik-System, dass über einen Release, einen Sprint oder sogar über den Lebenszyklus eines Produkts hinaus geht, und die Vision einer kontinuierlichen Verbesserung unterstützt.

image-20210510-072731

Eine Vision, wie in etwa “Wir wollen Qualität teilen” könnte zum Beispiel in Ziele resultieren, die mit jeder Produktivsetzung eines Inkrement die Fehlerrate um 15% gesenkt wird. Ein weiteres Ziel könnte sein, dass das Produkt bis zum Going-Public von 100% aller Mitarbeiter innerhalb des Unternehmens eingesetzt wird. Als Beispiel aus der Vergangenheit sei hier Microsoft Word angeführt. Alle Microsoft-Mitarbeiter haben Word vor Verkaufsstart eingesetzt. Die Qualität wurde im wahrsten Sinnes des Wortes geteilt (“Eat your own dog food”). Positives wie negatives Feedback wurde dementsprechend schnell an das Produkt-Team zurück gegeben. Vielleicht war man damals nicht nur deshalb schon viel näher am agilen Vorgehen dran, sondern auch deshalb weil die Teams mehr oder weniger autarke Einheiten waren bei denen auch der Projektleiter programmiert hat. Unter Berücksichtigung des hier im Artikel beschriebenen Inhalts, bekommt man einen sehr strukturierten Verbesserungsansatz dessen Lücken noch durch geeignete Metriken gefüllt werden müssen.

Ich betrachte jede verwendete Metrik und jede Messung auch aus strategischer Sicht und nicht nur um das aktuelle Problem zu lösen. Dabei geht es zum Beispiel nicht nur um das Verhältnis zwischen geplanten und erfolgreich durchgeführten Sprints, sondern auch um eine Kategorisierung und Häufigkeit der Probleme offener Stories am Ende der Sprints. Es geht nicht nur um Sprint Burndown Charts, sondern auch um eine Pareto-Betrachtung der aktuellen Arbeitssituation. Wie hoch ist der Anteil an Blockern und welcher Art sind diese? Es geht auch um das Verhältnis zwischen den realisierten Features und den damit verbundenen Testing-Aufwänden. Wie oft müssen damit verbundene Defects wiederholt behoben werden bis der Kunden zufrieden ist? Die Liste der möglichen Metriken ist abzählbar unendlich, wie der Mathematiker sagen würde. Die Liste der sinnvollen Metriken ist abzählbar und bedient nur und ausschliesslich die zuvor definierten Ziele. Die ausgewählten Metriken sollten Team- und Produkt-übergreifend und auf jeden Fall strategischer Natur sein.

Kontakt

Harald Schmidt

Harald Schmidt

Mobil: +41 (0) 79 88 55 1 44
E-Mail: harald.schmidt@spf-consulting.ch