Große Projekte Schritt für Schritt realisieren
Noch immer wird bei Softwareprojekten häufig angenommen, dass ausgiebige Planung, detaillierte Spezifikation und exakte Kalkulation Projekterfolg versprechen. Einer raschen Realisierung des Systems und der Einhaltung von Budgetvorgaben soll so nichts im Weg stehen. Klingt überzeugend? Ein Blick auf die Realität vieler Softwareprojekte offenbart: die Sicherheit ist trügerisch, überdies wird häufig schlicht am tatsächlichen Bedarf vorbei entwickelt.
Veröffentlicht am:2014-06-26
Die Umsetzung umfangreicher Softwareprojekte kann mitunter sehr lange dauern. Wenn alles gut geht, wird Monate oder gar Jahre strikt nach Plan entwickelt und am Ende genau das Produkt budgetgetreu abgeliefert, von dem der Auftraggeber zu Projektbeginn glaubte, es später zu benötigen. Erweiterungen und Umbauten sind nur begrenzt vorgesehen und möglich.
Ein Hausbau, Zimmer für Zimmer
Der Ablauf ist sehr vergleichbar mit dem Neubau eines Hauses: Zuerst erfolgt eine vollständige, langwierige Planung; anschließend werden Genehmigungen eingeholt, das gesamte Haus wird gebaut und eingerichtet – erst dann kann der Bauherr einziehen und das Haus nutzen. Zwischen Beginn der Planung und Nutzung liegen schnell Jahre.
Was wäre, wenn man einen Hausbau so anfangen könnte, dass als erster Bauschritt nur das minimal Nötige gebaut wird, was man zum Einzug braucht – also beispielsweise ein Schlafzimmer, Bad und Küche? Wenn dieses minimal bezugsfähige Haus im Frühsommer fertig wird, kann der Garten als Wohnzimmer dienen und Möbel und Umzugskisten, die noch keinen Platz haben, werden übergangsweise in Containern gelagert?
Direkt nach dem Einzug wird die nächstwichtige Funktion realisiert. Abhängig vom Wetter kann das zum Beispiel der Swimmingpool im Garten, das Wohnzimmer mit Kamin oder ein Wintergarten sein – oder, falls alte Freunde ihren Besuch angekündigt haben, das Gästezimmer. Anschließend wird der nächste Schritt realisiert.
Der Vorteil? Statt während des gesamten Hausbau-Projektes Miete und Kreditzinsen parallel zu zahlen, können die Mietkosten schon nach kurzer Zeit entfallen und ein wesentlicher Teil des vom Haus erwarteten Nutzens wird früh realisiert. Die gesparte Miete kann für die schnellere Tilgung des Kredits oder zusätzliche Erweiterungen verwendet werden.
Ein weiterer Vorteil dieser Vorgehensweise ist, dass die Planung unmittelbar bedarfsorientiert erfolgt. Weder wird spekulativ das dritte Kinderzimmer vor dem ersten Kind gebaut, noch ein Gästezimmer ohne Gäste.
Alles nur Phantasie? Für Bauprojekte mag das zutreffen, insbesondere weil Änderungen an bereits gebauten Teilen des Hauses aufwändig und meistens mit großen Beeinträchtigungen der Wohnqualität verbunden sind - ebenso wie Möbelcontainer im Garten.
Früh veröffentlichte Produkte finanzieren ihre eigene Weiterentwicklung
In der Agilen Softwareentwicklung gehen Projekt-Teams seit vielen Jahren mit großem Erfolg nach genau diesem Schema vor. Aufbauend auf einem groben Gesamtplan wird Schritt für Schritt die Detailplanung vorgenommen und das nächste Feature erst dann realisiert, wenn das vorherige abgeschlossen ist. Der Gesamtplan dient dabei in erster Linie dazu, die Grundstrukturen - beim Bau die Statik, bei der Softwareentwicklung zentrale Architekturentscheidungen - von Beginn an möglichst passend für den geplanten Gesamtumfang auszulegen. Das Produkt geht online, sobald ein Minimal Marketable Feature realisiert ist. Software hat dabei den großen Vorteil, dass sich selbst die tragenden Wände später noch wesentlich leichter versetzen lassen als in Gebäuden.
Bei unserer neuen webfactory-Website haben wir dieses Prinzip konsequent angewendet: Zunächst haben wir im März 2013 nur eine neue Ein-Seiten-Website online gegangen, also eine Startseite mit den wichtigsten Informationen über uns und unsere Projekte. Da sich im April herausstellte, dass wir Ersatz für einen unserer Hauptentwickler brauchten, war das nächste Feature eine überzeugend gestaltete Stellenanzeige und die Seite "Über uns". Im Sommer folgten dann ausführlichere Projektbeschreibungen und schließlich im Februar 2014 das Redesign unseres Inside-Blogs. Als nächstes stehen im aktuellen Plan eine neue, ausführlichere Unternehmensdarstellung mit Teamprofilen und eine Anpassung der Startseite an die mittlerweile viel umfangreichere Website.
Eine Planungsmethodik, um Softwareprojekte selbstfinanzierend zu gestalten (also so, dass die ersten realisierten Features durch ihre Erlöse einen Teil der Weiterentwicklung finanzieren), beschreiben Mark Denne und Jane Cleland-Huang in ihrem Buch Software by Numbers und bezeichnen sie als Incremental Funding Methodology (IFM).
Im Falle eines Produktes, das keine direkten Erlöse generiert, wie im Beispiel von webfactory.de, ist die Selbstfinanzierung natürlich nicht unmittelbar messbar – im übertragenen Sinne allerdings durchaus. So kann zum Beispiel ein großer Kundenauftrag, der aufgrund eines frühen Launches der Basiswebsite schon gewonnen werden konnte, die Weiterentwicklung der Website finanzieren. Oder aber – und so bei uns geschehen – die durch die früh online gestellte Stellenanzeige gewonnenen Mitarbeiter können zur Verbesserung der Website eingesetzt werden.
Gibt es denn einen Festpreis für mein Projekt?
Ein vermeintlicher Vorteil großer, vorab vollständig durchkalkulierter Projekte ist, dass sie zum pauschalen Festpreis angeboten werden können. Bei einer Schritt-für-Schritt-Vorgehensweise hat der fehlende Gesamtpreis System: Wer entgegen der ursprünglichen Idee feststellt, dass er mit Schlafzimmer, Küche und Bad glücklich ist und den Rest des Grundstücks und Ausblicks lieber unverbaut lässt, kann das Bauprojekt bereits an dieser Stelle beenden. Umgekehrt kann das Projekt natürlich auch wesentlich umfangreicher werden als ursprünglich angedacht - wenn zum Beispiel wegen der attraktiven Lage noch eine vermietbare Wohnung realisiert werden soll.
Dreh- und Angelpunkt der agilen Vorgehensweise ist, dass zu jedem Zeitpunkt und für jedes Budget genau die wichtigsten und wertvollsten Funktionen realisiert und nutzbar sind. Umgekehrt wird kein Geld für Funktionen ausgegeben, die zwar zu Beginn sinnvoll erscheinen, aber später doch niemand benötigt. Denn eine wesentliche Erkenntnis ist, dass für Software- (wie auch für Bau-) Projekte zwar das grobe Ziel schon zu Beginn klar ist, die Unterziele und Details (Gästezimmer? Kinderzimmer? Hobbykeller?) aber noch nicht sicher benannt werden können. Das kann daran liegen, dass der Bedarf von externen Faktoren abhängt – häufig ist der Grund aber auch, dass erst in der tatsächlichen Nutzung klar wird, welche Funktionen wirklich benötigt werden. Je größer der zeitliche Abstand zwischen Planungs- und Nutzungsphase, desto größer ist auch das Risiko, dass nicht benötigte Funktionen geplant und realisiert werden.
Nebenbei gesagt: Auch ein fester Gesamtpreis ist häufig trügerisch, was nicht nur bei Großprojekten wie der Elbphilharmonie oder dem Berliner Flughafen sichtbar wird. Je größer und unübersichtlicher das Planungsvorhaben, desto schwieriger wird eine verlässliche Kalkulation und insbesondere auch das zuverlässige Abstimmen aller Detailwünsche des Bauherrn, der ja ein Gesamtbild des Projektes im Kopf haben muss. Schon kleine Änderungen oder unerwartete Hindernisse in frühen Projektphasen können dann den gesamten Plan hinfällig werden lassen.
Buchtipp
Alistair Cockburn, ein renommierter Experte für Software-Entwicklungsmethoden, hat seinen Hausumbau genau nach dem oben dargestellten Weg realisiert – die Erfahrungen beschreibt er plastisch als Case Study in seinem hervorragenden Buch Agile Software Development (2. Auflage).