Software Engineering Metrics
1.0

1.0 Einführung zu Teil 1: Grundlagen der Messung

Bevor dieses Buch auch nur eine einzige Metrik benennt, muss es eine schwierigere Frage beantworten: Wozu dient Messung überhaupt? Jedes Team, das jemals ein Dashboard gebaut hat, hat irgendwann auch erlebt, wie sich eine Zahl verbesserte, während sich das, was sie eigentlich abbilden sollte, verschlechterte. Das ist kein Tooling-Fehler. Es ist das vorhersehbare Ergebnis davon, die Grundlagen zu überspringen, die dieser Teil behandelt: warum überhaupt gemessen wird, was mit einer Metrik geschieht, sobald Menschen wissen, dass sie beobachtet wird, wie Ergebnisse stärker gewichtet werden als Aktivität, wem eine Zahl und ihre Definition gehören, woher die Daten tatsächlich stammen, und wie ein verrauschtes Signal gelesen wird, ohne sich selbst zu täuschen.

Für große Teams hören diese Grundlagen auf, optional zu sein. Ein einzelnes Team kommt vielleicht mit einer Ad-hoc-Zahl davon, auf die eine Führungskraft einmal pro Woche blickt. Eine Organisation mit Hunderten von Ingenieurinnen und Ingenieuren, Dutzenden Dashboards und einer Führungsebene, die nach oben berichtet, kann das nicht. Auf dieser Ebene führt eine Metrik ohne Eigentümer oder mit schlechter Definition nicht nur ein Team in die Irre, sondern jeden nachgelagerten Beteiligten, der der Zahl vertraut, ohne zu prüfen, wie sie zustande kam, und es ist teuer, das rückgängig zu machen, sobald sich das Verhalten bereits darauf eingestellt hat, sie zu manipulieren.

Unternehmen und Behörden spüren das am stärksten, weil ihre Metriken oft Konsequenzen weit über das produzierende Team hinaus tragen: Budgetentscheidungen, öffentliche Leistungsberichte, Prüfungsfeststellungen und Lieferantenverträge. Eine Metrik, die wie eine interne technische Annehmlichkeit wirkt, kann still und leise zu einer kritischen, unhinterfragten Eingabe für Entscheidungen werden, die von Menschen getroffen werden, die die Pipeline, die sie erzeugt hat, nie zu Gesicht bekommen. Die Grundlagen richtig zu legen, ist das, was dieses Gewicht tragbar macht.

Themen in diesem Teil

  • 1.1 Warum Softwareentwicklung überhaupt messen: Die Begründung fürs Messen an sich, wozu es dienen soll, und der Unterschied zwischen Messen zum Lernen und Messen zum Urteilen.
  • 1.2 Goodharts Gesetz und die Psychologie der Metriken: Die eine Idee, die jedes andere Thema dieses Buches bestimmt: Eine Metrik, die zum Ziel wird, hört auf, eine gute Metrik zu sein, sowie die psychologischen Mechanismen, die Manipulation nahezu unvermeidlich machen, sobald Menschen wissen, dass sie beobachtet werden.
  • 1.3 Ergebnisse vor Output: die Wahl, was gemessen wird: Wie ein Metrik-Set stärker auf Ergebnisse als auf Aktivität ausgerichtet wird, anhand der klassischen Unterscheidung von Input, Output und Ergebnis sowie des Nordstern-Musters.
  • 1.4 Metrik-Governance und Eigentümerschaft: Wer entscheidet, was gemessen wird, wem eine Definition gehört, und wie ein Metrik-Charter ein wachsendes Dashboard davor bewahrt, zu einem unkontrollierbaren Wildwuchs zu werden.
  • 1.5 Datenquellen und Instrumentierung: Woher Engineering-Metriken tatsächlich stammen, Instrumentierung im Vergleich zu Selbstauskunft, und die Datenqualitätsprobleme, die ein Dashboard still entwerten, bevor es jemand bemerkt.
  • 1.6 Statistische Kompetenz für Engineering-Metriken: Das Mindestmaß an statistischem Urteilsvermögen, das ein Team braucht, um eine Metrik ehrlich zu lesen: Perzentile im Vergleich zu Durchschnittswerten, Stichprobengröße, Regression zur Mitte und Störvariablen.

Wie diese Themen zusammenhängen

Diese sechs Themen bauen in einer strikten Reihenfolge aufeinander auf. Thema 1.1 fragt, warum überhaupt gemessen werden soll, was wichtig ist, weil ein Team, das diese Frage nicht beantwortet hat, Zahlen sammeln wird, nach denen niemand handelt. Thema 1.2 ist der Dreh- und Angelpunkt, um den sich der Rest des Buches dreht: Sobald akzeptiert ist, dass jede Metrik zum Ziel werden und manipuliert werden kann, folgen alle späteren Empfehlungen dieses Buches daraus, gegen genau dieses Risiko zu gestalten. Thema 1.3 macht aus dieser Vorsicht eine positive Regel: auf Ergebnisse zu gewichten, weil sie die Kategorie sind, die sich am schwersten billig manipulieren lässt. Thema 1.4 macht die Governance konkret, Thema 1.5 macht die Daten konkret, und Thema 1.6 vermittelt das statistische Urteilsvermögen, um sich auch dann nicht von Rauschen täuschen zu lassen, wenn Governance und Instrumentierung bereits solide sind.

Alles Nachfolgende hängt von diesem Teil ab. Die Flow-Metriken und DORA-Metriken aus Teil 2 sowie das SPACE-Framework in Teil 3 sind im Grunde durchgerechnete Beispiele für die Prinzipien der Ergebnisgewichtung und der Leitplanken-Paarung, die in den Themen 1.2 und 1.3 dargelegt werden. Die Anleitung zur Dashboard-Gestaltung in Thema 8.1 setzt das Governance-Modell aus Thema 1.4 voraus. Und das Reifegradmodell, das jedes Thema dieses Buches abschließt, ist unter seinen fünf Stufen ein Reifegradmodell für genau die Disziplin, die dieser Teil einführt: so zu messen, als meine man es ernst, und die eigene Arbeit zu überprüfen.