Nach der Wasserfallmethode wird seit annähernd 40 Jahren Software entwickelt. Agile Softwareentwicklung befindet sich dagegen noch im Teen-ager-Alter, denn das "Agile Manifesto" wurde im Februar 2001 veröffentlicht. Aber die Diskussionen über Softwareentwicklungsmethoden auf die Formel "Alt oder Modern" zu beschränken ist genauso ergebnislos wie der ewige Disput, was kulturell wertvoller ist, E- oder Rock-Musik. Im Mittelpunkt der Diskussion über Softwareentwicklung sollte immer die inhaltliche Auseinandersetzung um erfahrene Vor- und Nachteile von Methoden in diesem Prozess stehen.

Nah an der Projektpraxis

Die Verfasser des Manifests für agile Softwareentwicklung haben nicht in einem stillen Kämmerlein etwas grundsätzlich Neues erfunden. Es waren ihre langjährigen Projekterfahrungen, die sie dazu führten, ein Framework wie Scrum für die Softwareentwicklung zu definieren, das der Projektpraxis folgt und dem "Schatz an Kreativität" der Entwickler Rechnung trägt.

In der Vergangenheit führte eine kritische Auseinandersetzung über Projektverlauf und Projektergebnis häufig zu dem Schluss, dass die linearen Phasenmodelle - dazu gehört der Wasserfall - nicht konsequent befolgt wurden. Leider mit dem Ergebnis, dass noch mehr Formalismus die Entwickler und Auftraggeber in ihren Tätigkeiten einschränkte. Lange Zeit wurde die Methode an sich nicht in Frage gestellt. Erst durch das Agile Manifesto hat eine andere Kultur und Denkweise der Softwareentwicklung eine Öffentlichkeit erhalten.

Kritik am Wasserfall

Zu den wesentlichen inhaltlichen Kritikpunkten am Wasserfallmodell gehören:

• Klar voneinander abgegrenzte Phasen sind unrealistisch und lassen sich nicht einhalten. Der Übergang zwischen den Phasen ist in Wirklichkeit fließend: Teile eines Systems können sich noch in der Planung befinden, während andere schon in der Ausführung oder im Gebrauch sind. Anforderungen können teilweise nur vorab ermittelt werden und ändern sich ständig.

• Einzelne Phasen laufen in der Theorie nacheinander ab, in der Praxis sind jedoch Rückschritte unvermeidlich. Fehler werden unter Umständen erst spät erkannt und müssen mit erheblichem Aufwand behoben werden.

• Je allgemeiner ein Schema ist, auf desto mehr Projekte ist es anwendbar, aber es sind auch weniger Informationen in ihm enthalten. Je konkreter beziehungsweise detaillierter ein Schema ist, desto festgelegter ist es, und auf desto weniger Projekte ist es anzuwenden.

• Der Lernprozess der Beteiligten bei der Entwicklung wird ignoriert.

In der Diskussion um Softwareentwicklung geht es oft darum, wie man den gesamten Prozess als Kommunikations- und Lernprozess aller Beteiligten betrachten kann. Ausgangspunkt dabei ist, dass der Auftraggeber (Kunde) und der Softwareentwickler im Verlauf der Entwicklung einen Lernprozess absolvieren. Beide Seiten werden zum Ende eines Projekts mehr wissen als zu Beginn.

Agile Softwareentwicklung unterstützt diesen Lernprozess und gibt die Möglichkeit, Lernkurven sehr schnell in laufende Projekte einfließen zu lassen. Das ist bei einem Wasserfallmodell nicht beziehungsweise nur in einem geringen Umfang möglich, und damit wird dieses Problem zum Kernproblem für den Wasserfall. Der Ansatz des Wasserfallmodells, erst die Dokumentation und dann die Software zu erstellen, lässt sich theoretisch umsetzen, ist aber in der Praxis mit vielen Problemen verbunden. Gelungene lange Projekte mit komplexen Inhalten sind davon geprägt, dass sie auf Erkenntnisgewinn der Beteiligten (aber auch auf Marktsituationen) beruhen und so zu einem befriedigenden Ergebnis führen.

Änderungen sind Entwickleralltag

Durch kurze iterative Entwicklungszyklen (zum Beispiel Sprints in Scrum) sind Auftraggeber und -nehmer in der Lage, Anpassungen und Änderungen schnell vorzunehmen, so dass am Ende tatsächlich das herauskommt, was sich der Kunde wünscht.

Wenn ein Flug von der Erde zum Mond geplant wird, dann gibt es auf der Reise keine Chance, einen Umweg über den Mars zu machen. Im Projektalltag der irdischen Kunden und Entwickler sind diese Umwege aber gelebte Praxis. Ein Wasserfallmodell kann dieser Praxis nicht standhalten, mit dem Ergebnis:

• Kosten und/oder Zeit werden überschritten;

• die Qualität leidet. Häufig sind es die Entwickler, die leiden, weil sie Code abliefern müssen, der nicht ihren Qualitätsansprüchen entspricht;

• die am Anfang erstellte Dokumentation entspricht nicht dem Ergebnis und wird aus Zeitmangel auch nicht angepasst;

• Tests werden nur unzureichend vorgenommen, manche entfallen ganz;

• und schließlich: "Abschluss und Akzeptanz eines so ablaufenden Projekts sind oft schmerzlich, denn jeder hat das Mögliche getan, aber die Erwartungen von niemandem wurden erfüllt" - (Zitat aus "Warum der Wasserfall unterschätzt wird", CW 36/10, Seite 28).

Aus diesen Gründen kann die Wasserfallmethode für überschaubare, nicht komplexe Anforderungen eine Lösung sein. Was darüber hinausgeht, wird in der Praxis von den beschriebenen Problemen begleitet sein. Beschriebene Prüfprozesse, wie in linearen Modellen üblich, sind eben nur "beschriebene" Prüfprozesse, und die Gefahr, dass sich die Analysten irren, ist wesentlich größer als ein erstellter Prototyp, der sich prüfen und damit auch testen lässt.

Dokumentation oder Papierfabrik?

Ein Kritikpunkt bei der Gegenüberstellung von linearen Phasenmodellen und der agilen Entwicklung ist die Frage nach Dokumentationen. Leider wird häufig der Eindruck vermittelt, dass im Wasserfall gut und ausführlich dokumentiert wird, in der agilen Welt die Dokumentation aber aus einer Sammlung von losen Blättern besteht.

Während beim Wasserfallmodell eine Menge an überflüssigen und zum Schluss nicht mehr verwertbaren Dokumenten entsteht, geht der agile Prozess von einer dokumentengestützten Modellierung aus. Der Entwicklungsprozess findet mit und an Dokumenten statt. Das bedeutet, dass die Beteiligten nur solche Dokumente erstellen und bewerten, die insgesamt das Produkt (System) ausmachen. Jede Aktivität soll also in diesem Sinn zielgerichtet sein, und jedes Dokument soll einen Beitrag zum Produkt liefern. Dafür müssen die Dokumente bestimmte Vor aussetzungen in fachlicher und technischer Hinsicht erfüllen.

Ziel ist es, weitgehend auf zusätzliche Dokumente zu verzichten. Je weniger Dokumente die Entwickler für das Projekt-Management erstellen müssen, desto intensiver können sie sich dem Entwicklungsprozess widmen. Das bedeutet aber nicht, wie so häufig unterstellt, dass auf Planungsdokumente verzichtet wird.

Durch die permanente Einbeziehung der auftraggebenden Seite, zum Beispiel durch die Rolle des Product Owner in Scrum, kommt es zu einem ständigen Kommunikations- und Lernprozess. Der Auftraggeber kann stets neue Erkenntnisse einbringen und gibt auch den Entwicklern die Möglichkeit, aus der oft hinderlichen technikzentrierten Sicht herauszukommen.

Eine durchgehende Transparenz ermöglicht ein wesentlich effizienteres Anforderungs-Management und eine stetige Kontrolle von Kosten und Terminen. Diese Transparenz sorgt auch für ein kontinuierliches Überprüfen und Anpassen (Inspect und Adapt) der zu erstellenden Software und der Entwicklungsprozesse. Agile Softwareentwicklung ist auch als kontinuierlicher Verbesserungsprozess zu verstehen.

Agile Softwareentwicklung ist ein Paradigmenwechsel und keine Auseinandersetzung zwischen Alt und Modern. Sie verlangt eine offene Kommunikation, in der Fehler zugelassen werden, um sie als Lernfaktor und Chance für den weiteren Verlauf anzusehen. Agile Softwareentwicklung erfordert ein hohes Maß an Disziplin und Eigenverantwortung aller am Projekt beteiligten Personen.

Agile Softwareentwicklung wird heute in vielen größeren Unternehmen praktiziert, etwa bei SAP oder IBM. Es wäre ein Trugschluss, sie nur in kleineren und mittleren Unternehmen zuzulassen. Mit agiler Softwareentwicklung besteht gerade in langen Projekten die Chance, am Ende kein veraltetes Produkt zu erhalten. (ue)

*Norbert Grosz ist Abteilungsleiter Anwendungsentwicklung, Architektur und Vertriebssysteme beim Versicherungsunternehmen Deutscher Ring in Hamburg.