Softwareprojekte auf Diät

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