Buch-Rezension zu "Was man nicht messen kann..."

"Was man nicht messen kann... ... kann man nicht kontrollieren" von Tom DeMarco ist die deutsche Übersetzung seines 1982 erschienenen Klassikers "Controlling Software Projects". Die Führung von Projekten über Kennzahlen tönt nicht gerade interessant - doch sollte man sich zu keinem vorschnellen Urteil verleiten lassen.

Auch heute noch aktuell

Die Einleitung beschreibt sehr genau die Probleme, die in so manchem IT-Projekt herrschen. DeMarco schafft es, diese so zu benennen, dass es einem unverständlich dünkt, das man auf all dies nicht selber gekommen ist. Es ist doch alles so klar. Ich fand die Einleitung eine der treffendsten Beschreibungen der aktuellen Probleme, die ich seit langem gelesen habe. So war ich recht erstaunt, als ich das Erscheinungsjahr sah - 1982, mein Geburtsjahr. In der ganzen Zeit die ich auf der Welt bin hat sich somit an den Problemen nichts geändert. Dies ist doch eine rechte Enttäuschung.

In den Jahren kamen (und gingen) unzählige Programmiersprachen, Vorgehensmodelle und Theorien. Und dennoch befinden wir uns immer noch am gleichen Punkt. DeMarcos Buch liefert Erklärungen, wieso dies so ist. Genau das was damals schon die Probleme verursachte, verschuldet diese auch heute noch. Eigentlich verständlich - wenn man Dinge immer gleich macht, wird auch immer das gleiche heraus kommen.

Die Vorschläge für dezidierte Mess-, Schätz und Testgruppen kosten viel Geld. Doch was kostet ein einziges fehlgeschlagenes Projekt? Das Buch geht dem nach und liefert Fakten. Was kosten Fehler? Wie kann man diese Verhindern? Und so wird aus einer ganzen Reihe von trockenen Kennzahlen plötzlich etwas sehr konkretes.

Es gibt aber auch einige wenige Punkte, bei denen man das Alter der Tipps merkt. Die Forderung den Code unkompiliert ans Testteam zu geben und das die Tester dann zum ersten Mal kompilieren erscheint heute wie aus einer anderen Welt. Gleiches gilt für das strikte Testverbot für Entwickler. In Zeiten von Unit Tests und TDD ist so ein Ansatz überholt.

Vom Chaos bis zur Qualität

DeMarco nimmt einem auf einen Rundgang durch die Führung von Projekten. Im Gegensatz zu "Der Termin" allerdings nicht in eine einzige Geschichte verpackt. Zahlreiche Formeln und Diagramme unterlegen seine Theorien. Somit ist es eher ein "Schulbuch" als ein Roman. Aber keine Angst! Die Formeln und Diagramme werden so erklärt, dass man deren Sinn und Zweck verstehen kann. Die 4 Teile des Buches gliedern sich so:

1. Chaos und Ordnung im Software-Entwicklungsprozess
2. Modelle und Kennzahlen eines Systems
3. Kostenmodelle
4. Softwarequalität

Der Rundgang beginnt beim feststellen der aktuellen Situation und zeigt, wie man unter Verwendung von Kennzahlen und einem strukturierten Vorgehen zum Ziel kommt. Von den zahlreichen Punkten sind mir die folgenden besonders aufgefallen.

Schätzen oder Messen?

Die Qualität einer Schätzung kann durch viele Einflüsse verschlechtert werden: Mangelnde Erfahrung, fehlende Fähigkeiten, Verwendung falscher Ausgangsdaten oder den Druck, genehme Schätzungen zu liefern. All dies führt nur dazu, dass die Schätzung mit der Realität nicht viel gemeinsam hat. Dem Messen vertrauen wir deutlich mehr. Aber was wird gemessen? Was machen wir wenn das was wir messen wollen noch nicht vorliegt? Nichts machen kann da keine Lösung sein.

Es braucht somit die Kombination von Schätzen und Messen. Und vor allem eine Rückmeldung an den Schätzer, sobald die Messresultate vorliegen. Nur mit diesem Feedback kann sich der Schätzer verbessern. Und die Schätzer brauchen Erfahrung. DeMarco schlägt vor, innerhalb der Firma eine unabhängige Gruppe von Schätzern einzurichten, die sich nur um das Schätzen kümmern. Wenn die Schätzer vom zu schätzenden Objekt unabhängig sind und ihre Leistung nur an der Genauigkeit ihrer Schätzung gemessen wird, hat man eine Chance auf eine objektive Schätzung. Andernfalls gibt es einen Zielkonflikt, bei dem die Schätzung meistens unterliegt.

Der Entwurf zählt

Damit man etwas zu schätzen hat, braucht es eine Spezifikation (Was) und einen Entwurf (Wie). Nur diese Dokumente stehen am Anfang des Projekts zur Verfügung und können zur Schätzung von Aufwand und Kosten herangezogen werden. Die Schätzung auf Basis von Codezeilen fällt da flach - es gibt noch nichts dergleichen.

Ein Entwurf. Das ist zu häufig eines der ersten Dinge die man einspart um "agil" zu sein. Braucht es nicht, ist eh zu teuer und schliesslich und endlich hat man ja den Programmierer, der dies festlegt. Ist dies wirklich so? Ein Entwurf der klar zeigt welche Dinge wo gemacht werden müssen und wie die einzelnen Module zusammenarbeiten, wäre äusserst hilfreich. Sowohl für die Entwickler, die deutlich weniger vermuten müssten. Auch für die Tester würde ein guter Entwurf viel bringen. Wenn klar ist was welcher Teil wie machen müsste, kann man auch genau dies testen. Und man hat klare Vorgaben, mit denen man den Erfolg des Projekts am Ende messen kann.

Wie es DeMarco auch schreibt darf der Entwurf natürlich nicht am Anfang einmal gemacht werden und dann in einer Schublade verschwinden. Neue Anforderungen müssen dort genauso aufgenommen werden wie in der Spezifikation. DeMarco formuliert dies auch recht direkt:

Es gibt keinen Ersatz für das Prinzip, dass man zuerst denken und dann handeln sollte.

Der Entwurf soll daher als Bauplan dienen. Dabei ist es wichtig, dass dieser auch mit den Kunden besprochen werden kann - und zwar ohne vorher wieder eine "Konvertierung" durchzuführen.

Ein Fehler kommt selten allein

Entgegen der Vermutung sind Fehler nicht gleichmässig über den ganzen Code verteilt. Hat man Module bei denen schon etliche Fehler gefunden wurden, ist die Wahrscheinlichkeit gross, dass dort noch mehr Fehler versteckt sind. Eine Erklärung dafür liegt in der Art wie die Module erstellt werden. In der Regel kümmert sich ein Teil der Entwickler um Modul A, eine andere Gruppe um Modul B usw. Es gibt Leute die mehr Fehler machen als andere. Arbeiten diese vor allem an Modul A werden dort häufiger Fehler auftreten.

DeMarco liefert einige Beispiele wie durch einen anderen Einsatz der Leute die Fehler reduziert und die Qualität gesteigert werden kann. Die dahinter liegende Idee ist wiederum einfach: Das verhindern von Fehlern ist billiger als deren Behebung. Um zu wissen welche Leute besser für die Fehlersuche als für die Entwicklung geeignet sind, braucht es aber Messdaten. Und damit schliesst sich der Kreis wieder bei der Messbarkeit.

Fazit

Ein aufschlussreiches Buch das an Aktualität fast nichts eingebüsst hat. Heute würde man zur Modellierung UML verwenden und so liesse sich einiges an Erklärung für die Darstellungsart von DeMarco einsparen. Messen kostet, genauso Qualität. Aber erst recht teuer werden fehlgeschlagene Projekte oder ein nachträgliches anheben der Qualität. In 28 Jahren wird dieses Buch hoffentlich nicht mehr aktuell sein.

Wie bei allem darf man es natürlich auch beim Messen nicht übertreiben. Wenn man nur noch am messen ist, fehlt die Zeit um zu arbeiten. Auch hier benötigt es ein Gleichgewicht.

Zum Buch

"Was man nicht messen kann... ...kann man nicht kontrollieren" von Tom DeMarco, Mitp-Verlag, 2. überarbeitete Auflage 2008, ISBN 978-3-8266-1488-0, 450 Seiten