Softwareprojekte auf Diät: Schlanke Lösungen sind gefragt

17. April 2014Prof. Dr. Volker Gruhn

Agile Softwareentwicklung lässt viel Spielraum für Entscheidungen – auch spät im Projekt. Das ist inhaltlich sinnvoll und in gewissen Maßen unvermeidbar, denn viele Softwaresysteme sind – abstrakt betrachtet – soziotechnische Systeme: Sie können als organisierte Menge von Menschen und Technologien verstanden werden, die in einer bestimmten Weise strukturiert sind, um ein spezifisches Ergebnis zu produzieren. Und sie sind nicht vollständig beschreibbar. Selbst der Versuch einer möglichst weitgehenden Vorab-Spezifikation ist, zumindest für Informationssysteme ohne ausgeprägte Risiken, unwirtschaftlich. Vieles lässt sich erst während der Entwicklung festlegen, direkt umsetzen und notfalls neu bewerten. Gerade das ist  der Charme der agilen Entwicklung. 

Nachvollziehbar ist aber auch der Wunsch nach Kostentreue. Wie teuer Software wird, muss von vornherein bekannt sein. Ansonsten lösen sich grundlegende Annahmen über die Planbarkeit wirtschaftlicher Aktivitäten in Luft auf. Das sieht auf den ersten Blick nach einem Dilemma aus, welches sich bei genauerem Hinsehen aber auflösen lässt.

Milderung versprechen zwei Mechanismen. Erstens gibt es nicht nur späte Anforderungen (typischerweise zuständig für Kostensteigerungen), sondern auch zu Frühe. Solche, die es mehr oder weniger zufällig in den Status einer Anforderung schaffen, sich bei näherem Hinsehen während der Entwicklung aber als entbehrlich entpuppen. Hier zeigt die agile Entwicklung ihren Charme, denn die zu frühen Anforderungen können einfach „weg-priorisiert“ werden. Im Sinne der Planbarkeit ist es nun nützlich, wenn die Projektbeteiligten beim Auftreten später Anforderungen erst einmal prüfen, welche zu Frühen  dafür wegfallen können. Erstaunlicherweise führt ein solcher Mechanismus nicht nur zum kontinuierlichen Aufräumen, sondern beschränkt auch die allzu leicht ausufernde Fantasie beim Finden später Anforderungen.

Zweitens ist es sinnvoll, alle wirtschaftlich beteiligten Stakeholder (alle Budgetverantwortlichen, Lieferanten etc.) auf schlanke Software zu verpflichten. Das Ziel sollte nicht viel Software sein. Es muss darum gehen, die richtige Software zu schreiben – also die, deren Anwendung wirklich zur Wertschöpfung beiträgt. Das kann schon mal bedeuten, dass nicht alles automatisiert wird, dass nicht jeder selten genutzte Dialog perfekt „usability-engineered“ wird. Und dass goldene Software-Wasserhähne nicht angeschraubt werden.

Wer braucht schon Software-Plunder?

Schlanke Software hat verschiedene Vorteile. Zum einen kostet sie weniger in der Entwicklung und – wahrscheinlich noch wichtiger – der nebensächliche „Software-Plunder“ muss nicht auch noch weiterentwickelt, gewartet und immer wieder mitgetestet werden. Also, schlanke Software in einvernehmlicher „Schlankheitsorientierung“ zwischen Auftraggeber und -nehmer. Dass Auftragnehmer, die im „Times-x-Material“-Modell arbeiten, auch Ziele haben, die mit schlanker Software in Konflikt geraten können, liegt auf der Hand. Dass Anwender und Fachbereiche, die lange auf neue Software gewartet haben, nicht in erster Linie drüber nachdenken wollen, was weggelassen werden kann, ist auch klar. Unternehmensarchitekten haben berechtigte Wünsche an Software-Sekundäreigenschaften. Nicht immer führen diese Wünsche direkt zu Schlankheit.

Dann gibt es noch Festpreis-Projekte – und das trotz der fehlenden, wirklich vollständigen Spezifikation. Mechanismen zur Bewertung von späten Anforderungen sind bekannt (und teuer). Das Weglassen zu früher Anforderungen wirtschaftlich abzubilden macht schon mehr Schwierigkeiten. Und wie häufig im Leben: Schwierige Sachen werden gerne vernachlässigt. Deshalb wird nicht konsequent aussortiert, sondern gebaut und geliefert wie bestellt (zuzüglich der Aufwände für die zahlreichen zu späten Anforderungen). Schlanke Software wird das nicht.

Was sorgt für schlanke Software? Wie können alle Beteiligten auf dieses Ziel verpflichtet werden? Shared-pain-/-shared-gain-Modelle sind die Antwort. Es sind Modelle, die die genannten Mechanismen umsetzen und den Gesamtfokus auf die oben geforderte schlanke Software legen. Wie diese Modelle im Detail aussehen, ist Thema eines weiteren Blog-Artikels. Eins vorab: Ohne Vertrauen funktionieren solche Modelle nicht. Sobald Juristen und klassische Einkäufer die Eckdaten für Software-Lieferverträge bestimmen und darauf beharren, dass Software genauso zu bestellen sei wie Bleistifte, sollten alle lieber gleich bei „fetter Software“ bleiben, Controller für epische Change Request-Diskussionen und -Umsetzungen engagieren und sich an viel Software erfreuen.

Agile Softwareentwicklung und schlanke Software sind wichtige Aspekte unserer New School of IT. Unsere detaillierten Whitepaper informieren Sie genauer über dieses und weitere Themen: https://www.new-school-of-it.de/de/downloads/download_page.jsp

Prof. Dr. Volker Gruhn Prof. Dr. Volker Gruhn gründete 1997 adesso mit und ist heute Vorsitzender des Aufsichtsrats.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentare

Michael Brandt 6. Dezember 2014 Website des Autors

Schöner Artikel, der einige gute Ansätze liefert.
Einzig der Punkt mit den frühen bzw. späten Anforderungen wurde vielleicht ein wenig simplifiziert.
Frühe Anforderungen weg zu priorisieren hört sich einfacher an, als es das im realen Softwareprojekt ist.
Die Priorisierung von Anforderungen innerhalb eines Fachbereichs oder gar fachbereichsübergreifend gehört meiner Ansicht nach zu den Königsdisziplinen im agilen Requirements-Engineering.

Kommentar hinzufügen:

Ihr Kommentar: