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

3 Gedanken zu „Buch-Rezension zu „Software by Numbers““

  1. ZITAT:
    > •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.

    Genau das steht dort so eben nicht drin. Die Autoren negieren das vielmehr explizit und vertreten vielmehr die Ansicht, daß diese Entscheidung stets fallweise, und zwar konsequent auch hier anhand der jeweiligen aktuellen Zahlen, zu treffen sei.

    1. Hallo JensG,
      Wir liegen gar nicht so weit auseinander. Mit „was man jetzt auch wirklich braucht“ meinte ich das was für das aktuell zu bearbeitende MMF nötig ist. Die Auswahl des MMF, die Reihenfolge und was alles dazu gehört wurde ja durch die NPF-„Kette“ berechnet.
      Die ganze Zahlenarbeit und alle Berechnungen sind da bereits eingeflossen. Wenn dieses MMF bereit für die Entwicklung ist soll man dann als Entwickler eben nicht anfangen noch gleich alles andere anzugehen.
      Vor dem nächsten Entwicklungsschritt muss man die Zahlen wieder überprüfen und so fällt das nächste MMF vielleicht aus der Planung heraus. Was dafür schon entwickelt wurde ist in dem Fall oft teurer Müll.

      Ich hoffe mit dieser Ausführung meine Aussage ein wenig klarer dargelegt zu haben.

      Gruss Johnny

Kommentare sind geschlossen.