Share ZU:
13 December 2016 @ Sascha Schamberg

Zeig doch mal die Metrik!

Kennen Sie auch folgendes Szenario: Sie sitzen in einem Projektmeeting und der erste Punkt der Agenda steht an: Die aktuellen Metriken. Noch bevor inhaltliche Themen der Entwicklung besprochen werden, wird der aktuelle Status der Metriken als wichtigstes Mittel zur Messung des Projektfortschrittes herangezogen.

Soweit so gut, Metriken als Einstiegspunkt (!) zu verwenden, scheint ein logischer Schritt zu sein. Doch an dieser Stelle endet oft die Logik. Anstatt die nackten Zahlen einer Metrik als Startpunkt für Diskussionen und den Austausch zu nutzen, nimmt der Projektverantwortliche Anstoß am nicht sichtbaren Fortschritt bzw. den immer noch offenen Punkten. Wenn dann der Betroffene sich zu seinen Themen äußern will, wird seine Aussage im Keim erstickt: „Für Diskussionen haben wir hier keine Zeit. Nächste Woche sieht die Metrik bitte besser aus!“. Solche oder ähnliche Szenarien werden die meisten von uns schon erlebt haben. Wie kann man so eine Situation vermeiden?

Eine Möglichkeit besteht darin, die ganze Situation bereits im Vorfeld, bei der Erstellung der Metrik, zu entschärfen. Im Regelfall fordert der Projektverantwortliche zum Projektstart oder ab bestimmten Meilensteinen die Erstellung einer / mehrerer Metrik(en) beim Anforderungsmanager ein. Hier kann (und muss) der Grundstein für einen „vernünftigen“ Umgang mit Metriken gelegt werden.

Zunächst einmal muss geklärt werden, was überhaupt das Ziel der Metrik sein soll. Dazu bieten sich beispielsweise die folgenden Methoden an:

In jedem Fall muss eine Absprache zwischen Projektverantwortlichem und Anforderungsmanager stattfinden, bei welcher die Eckpunkte der neuen Metrik(en) abgestimmt werden.

Die für mich wichtigste Frage in diesem Zusammenhang lautet:

„Welchen Mehrwert liefert die neu zu erstellende Metrik für das gesamte Projekt?“

Diese Frage ist die Grundlage jeder Diskussion über neu zu erstellende Metriken. Es muss sichergestellt werden, dass nicht nur die Sicht des Projektverantwortlichen, sondern auch die Sicht derer, deren Arbeit in den Metriken auftaucht (bspw. Entwickler oder Tester), bei der Erstellung einer Metrik berücksichtigt werden.

Sind Inhalt und Darstellung der zu erstellenden Metrik geklärt, muss noch der korrekte Umgang mit der Metrik besprochen werden. Der Projektverantwortliche muss darauf hingewiesen werden, dass die Metrik zwar die aktuellen Zahlen (bspw. wie viele Anforderungen sich derzeit im Status „Fertig“ befinden), nicht jedoch die im Projekt durchgeführten Arbeiten zeigt. Wichtiger als die nackten Zahlen der Metrik sind die Informationen, die hinter diesen Zahlen stecken. Diese Informationen kann man nur im Austausch mit den Bearbeitern der Anforderungen erlangen. Weiterhin müssen diese Informationen auch immer bei der Vorstellung der Metriken im Projektmeeting eine Rolle spielen. Dieser Schritt scheint banal, wird aber häufig vernachlässigt.

Ein (fiktives) Beispiel:

Im Projektmeeting zeigt die wöchentlich vorgestellte Metrik, dass in den letzten vier Wochen von Entwickler A nur wenige seiner 150 „In Arbeit“ stehenden Anforderungen auf „Fertig“ gesetzt wurden. Der Projektverantwortliche ist außer sich vor Wut, hat er doch Entwickler A darauf hingewiesen, dass die Anforderungen „asap“ in den Status „Fertig“ gestellt werden sollen, denn erst dann dürfen diese den Testern zum Review bereitgestellt werden. Dieses Review soll in weiteren vier Wochen durchgeführt werden, um den wertvollen Input der Tester in die Anforderungen einfließen zu lassen. Der Projektverantwortliche sieht seine bisherige Terminplanung in Gefahr, da nach seiner Planung die Anforderungen vor zwei Wochen „Fertig“ hätten sein sollen.

Was die Metrik an dieser Stelle nicht zeigt, Entwickler A hat die letzten 4 Wochen fast jeden Tag mit Tester B zusammengesessen und die 150 Anforderungen durchgesprochen, um das Feedback von Tester B direkt in die Anforderungen einzuarbeiten. Am folgenden Tag findet der letzte Termin statt, und alle 150 Anforderungen können in den Status „Fertig“ gesetzt werden. Das Review der Tester und der damit verbundene Zeitaufwand wurde also minimiert, da Entwickler und Tester direkt miteinander gearbeitet haben. Diese wichtige Information muss der Projektverantwortliche aber auch bekommen, die Metrik an sich zeigt dies nicht. Die Kommunikation dieser Informationen kann direkt durch den Entwickler im Projektmeeting geschehen, oder der Anforderungsmanager liefert diese, da er im direkten Austausch mit dem Entwickler steht. Im Idealfall wird nicht mehr über die Zahlen der Metriken, sondern über die Arbeit der Entwickler gesprochen.

Bloß die Kennzahlen einer Metrik zu präsentieren, reicht nicht aus, um den Status des Projektfortschritts und die damit verbundene Arbeit aufzuzeigen! In meinem aktuellen Projekt vertritt mein Team genau diesen Standpunkt. Wir stellen in Projektmeetings nicht nur die Metrik vor, sondern sprechen mit unseren Ansprechpartnern, um die Informationen hinter der Metrik zu erfahren und weitergeben zu können.

Ich hoffe, Sie sehen zukünftig in einer Metrik mehr als die bloßen, dargestellten Zahlen!

Sascha Schamberg

Kontaktieren Sie Sascha Schamberg

Sascha Schamberg arbeitet bei der HOOD GmbH als Consultant im Bereich Requirements Engineering. Seine Tätigkeitsschwerpunkte liegen in der Unterstützung unserer Kunden beim Einsatz von Requirements Engineering und zugehöriger Werkzeuge (z.B. DOORS). Zu seinen Aufgaben zählen die Erhebung, Verbesserung und Dokumentation von funktionalen und nicht-funktionalen Anforderungen, sowie die Erstellung von objektorientierten Modellen. Seine Wissensschwerpunkte liegen im Bereich Software Engineering und Requirements Engineering. Er ist mit zahlreichen Vorgehensmodellen zur Softwareentwicklung und diversen Modellierungssprachen (z.B. UML) vertraut.