“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”
John Gall
Vor vielen Jahren sah ich eine beeindruckende Dokumentation über einen Mann, der in den Anden eine Hängebrücke baute. Zuerst wurde ein dünnes Seit über die Schlucht geworfen und mit dessen Hilfe ein dickes Seil herüber gezogen. Dafür musste der Mann in die Schlucht hinabsteigen und auf der anderen Seite der Schlucht hinaufklettern. Aber nachdem das dicke Seil dann auf beiden Seiten befestigt war, konnte der Mann Werkzeuge und Materialien über die Schlucht transportieren. Aus dem einzelnen Seil wurden mehrere Seile, dann das Grundgerüst einer Brücke und später eine vollständige Hängebrücke.
Was hat dies mit Agiler Softwareentwicklung zu tun? Ein Brückenbau ohne jede Art von moderner Technologie? Als Materialien nur Seile und Holzplanken? Schauen wir uns dazu eine andere Form von Bautätigkeit an, statt in luftige Höhen, blicken wir tief in die Felsen eines Gebirges.
Mehrere Teams von Bergarbeiten treiben Tunnel durch das Gebirge, damit die Teams gleichzeitig arbeiten können, beginnen sie nicht einfach an der einen Seite des Berges und bohren sich bis zur anderen Seite durch, sondern sie beginnen auf beiden Seiten mit ihren Arbeiten. So können sie die Zeit für den Tunnelbau mindestens halbieren. In diesem Fall treiben sie aber noch einen Schacht auf halben Wege in den Berg und beginnen von hier aus, in beide Richtungen, einen Tunnel. Damit reduziert sich die Zeit für den Tunnelbau fast auf eine Viertel der ursprünglichen Planung. Es gib jedoch ein Risiko in diesem Plan. Irgendwo im Berg werden die Grabungen aufeinander treffen. Erste wenn der Durchstich erfolgt, weiß man um Erfolg oder Misserfolg. Die Messungen und Planungen und Arbeiten müssen überaus genau ausgeführt werden, da sonst ein horizontaler oder vertikaler Versatz der Tunnel das Projekt scheitern lässt.
Tunnelbauten sind klassische Wasserfall Projekte, in denen ausgiebig geplant und dann ohne große Änderungen der Bau ausgeführt werden kann. Hin und wieder gibt es zwar geologische Überraschungen, aber ein Tunnelplan ist, im wahrsten Sinne des Wortes, in Stein gemeißelt.
Viele Software Entwicklungen werden wie Tunnelbauprojekte durchgeführt. es werden viele Tunnelabschnitte abgesteckt und mit den Arbeiten begonnen und später macht man sich Gedanken über die Anschlussstellen der einzelnen Abschnitte. Software-Projekte werden aber nicht durch Granit getrieben , sondern befinden sich in einer weichen, formbaren und scheinbar lebendigen Masse, die sich Marktanforderungen nennt. Auch wenn die Abschnitte zu Beginn korrekt umgesetzt werden, kann es sich im Laufe des Projektes zeigen, dass etliche Anschlussstücke vergessen, Anforderungen verändert und einige Teile völlig falsch geplant wurden.
Die Agile Entwicklung fußt auf 12 Prinzipien. Das erste von ihnen lautet
“Customer satisfaction through early and continuous software delivery.”
Ein Tunnelbauprojekt, wie oben beschrieben, entspricht nicht diesem Prinzip. Ein Tunnel der erst einige Meter in den Berg getrieben wurde, hilft dem Kunden nicht weiter. Einzelne Abschnitte im Berg auch nicht. Der Kunde kann das Produkt erst nutzen, wenn alle Abschnitte erfolgreich miteinander verbunden wurden.
Die primitive Hängebrücke steht für Projekte, die dem Kunden frühzeitig ermöglichen, Rückmeldungen an das Projektteam zu liefern. Obwohl zu Beginn nur ein Seil über die Schlucht gespannt ist, kann der Kunde sie nutzen. Er kann zwar noch keine größeren Lasten über die Schlucht transportieren, aber das wird sich nach und nach ändern.
Ein Bezahlsystem für einen Onlineshop kann entweder Bottom-Up wie ein Tunnelbauprojekt oder Top-Down wie eine Hängebrücke erstellt werden. In beiden Fällen benötigt man einen Warenkorb, eine Auswahl der Zahlungsart, Dialoge für Banküberweisungen, Kredikartenzahlungen oder Bitcoin-Transaktionen.
Während bei der Buttom-Up Methode die vollständigen Komponenten zusammengefügt werden und sich erst dann, zum Ende des Projekts, gravierende Planungsmängel offenbaren, startet ein Top-Down Entwurf mit dem einfachsten funktionierenden System. Der Warenkorb kann zu Beginn vielleicht nicht mal die Produkte korrekt anzeigen und als Zahlungsart ist Anfangs nur die Vorkasse möglich, aber der Kunde kann die Software testen, Rückmeldungen geben und neue Ideen erproben.
Für das Entwicklungsteam bietet eine Top-Down Entwicklung auch einen unschätzbaren Wert. Alle Beteiligten können, vom ersten Tag an, auf einen wirklich funktionierenden Entwurf setzen.