Qualität messen

Softwaremetriken sind gezielte Messgrößen, die Entscheidungen in der Softwareentwicklung von Meinungen auf Datenbasis stellen. Sinnvolle Metriken passen zum jeweiligen Kontext, zeigen Tendenzen statt absoluter Zahlen und sind für die Person zugänglich, die sie braucht. Qualität, Produktivität und Performance hängen dabei eng zusammen und lassen sich durch Trends früh erkennen.

Das Wichtigste in Kürze

• Wer Metriken erhebt, sie aber nicht für Entscheidungen nutzt, kann sich die Arbeit sparen: Daten ohne Konsequenz sind verschwendete Kapazität.
• Softwarequalität und Entwicklungsgeschwindigkeit hängen direkt zusammen: Schlechtere Codequalität verlängert Bearbeitungszeiten, weil Änderungen aufwendiger werden.
• Durchlaufzeiten sind keine festen Zahlen, sondern Zufallsvariablen: Sie lassen sich als Histogramm darstellen und für kurzfristige Prognosen mit Monte-Carlo-Simulationen nutzen.
• Teamvergleiche über Produktivitätsmetriken erzeugen internen Wettbewerb, der Teams schwächt statt stärkt, weil unterschiedliche Kontexte keine fairen Vergleiche zulassen.
• Metriken lassen sich in konzentrischen Kreisen denken: Einige sind nur für die einzelne Person sinnvoll, andere fürs Team, wieder andere fürs Management, je nachdem wer welchen Kontext kennt.

Metriken sind kein Selbstzweck, sondern Entscheidungshilfe

Metriken sollen helfen, im Tagesgeschäft schneller und besser zu entscheiden. Das ist ihr eigentlicher Zweck, nicht das Befüllen eines Dashboards. In vielen Unternehmen wird über Vorgehen und Prioritäten vor allem auf Basis von Meinungen diskutiert. Mit zunehmender Komplexität der Softwareentwicklung reicht das nicht mehr aus.

Maik Wojcieszak bringt es mit einem Satz von W. Edwards Deming auf den Punkt: Wer keine Daten hat, ist nur eine weitere Person mit einer Meinung. Genau hier setzen Metriken an. Sie machen aus einer Behauptung eine überprüfbare Aussage.

Wenn du keine Daten hast, bist du nur eine weitere Person mit einer Meinung. Maik Wojcieszak

Der Knackpunkt liegt nicht in der Verfügbarkeit der Daten. Tools erfassen heute jede Menge Zahlen und zeigen sie auch an. Schwach bleibt die Nutzung. Daten landen in Dashboards, die niemand für konkrete Entscheidungen heranzieht.

Warum überladene Dashboards dumm machen

Zu viele Informationen wirken genauso schädlich wie zu wenige. Es gibt zwei Wege, einen Menschen handlungsunfähig zu halten: Man gibt ihm zu wenig Information oder man überschüttet ihn mit zu viel. Wachsende, immer buntere Dashboards fallen in die zweite Kategorie.

Die Aufgabe besteht darin, genau die Informationen herauszufiltern, die für die jeweilige Arbeit der jeweiligen Person relevant sind. Alles andere ist Rauschen. Eine Informationsflut überfordert, statt zu klären.

Wie eine gute Metrik aussehen sollte, zeigt ein Vergleich aus dem Alltag. Ein Pilot, der seine Instrumentendaten in einem Excel-Sheet ablesen müsste, hätte keinen schnellen Zugang. Der Geschwindigkeitsmesser im Auto dagegen fällt nicht mehr auf, wird aber permanent genutzt, ohne darüber nachzudenken. So intuitiv sollten Metriken im Arbeitsalltag funktionieren.

Es gibt kein universelles Standard-Set

Welche Metriken sinnvoll sind, hängt vom konkreten Fall ab, nicht von einer allgemeingültigen Liste. Ein kleines Projekt braucht weniger Metriken als ein großes. Ein einzelnes Team braucht weniger als eine Organisation mit vielen Teams. Eine Kennzahl, die für einen Anwendungsfall trägt, kann für einen anderen wertlos sein.

Maik nennt dafür ein klares Beispiel. Die DORA-Metriken aus dem Buch “Accelerate” von Jez Humble, Gene Kim und Nicole Forsgren sind im DevOps-Umfeld beliebt. Wer aber gar kein DevOps betreibt, etwa bei der Entwicklung mobiler Anwendungen, gewinnt mit der Deployment-Rate nichts. Die Metrik passt schlicht nicht zum Kontext.

Daraus folgt eine einfache Regel: Erst den Anwendungsfall verstehen, dann die passenden Metriken auswählen. Nicht umgekehrt.

Qualität messen: Zuverlässigkeit, Wiederherstellung, Änderungsgeschwindigkeit

Softwarequalität besteht aus vielen Aspekten, und mehrere davon lassen sich direkt messen. Die Zuverlässigkeit einer Software lässt sich über Fehlerraten erfassen. Auch die mittlere Wiederherstellungszeit liefert verwertbare Hinweise und Tendenzen.

Einen Aspekt unterschätzen viele Teams: die Zeit, die eine Änderung in der Software braucht. Das meiste, was als innere Qualität gilt, also Clean Code und saubere Architektur, zielt genau darauf ab, Änderungen schneller durchführen zu können.

Idealerweise beginnt die Messung schon bei der Anforderung. Anforderungen haben enormen Einfluss darauf, wie viele Runden ein Team drehen muss, bis aus einer Vorgabe das wird, was der Kunde wirklich braucht.

Qualitätsdaten gehören in die IDE, nicht ins Reporting

Qualitätsmetriken entfalten ihren Wert erst, wenn Entwicklerinnen und Entwickler sie direkt beim Schreiben des Codes sehen. Statische Codeanalyse und Linter-Ergebnisse sollten sofort in der IDE auftauchen und zu einer unmittelbaren Verhaltensänderung führen.

Der Grund ist simpel. Wer schlechte Qualität gar nicht erst einbaut, spart sich die teure Reparatur später. Baut man sie ein, wird es schrittweise schlimmer, bis am Ende eine Situation steht, die viel Geld und viel Zeit kostet.

Die Praxis sieht oft anders aus. Tools liefern Berge von Mängeln, die niemand anschaut, weil es zu viel ist und die Zeit fehlt. Das ist das Gegenteil intuitiver Nutzung. Der Hebel: Punkte finden, an denen es offensichtlich besser laufen könnte, und von dort aus mit konkreten Daten ins Gespräch gehen. So werden Metriken zum Kommunikationsmittel, das auch Entscheidungen von Vorgesetzten auf eine belastbare Grundlage stellt.

Performance über Trends statt über Einzelwerte

Performance-Metriken zeigen ihren Nutzen, wenn man sie über die Zeit von Build zu Build betrachtet. Klassische Performance-Tests laufen direkt in der Pipeline. Trägt man die Ergebnisse über mehrere Builds auf, erkennt man Tendenzen und kann sofort reagieren, wenn die Performance schlechter wird. Auch eine Optimierung lässt sich so auf ihren tatsächlichen Effekt prüfen.

Tendenzen sind oft aussagekräftiger als absolute Zahlen. Eine einzelne Zahl kann in Einzelfällen springen und gar keinen echten Trend abbilden. Die Richtung des Pfeils, also besser oder schlechter, liefert die handlungsrelevante Information.

Warum Team-Vergleiche in die Irre führen

Absolute Metriken zum Vergleich von Teams sind selten sinnvoll und schwer sauber zu erheben. Misst man Produktivität etwa daran, wie lange ein Team für eine bestimmte Anzahl Anforderungen braucht, sagt eine niedrigere Zahl nichts über Geschwindigkeit oder Qualität aus. Der Kontext kann ein völlig anderer sein.

Solche Vergleiche erzeugen internen Wettbewerb, und der schadet. Maik vergleicht das mit Krabbenkörben. Bei einer einzelnen Krabbe können die Fischer den Deckel offen lassen, sie würde herauskrabbeln. Sind zwei drin, zieht die eine die andere immer wieder herunter. Viel Bewegung, kein Fortschritt.

Durchlaufzeit ist eine Zufallsvariable, kein Termin

Die Durchlaufzeit lässt sich einfach messen: von Beginn einer Anforderung bis zu ihrer Fertigstellung. Wer sie nutzt, muss aber zwei Fehler vermeiden.

Erstens darf Softwareentwicklung nicht als lineares System betrachtet werden. Wer das tut, liegt von Anfang an falsch.

Zweitens lässt sich die Fertigstellung einer Anforderung vorher nicht vorhersagen, nur im Nachhinein bestimmen. Damit hat die Durchlaufzeit den Charakter einer Zufallsvariable. Eine Zufallsvariable bildet man nicht als absolute Zahl ab, sondern als Histogramm.

Sobald man das tut, wird mehrere Dinge sichtbar. Es entsteht eine schiefe Verteilung, weil manche Aufgaben unerwartet lange brauchen. Langfristige Vorhersagen sind dadurch schwer bis unmöglich. Für kurzfristige Prognosen dagegen taugt die Metrik hervorragend, etwa in Verbindung mit einer Monte-Carlo-Simulation.

Wichtig dabei: Mikromanagement bringt nichts. Niemand muss Minuten aufschreiben. Die Durchlaufzeit liefert die nötige Aussage, ohne in Kleinteiligkeit zu kippen.

Drei Dinge, die ein Metrik-Vorhaben braucht

Wer Metriken bewusst angeht, sollte zuerst den Zweck klären: Welches Ziel verfolgst du damit? Erst danach kommen die drei Bausteine.

Performance und Qualität hängen eng zusammen. Wird die Qualität schlechter, steigt die Bearbeitungszeit. Aus der einen Metrik lassen sich also Rückschlüsse auf die andere ziehen. Performance hängt allerdings von vielen weiteren Faktoren ab, weshalb man mehrere Metriken zusammen betrachten muss, um die Zusammenhänge zu erkennen.

Der häufigste Denkfehler steckt in der Anwendung. Wer Metriken erhebt, aber seine Entscheidungen nicht davon beeinflussen lässt, kann sich die Mühe sparen. Mit einem klaren Ziel wird die Auswahl der richtigen Metriken deutlich einfacher.

Fang bei dir selbst an

Der beste Einstieg in Metriken ist die eigene Arbeit, nicht das große Team-Programm. Du musst kein Vorhaben für die ganze Organisation aufsetzen, um zu profitieren. Als Entwicklerin, Tester oder in welcher Rolle auch immer kannst du Metriken zuerst für dich nutzen und automatisieren.

Maik beschreibt das als konzentrische Kreise mit der Person in der Mitte. Manche Metriken sind nur für dich selbst. Damit kannst du dich verorten, niemand sonst muss sie sehen. Dann folgen Team-Metriken, die dem Team helfen, sich einzuordnen, ohne dass das Management sie braucht oder den Kontext kennen müsste. Auf dieser guten Basis lassen sich weitere Metriken ableiten, die das Management für seine Entscheidungen nutzt.

Metriken zeigen vor allem eines gut: wo du gerade stehst. Im Mittelfeld, an der oberen oder an der unteren Grenze. Diese Selbstverortung ist Motivation genug, um besser zu werden. Nicht im Wettbewerb gegen andere, sondern für die eigene Arbeit.