Die Nadel im (Daten-) Heuhaufen finden: 12 nützliche Metriken

Es wird viel von Datenanalyse, Datamining, Business Intelligence und ähnlichen Ansätzen gesprochen, um sich systematisch zu verbessern. Das klingt erst mal plausibel: Was man nicht messen kann, kann man nicht lenken.

Doch in der Praxis ist das gar nicht so einfach. Und in der Praxis begegne ich einer erstaunlich hohen Anzahl von Organisationen, die kein klares Verständnis davon haben, wie effizient dort überhaupt gearbeitet wird. Denn wenn es darum geht, bei der Bewertung konkret zu werden, ist es gar nicht so leicht, quantifizierbare und gleichzeitig relevante Metriken zu finden.

Im folgenden beschreibe ich eine Vorgehensweise, und stelle auch zwölf Metriken vor, die in der Praxis weiterhelfen.

Haben wir Rohdaten?

Ein guter Anfangspunkt ist eine Inventur an relevanten Daten. Die können in unterschiedlichsten Formen vorliegen, zum Beispiel:

• Ein Datenbankbasiertes Entwicklungssystem, wie Source Code Repository (git), ALM-Werkzeug (Jira), RE-Werkzeug (Jama), Modellierungswerkzeug (Cameo), usw. Diese haben in der Regel eigene Reportingfunktionen. Außerdem lassen sich oft Daten direkt über eine API oder Dastenbankabfrage abrufen, oder man kann spezialisierte Werkzeuge andocken.
• Test- Validierungs- und Defektdaten sind attraktiv, da diese in der Regel eine direkte Aussage über die Qualität machen, die es zu verbessern gilt.
• Kundendaten, wie Supporttickets, Telemetriedaten oder auch die Resonanz von Marketingkampagnen.
• Metriken der Gruppen- und Abteilungsleiter. Diese liegen oft nur in der Form von Spreadsheets vor und werden dann wöchentlich per E-Mail verschickt. Doch diese kann man natürlich auch auswerten.
• Umfragen sind ebenfalls aussagekräftig, auch wenn diese eher qualitative Ergebnisse liefern.

Bei den Daten fehlt oft die Zeitkomponente: Wir wollen uns ja schließlich verbessern. Aus den meisten der aufgeführten Datenquellen ist es sehr mühsam (und Zeitaufwendig), zeitbasierte Informationen abzuleiten. Daher sollte am besten sofort begonnen werden, die Rohdaten systematisch zeitbasiert aufzuzeichnen. Dazu gibt es spezialisierte BI-Systeme, wie zum Beispiel Jama Analyze.

Nur, wenn wir die Daten in regelmäßigen Intervallen sammeln, können wir Trends erkennen.

Was wollen wir messen?

Selbst wenn wir solide, zeitbasierte Daten haben – welche Metriken könnte man daraus ableiten? Hier ist eine kleine Auswahl zur Inspiration, aus verschiedenen Bereichen. Viele der Metriken können unterschiedlich fein gemessen werden.

Effizienzmetriken

• Wie viel Zeit verbringen wir in Reviews? Zum Beispiel die in Meetings verbrachte Zeit, der Aufwand pro hundert Elemente, etc.
• Effizienz, Defekte zu entfernen – Zum Beispiel die Anzahl der in der Entwicklung gefundenen Defekte geteilt durch Defekte in der Entwicklung plus im Betrieb gefundener Defekte.
• Durchsatz – Zum Beispiel bei Sprints, aber auch bei anderen in regelmäßigen Zyklen durchgeführte Aktivitäten.

Qualitätsmetriken

• Testabdeckung – Diese Metrik gibt es im Code (% Zeilen getestet), Anforderungen (% Anforderungen getestet), und vielen anderen Bereichen. Dabei sollte aufgepasst werden, dass eine 100%ige Abdeckung oft nicht sinnvoll ist.
• Defektrate – Ganz banal: Wie viele offene Defekte gibt es? Wie lange bleiben Defekte normalerweise offen?
• Eskalierungsrate – zum Beispiel bei Supporttickets.

Warnmetriken

Diese Metriken können als Indikatoren genutzt werden um zu erkennen, ob die Entwicklung aus dem Ruder läuft.

• Vertrauen in die Entwicklung – Dies wird oft über „Ampeln“ berichtet, doch dies sollte auch über die Zeit aufgetragen werden um rechtzeitig einzugreifen
• Testabdeckung – Die oben beschriebene Testabdeckung kann uns auch als Trend zeigen, ob wir rechtzeitig die gewünschte Testabdeckung erreichen werden.
• Volatilität – Dies ist eine anspruchsvolle Metrik, die uns zeigt, wie stark sich etwas verändert Also zum Beispiel die Anzahl der hinzugefügten, gelöschten und geänderten Anforderungen pro Zeitintervall. Am Projektbeginn wird eine hohe Volatilität erwartet, gegen Ende des Projekts kann dies auf ernsthafte Probleme hinweisen, zum Beispiel die Notwendigkeit, die Architektur zu ändern.

Zufriedenheitsmetriken

Uns interessiert sowohl Kunden- als auch Entwicklerzufriedenheit.

• Kommunikation im Team – Dies lässt sich gut mit Umfragen erheben: Funktioniert Kommunikation? Haben wir zu viele Meetings? Nutzen wir unsere Werkzeuge richtig?
• Kundenzufriedenheit – Diese wird oft schon direkt gemessen, besonders bei Software. Wenn dies nicht gemacht wird, dann ist es höchste Zeit.
• Erfolg beim Onboarding – Dies ist auch für Software leichter zu finden: Wie viele Kunden nutzen das Produkt nach x Wochen noch?

Achtung – Nicht bestrafen!

Damit das ganze funktioniert, ist es wichtig die Metriken nicht zur Bestrafung oder zum „Finger pointing“ heranzuziehen! Auch Anreizsysteme sollten kritisch betrachtet werden. Denn dann werden die Metriken garantiert gefälscht. Statt dessen sollten diese genutzt werden, um gezielt Maßnahmen auszuwählen und dann deren Effektivität zu messen: Wenn die Testabdeckung nicht schnell genug ansteigt, dann muss der Tester vielleicht von anderen Aktivitäten freigestellt werden, oder ein weiterer ins Team gebracht werden.

Ebenso ist es ganz wichtig, mit dem Team offen über die Metriken zu sprechen und für Transparenz zu sorgen, ansonsten kann es schnell zu Verunsicherungen kommen. Das tut dem Team auch nicht gut.

Doch wenn Daten richtig eingesetzt und gut kommuniziert werden, dann wird das Team dankbar für einen funktionierenden Feedbackmechanismus sein.

Photo by Niklas Hamann on Unsplash