Buch-Rezension zu „Waltzing with Bears“

„Waltzing with Bears: Managing Risk on Software Projects“ von Tom DeMarco und Timothy Lister erschien 2003 bei Dorset House. Risikomanagement ist etwas was nicht erst in den letzten Jahren aktuell wurde. DeMarco und Lister haben ihre Erfahrungen in dieses knapp 200 Seiten umfassenden Buch einfliessen lassen. Wie meist bei DeMarco ist das Buch trotz der vielen Theorie sehr angenehm zu lesen.

 
 
 
 
Die einzelnen Teile des Buches gehen diesen Fragen rund ums Risikomanagement nach:

• Warum?
• Wann nicht?
• Wie?
• Wie viel?
• Wird’s gemacht?

Im ersten Teil wird auf anschauliche Art erklärt was Risiken sind und wieso man vor ihnen nicht weglaufen kann. Projekte die ganz ohne Risiko sind haben meist auch nur sehr wenig finanzielle Anreize, wodurch man früher oder später hinter die risikoreichen Projekte muss.

 
Wann auf Risikomanagement verzichten?
Teil 2 geht dann auf die Situationen ein, wo man besser auf ein Risikomanagement verzichtet. Dies mag einen erstaunen, doch gibt es solche Situationen wirklich. Es macht schlicht keinen Sinn in einer Firma die nur Ja-Sager will von Dingen wie Risiken zu sprechen. Bei Risiken spricht man von Möglichkeiten und Unsicherheiten. Ein Firmenmotto wie

It’s okay to be wrong, but not okay to be uncertain.

steht diesem Vorhaben im Weg. Eine andere Situation ist wenn Glück integraler Bestandteil des Projektplans ist. Dabei ist nicht gemeint dass man mit ein wenig Glück vielleicht ein wenig früher fertig wird. Sondern das man bei allen Schritten viel Glück braucht damit man überhaupt auch nur im Entferntesten diesen Plan umsetzen kann.

 
Wie managt man Risiken?
Gut die Hälfte des Buches widmet sich der Frage wie man Risiken managen kann. Als erstes Beispiel dient das Risiko des verpassten Liefertermins. Mittels Terminkurven wird die Wahrscheinlichkeit des Lieferzeitpunktes untersucht. Die eine Grenze bildet der frühestmögliche Zeitpunkt (N) unter optimalsten Bedingungen, die andere ist der Termin bei dem man sicher fertig sein wird (und damit viel weiter in der Zukunft liegt als das Projekt dauern soll).

Der Punkt N wird hier als Nano-Prozent Datum definiert. Die Chancen zu diesem Zeitpunkt zu liefern sind grösser als 0, aber immer noch verschwindend gering. Leider wird dieser Zeitpunkt aber oft als Liefertermin benutzt, was zu all den bekannten „Verzögerungen“ führt.

Wie geht man nun mit diesem Risiko um? Die Autoren schlagen vor Anzeichen für ein Eintreten zu sammeln und zu überwachen. Davon erhofft man sich bei ersten Anzeichen noch reagieren zu können. Allerdings gilt es bei grösseren Risiken Vorkehrungen zu treffen. Genau wie bei einer Versicherung muss man sich vor dem Eintreffen des Schadensereignisses darum kümmern. Dabei muss man wieder abwägen wie viel einem eine Vorkehrung für etwas das nur vielleicht eintreffen wird wert ist. Es wäre kein Buch von DeMarco wenn es dazu nicht auch zahlreiche Formeln und betriebswirtschaftliche Grundlagen gäbe.

Neben der Terminüberschreitung gibt es auch zu anderen häufigen Risiken bei Software Projekten (wie Explosion der Anforderungen oder Personalfluktuation) Beispiele die nach dem gleichen Muster angegangen werden.

 
Risiken minimieren
DeMarco und Lister haben auch etliche Ansätze zum Reduzieren der Risiken. Für die Lieferverzögerung ist ihr Ansatz die Software in mehreren Teilen zu liefern. Mit doch recht vielen Worten wird ein vorgehen erklärt das anhand des Nutzens für den Kunden Teile abgrenzt und zu Lieferpaketen gruppiert. Aus heutiger Sicht ist einem so ein Vorgehen aus Scrum oder XP bekannt und bräuchte weniger Erklärungsbedarf.

 
Kosten, Nutzen und Risikobereitschaft
Wie auch bei „Software by Numbers“ sollten für etliche Berechnungen sowohl die Kosten wie auch der Nutzen vorliegen. DeMarco und Lister sind diesbezüglich aber ein wenig realistischer:

Cost = $6,235,812.55
Benefit = „We gotta have it.“

Ein wenig mehr Erklärung wie man dann aber doch zu genügend guten Zahlen kommt hätte in dem Buch noch Platz finden sollen.

Ein weiteres schönes Zitat zur Risikobereitschaft zeigt eines der grossen Probleme bei Software Projekten:

Take lots of risks when the benefit is negligible. How else can we possible get costs down enough to justify this loser project?

Dies steht im Wiederspruch zu dem was man eigentlich erwarten würde: Viel Risiko wenn es viel zu gewinnen gibt, wenig Risiko wenn der mögliche Nutzen minimal ist. All die Death-March Projekte zeigen aber das DeMarco und Lister auch hier recht haben. Leider.

 
Fazit
Ich finde das Buch ist ein guter Einstieg ins Thema. Es deckt die 20% des Themas Risikomanagement ab die rund 80% des Nutzens beinhalten. Damit ist aber auch klar dass man nach dem Lesen kein Experte für Risikomanagement sein kann.

Ein wenig mehr Wissen über Risiken im Entwicklerteam würde noch so manchem Projekt gut tun. Dazu kann man dieses Buch gut nutzen.

 
Zum Buch
“Waltzing with Bears: Managing Risk on Software Projects” von Tom DeMarco und Timothy Lister, 2003 Dorset House

Buch-Rezension zu “Software by Numbers“

“Software by Numbers – Low-Risk, High-Return Development“ von Mark Denne und Jane Cleland-Huang erschien 2003 bei Prentice Hall. Die Idee des Minimum Marketable Feature wurde hier zum ersten Mal erwähnt und mit Zahlen Unterlegt.

 
Zahlen über Zahlen
Das Buch heisst zu Recht „Software by Numbers“. Denn hier geht es vor allem um die betriebswirtschaftliche Seite der Softwareentwicklung. Begriffe wie ROI und Break-even Time sollte einem geläufig sein, bevor man sich diesem Buch zuwendet. Nur so als Warnung.

 
Minimum Marketable Feature
Das Ziel des Buches ist es Softwareprojekte so zu optimieren, das diese möglichst grosse Gewinne abliefern. Zu diesem Zweck nutzen die Autoren die Incremental Funding Methodology (IFM). Die Idee dahinter ist das ein Projekt so schnell wie möglich die notwendigen finanziellen Mittel für die Weiterentwicklung selber generiert. Dies zwingt einem dazu möglichst schnell ein für den Kunden sinnvolles Paket an Teilfunktionalität auszuliefern. Diesen Teil nennen sie das Minimum Marketable Feature (MMF).

Software in Teilen auszuliefern ist heutzutage nichts ungewöhnliches mehr. Sei es mit XP, Scrum, Kanban – überall ist man dabei viele kleine Teillieferungen zu erstellen. Das MMF ist also nicht ein theoretisches Konstrukt sondern höchstens ein anderer Name für etwas was man als Entwickler bereits zu liefern versucht.

Im Buch ist das MMF die Ausgangslage für alle Berechnungen. Man kennt die Kosten, den Nutzen und weis zudem was für Abhängigkeiten zwischen den MMFs bestehen. So kann man diese zu Ketten (Strand) zusammenfügen. Für jede dieser Ketten kann man den Net Present Value (NPV) berechnen, der als Entscheidungsgrundlage für die Priorisierung dient. Das was den höchsten Gewinn liefert ist dann die Kombination der Ketten, die man entwickeln sollte.

 
Theorie ok – und die Praxis?
Das Schöne an all den theoretischen Beispielen ist das man nicht nur die Kosten kennt, sondern auch das Risiko und den Ertrag. In der Praxis dürfte genau hier der Knackpunkt liegen: Die meisten Projekte scheitern bereits an der Aufwandsschätzung der einzelnen Teilaufgaben. Wie will ein Projekt das bereits bei diesen täglichen Arbeiten um Faktoren daneben liegt den Nutzen auf tausend Franken/Euro/Dollar genau schätzen?

Die ganzen Berechnungen machen aber nur dann Sinn, wenn man auch verlässliche Zahlen hat. Im Buch kommen diese Zahlen aus der Finanzabteilung, womit die Autoren der Frage nach der Beschaffung gekonnt ausweichen. Das wird in der Praxis wohl meistens so sein, ich hätte dennoch gerne mehr dazu erfahren.

 
Was haften bleibt
Auch wenn man von BWL keine Ahnung hat, so gibt es doch eine ganze Reihe von Punkten die man mitnehmen kann:

• Ein MMF ist die kleinste sinnvolle Funktionseinheit die dem Kunden einen Nutzen bringt.
• Je schneller man ein MMF liefert desto schneller profitiert der Kunde davon. Dieser Nutzen kann sowohl mehr Funktionalität wie auch grössere Kosteneinsparungen bedeuten.
• Je eher der Kunde das MMF hat desto eher erfährt man ob das Projekt auf dem richtigen Weg ist und die Ziele auch erreichen kann.
• Die Reihenfolge in der man die MMF entwickelt kann einen gewaltigen Einfluss auf das finanzielle Ergebnis des Projekts haben.
• Man soll immer nur das bauen, was man jetzt auch wirklich braucht. Ein Refactoring zu einem späteren Zeitpunkt kostet oft weniger als die Verzögerung durch den Wartungsaufwand von Teilen die man irgendwann vielleicht brauchen wird.
• Hin und wieder ist die beste finanzielle Entscheidung ein MMF nicht zu entwickeln.

Für diejenigen die im Tagesgeschäft mit Zahlen arbeiten müssen gibt es noch einen weiteren Nutzen. All das was die Entwickler bisher nur mit dem Bauchgefühl erklären konnten lässt sich mit dem Buch durchrechnen. Im Gegensatz zu „The Economics of Iterative Software Development“ kann man mit dem Buch darlegen, wieso sich eine iterative Softwareentwicklung auch finanziell lohnt.

 
Fazit
Um von diesem Buch voll profitieren zu können muss man ein Vorwissen zu BWL haben. Die theoretischen Grundlagen finde ich sehr gut und sollte ich eine auf Zahlen basierte Entscheidung für oder gegen ein SW-Projekt fällen müssen würde ich auf dieses Buch zurückgreifen.

Bei meiner täglichen Arbeit fehlen mir aber die detaillierten Zahlen für Kosten und Nutzen pro Periode. Das Minimum Marketable Feature ist als Gedankenstütze aber auch da sehr nützlich. Je weniger Zeit man hat desto mehr muss man auf die kleinstmögliche Funktionalität mit einem Mehrwert für den Kunden achten.

 
Zum Buch
“Software by Numbers – Low-Risk, High-Return Development“ von Mark Denne und Jane Cleland-Huang, 2003 Prentice Hall, ISBN 978-0-131-40728-2, 208 Seiten, Englisch

Buch-Rezension zu “The Economics of Iterative Software Development”

“The Economics of Iterative Software Development – Steering Toward Better Business Results” von Walker Royce, Kurt Bittner und Mike Perrow erschien 2009 bei Addison Wesley. Ein Buch über den wirtschaftlichen Wert von iterativen Vorgehensmodellen bei der Software-Entwicklung tönt interessant. Und mit unter 200 Seiten erwartete ich eine kurze, aber doch fundierte Auseinandersetzung mit dem Thema.

 
Klein – aber fein?
Bei dem geringen Umfang war mir klar, dass ich keine grosse theoretische Abhandlung erwarten konnte. Die 3 Autoren haben fundierte Kenntnisse in der Projektführung und sind mit RUP(Rational Unified Process) bestens vertraut – einer war sogar bei der Entstehung massgeblich beteiligt. Bei diesem Hintergrund erwarte ich einerseits Werbung für RUP und andererseits eine praxisbezogene Darstellung wie man zu den besseren Resultaten kommt.

 
Ein schöner Vergleich
In der Einleitung wird die Planung eines Software-Projekts mit der Planung einer mehrmonatigen Reise verglichen. Dort wird man zu Beginn nur grob die wichtigsten Stationen planen und erst vor Ort sich mit Details wie dem Mittagessen oder der Parkplatzsuche beschäftigen. Mir hat dieser Vergleich sehr gefallen, da dieser mit wenigen Worten die Sache auf den Punkt bringt. Leider ist dies das Highlight des Buches.

 
Aktuell ja, aber zeitgemäss?
Die Resultate vom CHAOS-Report 2007 zeigen, dass dieses Buch nicht all zu alt ist. Hätte man den dazugehörigen Abschnitt weggelassen, könnte man als Leser auf die Idee kommen, das Buch stamme aus dem letzten Jahrtausend.

Wäre das Buch vor 20 Jahren erschienen, hätte man viele der Ideen aus dem Buch wohl als Meilenstein bezeichnen können. Iteratives Vorgehen gab es schon vorher, aber nun hätte man ein Buch gehabt das diese Vorgehensmodelle mit einem Mehrwert fürs Geschäft kombiniert.

Aber schon vor 10 Jahren hätte man mit den Ideen nicht mehr wirklich viel Beachtung erhalten. Der Trend zeigte schon stark in Richtung der agilen Methoden (wie XP). Wer sich vom Wasserfall aber erst in Richtung iterative Methoden verabschieden wollte, hätte damit doch noch einiges anfangen können.

Da das Buch aber 2009 erschienen ist, muss man es auch danach bewerten. Und das sieht schlecht aus. Die Probleme mit dem Wasserfall-Modell sind in jedem halbwegs brauchbaren Fachbuch in unzähligen Varianten beschrieben worden. Gleiches gilt für Iterative Vorgehensmodelle sowie deren Vorteile und wie man diese Einführt.

Es scheint fast als ob man irgendwo ein verstaubtes Manuskript gefunden hätte und dies nun doch noch veröffentlichen wollte.

 
Fazit
Das Buch war für mich nach der Einleitung ein kompletter Reinfall. Den Autoren gelingt es trotz ihrer Praxiskenntnisse nicht, ihre Ideen und Thesen (messbar) zu belegen. An Zahlen fehlt es nicht, aber woher die kommen und was man da eigentlich gemessen hat bleibt im Dunkeln.

Wer sich für das Thema interessiert, sollte sich “Was man nicht messen kann…” von Tom DeMarco anschauen. Dies ist trotz seines Alters noch immer ein Must-Read. Wer es gerne kürzer hätte, sollte sich unbedingt den Blogpost von Trond Wingard anschauen.

 
Zum Buch
“The Economics of Iterative Software Development – Steering Toward Better Business Results” von Walker Royce, Kurt Bittner und Mike Perrow, 2009 bei Addison Wesley, ISBN 978-0-321-50935-2, 192 Seiten

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