Die Welt steht Kopf? Exzellenz in IT-Metriken
Ganz gleich, wie ein Software-Entwicklungsprojekt in Auftrag gegeben wurde (nach Festpreis, auf Zeitbasis, etc.) oder mit welcher Methodik es durchgeführt wird (Agile, Wasserfall, Prince2, etc…): Am Ende entsteht ein Softwareprodukt. Dieses Produkt, ungeachtet des Vertrags und der Methodik, hat einen bestimmten Preis, eine Größe, verschiedene Qualitätsindikatoren und eine Reihe von Faktoren, die zeigen sollen, ob beispielsweise die Kosten im Verhältnis zum Endprodukt stehen.
Es ist äußert wichtig, zu unterscheiden, ob es sich um ein Produkt- oder Projektkonzept handelt. Rufen wir uns ins Gedächtnis, dass das Ziel eines Projekts die Erschaffung eines neuen Produkts (Dienstes oder die Erreichung eines bestimmten Ergebnisses) ist. Der Unterschied zwischen den Konzepten ist eigentlich einleuchtend, doch – wenn man die Metriken-Brille trägt – werden die Dinge plötzlich komplizierter: Ein und dieselbe Messgröße kann ganz unterschiedlich verstanden werden. Die Größe eines Projekts kann z.B. als Projektdauer oder Projektaufwand gesehen werden. Die Qualität eines Projekts kann dadurch gemessen werden, wie gut oder schlecht es gehandhabt wurde und ob eine Reihe von vordefinierten oder notwendigen Indikatoren erfüllt wurden. Bei der Größe oder Qualität eines Softwareprodukts (das innerhalb eines Projekts entstanden ist) greifen wiederum ganz andere Konzepte, die nichts mit der Projektperspektive zu tun haben.
Projekte, Produkte und IT-Metriken
Wir können duzende Metriken zu Projekten sammeln, aber Projektmetriken ohne Produktmetriken liefern manchmal isolierte Indikatoren, denen die wichtigsten strategischen Informationen fehlen. Man kann festlegen, dass die Projektschätzung mit den eigentlichen Zahlen übereinstimmt. Ähnlich lässt sich feststellen, dass der Projektplan eingehalten wurde und es besser gelaufen ist, als geplant. Und es gibt viele weitere, äußerst nützliche Metriken, die uns darüber aufklären, ob ein Projekt nach den vordefinierten Regeln und Indikatoren läuft. Leider – und hier kommt der Haken – können diese Metriken aber auch nicht viel mehr.
Wenn wir nämlich eine Reihe von eigentlich eindeutigen Fragen hinzufügen, kann das Ergebnis ein ganz anderes sein: Stimmt die Projektaufwandsschätzung mit dem tatsächlichen Aufwand überein? Stimmt die erwartete und vereinbarte Qualität mit dem Ergebnis überein? Und sind die verschiedenen KPIs einheitlich und liefern verlässliche Ergebnisse und Rückschlüsse?
Die Sache ist: Wir müssen über Projektaspekte hinausdenken, eine umfassendere Sicht entwickeln und Faktoren einbeziehen, die für die tägliche, ganz praktische Arbeit Sinn ergeben und wertvoll sind: Beginnend bei Low-Level Projekt Metriken bis hin zu strategischen CIO-Level Ergebnissen, einschließlich unternehmensweiter Prognosen (intern) und Markteinschätzungen (extern). In dem all diese Aspekte berücksichtigt werden, offenbart sich die Möglichkeit, die durch Metriken gewonnenen Erkenntnisse zu verbessern und die Ergebnisse und Schlussfolgerungen zu stärken. Das gilt in jedem Fall, ganz gleich, ob es sich um Projekte, Produkte, Finanzaspekte oder Wettbewerbsindikatoren sowie zukünftige strategische Erwartungen handelt.
Es gibt eine ungeheure Zahl an unterschiedlichen Indikatoren und KPIs, die anwendbar sind, doch am Ende des Tages sind es immer die gleichen Hauptfragen, die beantwortet werden müssen. Haben wir, abgesehen von der Sammlung und Erhebung dutzender wichtiger Metriken, auch realistische Metriken zur Produktivität, Qualität, zu Produktkosten, der Reaktionsfähigkeit und Markteinführungszeit? Können die Ergebnisse und deren Ursachen mit früheren Projekten in einem anderen Technologiesektor verglichen werden, die vielleicht mit anderen Entwicklungstools, einer anderen Methodik oder unter anderen vertraglichen Umständen umgesetzt wurden? Lässt sich sagen, warum manche Projekte besser laufen als andere? Können wir standardisierte, anerkannte Methoden anwenden, um Schlüsse zwischen unserer Firma und anderen Unternehmen zu ziehen? Geht das auf einem nationalen Level, branchenübergreifend oder sogar weltweit?
Um hierauf Antworten zu finden, müsste man sich verschiedene Aspekte anschauen, beginnend mit der Frage ob die vorhandenen Informationen realistisch sind. Werden die Zahlen richtig erhoben? Manchmal reicht die Tatsache, dass Teams oder einzelne Mitarbeiter gelobt (oder gescholten) werden sollen oder auch die Erstellung von Rankings oder die interne Bekanntgabe verschiedener Zahlen, dass es zum Zahlenlotto kommt. Das ist ein bisschen wie beim Fotoshooting: Sie machen ein Foto und wenn das Bild an den Augen oder Haaren nicht aussieht, wie gewünscht, wird es retuschiert. Doch wenn die Zahlen – aus welchen Gründen auch immer – nicht stimmen, sind auch alle abgeleiteten Metriken und Schlussfolgerunden falsch und ergeben keinen Sinn. Sie münden dann zwar in netten Dashboards und ansprechenden Präsentationen, sind aber fernab jeglicher Realität.
Inkorrekte gemeinsame Nenner oder wenn die Welt Kopf steht
Es ist erstaunlich, dass sich die gemessenen Werte in der Softwareindustrie nicht immer auf die Produktgröße beziehen. Oftmals wird die Produktgröße fälschlicherweise mit Produktkosten oder Entwicklungsressourcen in Verbindung gestellt. Doch zwischen Projekt und Produkt besteht nicht zwingend eine Verbindung: Ein Projekt, dass 5.000 Stunden gedauert hat, kann in einem viel kleineren Produkt münden, als ein Projekt das 3.500 Stunden lief – und das auch dann, wenn die gleichen Qualitätskriterien erfüllt wurden. Deshalb muss die Produktgröße als Konstante betrachtet werden. Ohne die Größe zu verstehen, indizieren andere Metriken (wie Qualität) nur Faktoren wie die Anzahl an Defekten (und selbst das Fehlerkonzept kann manchmal fragil sein). Wenn wir statt der Produktgröße die Projektgröße betrachten, sind alle abgeleiteten Schlussfolgerungen falsch. Schlimmer noch: Manchmal stehen die schlechtesten Projekte in Sachen Qualität am besten da und zwar einfach deshalb, weil die Ressourcenplanung höher war (und Projekte, die eine gewisse Funktionalität erreichen müssen, typischerweise mehr Zeit benötigen). Metriken darauf zu stützen, dass ein 5.000-Stunden-Projekt 25 Softwarefehler hatte, ist nicht dasselbe, wie wenn man Metriken für ein 3.500-Stunden-Projekt mit 25 Fehlern anwendet, selbst, wenn sie technisch betrachtet gleich sind – das erste war ineffizienter. Das ist ein bisschen, als würde die Welt Kopf stehen.
In anderen Fällen wird die Produktgröße manchmal (fälschlicherweise) mit der Anzahl der Codezeilen – in Englisch Lines of Code (LOC) – in Verbindung gebracht, die geschrieben oder editiert werden mussten. Angeblich sagen mehr LOC aus, dass das Ergebnis produktiver oder von höherer Qualität ist (selbst, wenn manche Zeilen unnötig sind). Das gleiche gilt für den Fall, dass die Produktgröße mit der Projektgröße verwechselt wird: Fälschlicherweise wird ein Programmierer, der ein Produkt mit 700.000 Codezeilen schreibt, besser bewertet als einer, der das gleiche Produkt in der gleichen Qualität, Leistung und Sicherheit mit nur 300.000 LOC erstellt. Und wieder, ganz einfach zu verstehen: Es ist nicht dasselbe, 10 Softwarefehler in 700.000 LOC zu haben, wie 10 Fehler in 300.000 LOC. Das erste Projekt scheint vielleicht besser, aber aus Sicht der Kundenfunktionalität kann es identisch sein. Natürlich gilt dieselbe Logik auch dann, wenn die Größe mit der Anzahl an Programmen, Prozessen, Teamgrößen, Projektdauer usw. in Verbindung gebracht wird. Auch hier steht die Welt Kopf.
Den LOC-Aspekt aus dieser Sicht mit einzubeziehen wirkt vielleicht ein bisschen abstrakt, aber leider gibt es keinen offiziellen Standard dafür, was eine LOC ausmacht. Handelt es sich um eine physische LOC? Mit oder ohne Kommentare? Manchmal können Codes eine Hilfestellung bieten, oftmals sind sie aber unnötig oder alt und wurden einfach nicht gelöscht. Bezieht sich die LOC-Zählung auf logische Zeilen, Statements, strukturiertes vs. unstrukturiertes Programmieren, eingebetteten Code usw.? Abhängig davon, welche Kriterien für LOC-Zählungen angewandt werden, kann es zu großen Unterschieden kommen, die sehr unterschiedliche Ergebnisse liefern. Manchmal liegt der Grund, sich für ein bestimmtes Kriterium zu entscheiden, einfach darin, dass dieses am besten zu einer bestimmten Situation, einem Vertrag oder abgeleiteten Metriken passt. Dieses faszinierende Thema würde Stoff für duzende Artikel und viele Studien liefern.
Hohes Maß an Zuversicht und Vertrauen
Das höchste Ziel sollte also die Messung der Produktgröße anhand standardisierter, anerkannter Methoden sein – kurzum mit Techniken, die eine globale Perspektive einnehmen und Zuversicht und Vertrauen schaffen, nicht nur auf interner Ebene, sondern auch im Hinblick auf die Beziehung zwischen Anbieter und Kunde. Mit dem richtigen Wissen und einer Akkreditierung kommen verschiedene Leute zu den gleichen Zahlen, in dem sie die Größe eines IT-Produkts oder die Funktionalitäten, die ein IT-Produkt ermöglicht, messen – und nicht den bezahlten Preis, die geleistete Arbeit für das Erstellen des Produkts, physischen Code oder die Zahl der Programme.
Die funktionale Größe kann durch verschiedene Methoden ermittelt werden, aber die IFPUG (International Function Point User Group, auch Function-Point-Verfahren) ist die am meisten gefestigte und genutzte Größe auf der ganzen Welt (zusammen mit Cosmic und NESMA, beide vor Jahren von IPFUG abgeleitet). Hier werden funktionale und nicht-funktionale Aspekte gleichermaßen berücksichtigt. Sie ist außerdem von der ISO (International Organization for Standardization) anerkannt, vereint die weltweit größte Community und hat dadurch, dass sie die weltweit meist genutzte ist, eine große Anzahl an standardisierten Indikatoren, Benchmarks und Referenzen, die auf jedem Level als Orientierung dienen. Metriken zu funktionalen Größen sind für Verträge zu Software-Entwicklungsprojekten in Ländern wie Brasilien, Italien, Japan, Malaysia oder Südkorea erforderlich und werden in dieser kleinen Welt viel genutzt.
