Metrik

Herausforderungen bei der Nutzung von Metriken

Organisationen stehen bei der Nutzung von Metriken vor einigen Herausforderung:

• Die Erhebung sollte so objektiv wie möglich vonstattengehen, d. h. subjektive Einflüsse des Messenden gilt es zu vermeiden.
• Die Feststellung einer Metrik sollte dahingehend zuverlässig sein, dass eine Wiederholung der Feststellung zu identischen Ergebnissen führt.
• Ohne Normierung bspw. in Form einer Messergebnisskala oder einer Vergleichsskala fällt die Bewertung von Erhebungen schwer.
• Der Aufwand zur Definition und Messung von Werten sollte möglichst gering sein. Darüber hinaus sollte der fortwährende Bedarf zur Bestimmung der Werte gewährleistet sein, denn nichts ist teurer, als Aufwand zu produzieren ohne Bedarf am Ergebnis.
• Die Validität ist in zweierlei Hinsicht zu beachten: Sind die erhobenen Daten in sich valide und lassen sich ggf. mit anderen Kenngrößen kombinieren? Oftmals lässt sich in der Unternehmenspraxis beobachten, dass ein Rückschluss von einer Metrik auf eine andere nicht wirklich funktioniert.
• Unternehmen sollten den Sinn hinter einer gewählten Kennzahl beachten. Die Velocity in agilen Entwicklungen ist bspw. ein Maß zur Planung von Sprints, sie unterstützt aber weder den Vergleich von Teams, noch ist sie ein Instrument zur Motivation oder Leistungssteigerung.

Und zu guter Letzt stehen Organisationen häufig vor der Herausforderung, aus der Vielzahl von Möglichkeiten, die Kennzahlen zu bestimmen, die wirklich in einem konkreten Kontext nützlich sind.

Agile Metriken

Es gibt eine Vielzahl von Metriken, die im Kontext agiler Vorhaben oder Entwicklungen genutzt werden. Nachfolgend finden Sie eine Auswahl:

• Die Backlog Health ist ein Maß für den allgemeinen Zustand und die Effizienz des Backlogs des Teams, einschließlich Faktoren wie Backlog-Größe, veraltete Elemente und Fortschritte bei der Fertigstellung.
• Die Cycle Time bestimmt die Zeit, die ein Team benötigt, um eine Aufgabe von Anfang bis Ende zu erledigen.
• Escaped Defects benennt die Anzahl der Fehler, die trotz der Bemühungen des Teams, sie zu vermeiden, in das Endprodukt gelangen.
• Die Fehlerdichte bezeichnet die Anzahl der Fehler pro Arbeitseinheit.
• Der Prozentsatz der Zeit, in der ein Team tatsächlich an der Wertschöpfung arbeitet, anstatt auf Ressourcen oder Genehmigungen zu warten, nennt sich Flow-Efficiency.
• Die Kundenzufriedenheit ist ein Maß dafür, wie zufrieden Kunden mit der Arbeit des Teams sind.
• Die Zeit, die von der Anforderung einer Aufgabe durch einen Kunden bis zur Lieferung der Aufgabe vergeht, wird als Lead Time bezeichnet.
• Die Mean Time To Repair (MTTR) ist die durchschnittliche Zeit, die für die Reparatur eines Fehlers benötigt wird.
• Der Prozentsatz der Nacharbeit bestimmt die Teile der Arbeit, die aufgrund von Mängeln oder anderen Problemen nachgearbeitet werden.
• Die Team-Moral ist ein allgemeines Maß für das Engagement und die Motivation des Teams, das durch Umfragen oder andere Formen des Feedbacks ermittelt wird.
• Die Zeit, die ein Team benötigt, um ein Produkt oder eine Funktion auf den Markt zu bringen, nennt sich Time to Market.
• Die Time to Value ist die Zeit, die ein Team benötigt, um dem Kunden einen greifbaren Wert zu liefern.
• Die Velocity benennt die Menge an Arbeit, die ein Scrum-Team innerhalb eines einzelnen Sprints erledigen kann, gemessen in Story Points oder anderen Arbeitseinheiten.
• Work in Progress (WIP) bezeichnet die Menge der Arbeit, die derzeit im System in Bearbeitung ist. Diese Kennzahl kann Teams helfen, Engpässe zu erkennen und Multitasking zu reduzieren, insbesondere in Kombination mit dem WIP Limit als maximale Anzahl von Aufgaben, an denen ein Team zu einem bestimmten Zeitpunkt arbeiten kann.

Sicherlich lässt sich diese Liste ergänzen. Der Scrum Guide, der das Framework mit seinen Spielregeln definiert, gibt keine agile Metrik vor; Organisationen können sich also entscheiden, welche Ansätze für ihre Arbeit am nützlichsten sind.

Softwaremetriken

Auch in der Softwareentwicklung gibt es zahlreiche Metriken. Nachfolgend finden Sie eine Auswahl:

• Codequalität misst den Grad der Effizienz, Zuverlässigkeit und Wartbarkeit des Codes.
• Reaktionszeit ist die Zeit, die ein System benötigt, um auf Benutzereingaben zu reagieren.
• Codeüberdeckung misst den Prozentsatz des Codes, der durch automatisierte Tests ausgeführt wird.¹
• Fehlerzahl ist die Anzahl der Fehler, die in einer Softwareanwendung während der Entwicklung oder des Testens gefunden wurden.
• Mean Time to Recovery misst wie lange es dauert, bis ein Systemfehler oder Systemausfall behoben ist.
• Code-Komplexität misst den Schwierigkeitsgrad beim Verstehen und Ändern von Code. Dies kann mit Metriken wie der zyklomatischen Komplexität oder der Anzahl der bedingten Anweisungen gemessen werden.
• Code-Duplizierung misst die Menge an Code-Duplikaten, die innerhalb einer Codebasis kopiert und eingefügt wurde. Duplizierter Code kann zu Inkonsistenzen führen und die Pflege des Codes erschweren.
• Code Smells sind Indikatoren für potenzielle Probleme im Code, die ein Refactoring erfordern können. Beispiele für Code Smells sind lange Methoden oder Klassen, inkonsistente Namenskonventionen oder übermäßige Kopplung zwischen Komponenten.
• Testabdeckung misst den Prozentsatz des Codes, der durch automatisierte Tests abgedeckt wird. Eine niedrige Testabdeckung kann die Identifizierung und Behebung von Fehlern erschweren und damit die Wahrscheinlichkeit von technischen Schulden erhöhen.
• Lines of Code (LOC) ist eine Metrik, die die Anzahl der Codezeilen in einem Softwareprogramm oder -system misst.²

Auch die Kombination einzelner Werte findet sich in der Softwareentwicklung. Der Wartbarkeitsindex ist bspw. eine zusammengesetzte Metrik, die Faktoren wie Code-Komplexität, Code-Duplizierung und Code-Größe berücksichtigt, um ein Gesamtmaß dafür zu liefern, wie einfach oder schwierig es sein wird, den Code im Laufe der Zeit zu warten. Ein höherer Wartbarkeitsindex zeigt an, dass der Code leichter zu warten ist und weniger wahrscheinlich technische Schulden anhäuft.

Metriken im Projektmanagement

Auch im Projektmanagement finden sich zahlreiche Metriken. Hier finden Sie eine Auswahl:

• Schedule Variance ist die Differenz zwischen dem geplanten Zeitplan und dem tatsächlichen Fortschritt, in der Regel gemessen in Zeit.
• Kostenabweichung ist die Differenz zwischen dem geplanten Budget und den tatsächlichen Ausgaben.
• Planned Value (PV) ist der Gesamtwert der Arbeit, die in einem bestimmten Zeitraum abgeschlossen werden soll.
• Earned Value (EV) ist der Gesamtwert der in einer bestimmten Periode tatsächlich abgeschlossenen Arbeiten.
• Cost Performance Index (CPI) ist ein Maß für die Kosteneffizienz, berechnet als Verhältnis zwischen dem verdienten Wert und den tatsächlichen Kosten.
• Schedule Performance Index (SPI) ist ein Maß für die Effizienz des Zeitplans, berechnet als Verhältnis zwischen Earned Value und Planned Value.
• Return on Investment (ROI) ist ein Maß für den Ertrag, den ein Projekt im Verhältnis zu den getätigten Investitionen erzielt.
• Net Present Value (NPV) ist ein Maß für den Gegenwartswert aller zukünftigen Mittelzuflüsse und Mittelabflüsse im Zusammenhang mit einem Projekt.
• Und die Change Request Rate ist ein Maß dafür, wie häufig während eines Projekts Änderungen beantragt werden, die sich auf den Projektumfang und den Zeitplan auswirken können.

In der Projektmanagement-Praxis kann es ebenfalls sinnvoll sein, verschiedene Metriken zu kombinieren. So kann z. B. die Kombination von Ressourcenauslastung und Ressourcenverfügbarkeit  dabei helfen, Bereiche zu identifizieren, in denen Ressourcen über- oder unterausgelastet sind, um folglich die Ressourcenzuweisung zu optimieren.

Fragen aus der Praxis

Hier finden Sie einige Fragen und Antworten aus der Praxis:

Impuls zum Diskutieren:

In welchen Zyklen sollten sich Organisationen fragen, ob die genutzten Metriken noch ihren Zweck erfüllen?

Hinweise:

Haben Sie Lust auf einen neuen Lieblings-Newsletter?

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

[1] Die Codeüberdeckung lässt sich mittels verschiedener Verfahren bestimmen: Statement Coverage, Branch Coverage, Path Coverage und Condition Coverage.

[2] Lines of Code (LOC) kann zwar einen gewissen Aufschluss über die Größe einer Codebasis geben, ist aber nicht unbedingt ein gutes Maß für die Komplexität, Qualität oder Produktivität von Software. Historisch gesehen wurde LOC aus verschiedenen Gründen als Metrik für die Softwareentwicklung verwendet:

• Da Softwareprogramme immer umfangreicher und komplexer wurden, bestand ein Bedarf an einer Möglichkeit, die Größe von Codebases auf konsistente und standardisierte Weise zu messen.
• LOC kann als grobe Schätzung des Entwicklungsaufwands und des Projektumfangs verwendet werden, insbesondere in den frühen Phasen eines Projekts, wenn detailliertere Metriken noch nicht verfügbar sind.
• LOC kann als Benchmark für Produktivitätsvergleiche zwischen verschiedenen Entwicklern oder Teams, die an ähnlichen Projekten arbeiten, verwendet werden.

Die Verwendung von LOC als Metrik für die Softwareentwicklung unterliegt jedoch einigen Einschränkungen. Zum Beispiel können verschiedene Programmiersprachen und -stile bei gleicher Funktionalität sehr unterschiedliche LOC-Werte ergeben. Darüber hinaus berücksichtigt LOC nicht die Qualität, Wartbarkeit oder Effizienz des Codes und kann Entwickler sogar dazu verleiten, mehr Code als nötig zu schreiben, um ein Ziel zu erreichen, was zu aufgeblähtem und schwieriger zu wartendem Code führt.

Hier finden Sie ein Video über Metriken für höhere Softwarequalität.

[3] Nicht nur im Unternehmenskontext spielt die Metrik eine wichtige Rolle. Auch in der Literatur, der Musik, in der Chemie, der Physik und der Mathematik wird der Begriff aktiv genutzt.

Hier finden Sie ergänzende Informationen aus dem t2informatik Blog:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.