Komischerweise laufen auch heute noch viele Softwareprojekte nach dem Wasserfallmodell ab: Fachleute schreiben die formalen Geschäftsanforderungen, Architekten destillieren daraus ein abstraktes Modell, Programmierer schreiben den Code und Tester prüfen diese auf Einklang mit den Anforderungen. Am Ende kommt im schlimmsten Fall ein Produkt heraus, das unbrauchbar ist.

Im Ingenieurswesen hat diese Methode den zweiten Weltkrieg nicht überlebt. Unter der Bedrohung der deutschen Wehrmacht mussten die alliierten Kontrahenten neue und bessere Geräte und Strategien entwickeln, die den schnellen Erfolg auf das Schlachtfeld bringen. Dazu mussten für bestehende Waffen Verbesserungen und Kampfwertsteigerungen rasch entwickelt werden -- jede Verzögerung kostete Menschenleben und schwächte die eigene Truppe.

Aus der Geschichte lernen

Zuvor hatte bereits die Wehrmacht entsprechende Lehren aus dem ersten Weltkrieg gezogen: Die langwierigen Grabenkämpfe und überschwere Geschütze hatten Landgewinn zu einer mühsamen Angelegenheit gemacht. Zermürbende Gefechte hatten den Kampfgeist und die Kampfkraft der Truppe aufgezehrt. Die Strategen hatten dann die Panzertruppe und die Beweglichkeit in den Gefechtsschwerpunkt gerückt. Der Kommandeur bekam das Konzept des "Gefechts der verbundenen Waffen" an die Hand, um mit dem gesamten Potenzial seiner Streitmacht zuzuschlagen. Kampf- und Unterstützungstruppen arbeiteten Hand in Hand unter gemeinsamer Führung.

Die Alternative zum Grabenkrieg: Feuer und Bewegung. (Quelle: Deutsches Bundesarchiv)

Beweglichkeit und Schnelligkeit waren seit Jahrtausenden die entscheidenden Faktoren gewesen, um eine Schlacht zu gewinnen. Mit der Beweglichkeit und Kampfkraft der Panzertruppe hatte zum Ende der 1930er Jahre niemand gerechnet; die deutschen Truppen konnten ohne nennenswerte Gegenwehr vorrücken.

Natürlich geht es in der Softwareentwicklung normalerweise unblutig vonstatten. Die entscheidenden Lehren aus Kriegsführung und Ingenieurswesen kann man aber trotzdem ziehen und hat das auch schon getan: Anfang der 1990er Jahre begannen "bewegliche" (agile) Modelle auch in der Softwarebranche Einzug zu halten. Obwohl es Bereiche gibt, die von einem formalen Prozess profitieren (v.A. Banken, Medizin, Luft- und Raumfahrt), wird ein innovatives Produkt mit agilen Prozessen schneller auf dem Markt gebracht und schneller verbessert werden können.

Kein Plan ist so gut, dass er den ersten Feindkontakt übersteht. (General von Moltke)

Wie ein leichtgewichtiger Entwicklungsprozess umzusetzen ist, hängt stark vom Arbeitsumfeld ab. Für unser Team funktionieren folgende Vorgehensweisen, die aus den Ideen der agilen Softwareentwicklung stammen:

Die Anwenderschnittstelle wird zuerst entworfen. Mit einfachen, funktionsfähigen Prototypen wird die Bedienungsweise der Anwendung erklärt. Programmiert man diese einigermassen sauber, hat man nachher schon den grundlegenden Code, um Templates für die Webanwendung zu bauen.

Wir pflegen eine offene Kommunikationskultur. Kritik wird sofort angebracht und Fehler früh behoben. Ziel ist, die Zeit zwischen Feedback und Release so kurz wie möglich zu halten.

Der Kunde ist immer vor Ort: Die Programmierer sind eingebettet in die Betriebsorganisation. Dadurch sind die Experten für die Geschäftslogik jederzeit ansprechbar. Das spart die Erstellung eines schriftlichen Fachkonzepts und damit tote Dokumentation.

Die technische Dokumentation ist immer aktuell: Die Dokumentation wird mit Markdown erstellt und gemeinsam mit dem Quellcode verwaltet. Dadurch muss man nicht mit ungeeigneten Werkzeugen hantieren.

Man kommt einfach mit fertigen Bausteinen schneller zum Erfolg: Was bereits gut funktioniert, muss man nicht neu schreiben. Bevor man sich irgendwelche kruden Spezifikationen von vorgeblichen User-Interface-Experten antut, verwendet man lieber Komponenten, die bereits funktionieren und begeistern. Sobald man mit dieser Programmierweise zurecht kommt, stellt man schnell fest, dass man den Weg des geringsten Widerstands geht.

Schnell reagieren

Die Open-Source-Szene lebt den Erfolg agiler Methoden vor: Aus einer Keimzelle von einigen wenigen Programmierern baut sich um frühe und häufige Releases schnell eine Community auf. Besondere Merkmale dieser Art von Software sind neben einer hohen Code- und Produktqualität auch eine gute Benutzbarkeit. Die Anwendungen leben geradezu von der Rückmeldung der Anwender.

Die direkte Rückmeldung hatte man auch auf dem Schlachtfeld: Ob eine Waffe oder eine Strategie funktioniert oder nicht, erfährt man sofort und bezahlt meistens einen hohen Preis dafür. Man darf auch nicht vergessen, dass es einer der ersten Informatiker war, der mit neuen und unkonventionellen Ideen die entscheidende Wende im Krieg herbeigeführt hat.

Wer meinen Vergleich mit dem Krieg übertrieben findet, höre im nächsten Projekt genau hin: Begriffe wie kriegsentscheidend, Grabenkämpfe oder Todesmarsch hört man auch in Softwareprojekten, wenn auch nur metaphorisch. Aber kräftezehrende Grabenkämpfe habe ich in Projekten schon genug erlebt. Es ist Zeit für etwas Neues!