Wer hat Angst vorm bösen Wasserfall?

08.09.2006 Permalink

Geht es in der Praxis um den Software-Prozess, begegnet mir gelegentlich dieser Ausspruch:
Uh oh, das klingt nach Wasserfall, darüber sind wir aber hinweg. Das machen wir so nicht, wir arbeiten agil.
Was in den nächsten Minuten des Gesprächs meist fehlt sind Antworten z.B. auf die Fragen: Wie konkret gehen wir vor? Und: Werden wir damit den individuellen Umständen gerecht? Es kommt mir vor, als läge häufig kein konkreter konstruktiver Weg im Kopf vor, sondern nur die Angst, dem bösen alten Wasserfall zu "verfallen".

Das Wasserfall-Modell ist aus guten Gründen kritisiert worden. Man kann dieses im Kern richtige Vorgehen aber nicht durch irgendetwas Unkonkretes, Esoterisches oder Mystisches ersetzen. Da muss man schon genauer werden.

Zur Erinnerung, die wichtigsten Kritikpunkte sind:

Der Software-Prozess ist kein großer, langer, sauber vorgezeichneter Marsch, an dessen Ende alle Wünsche der Stakeholder erfüllt sind. Es ist selten bekannt, wohin die Reise gehen muss. Deshalb kann man den endgültigen Umfang nicht up-front spezifizieren.
Kommunikation, Feedback-Loops und Änderungen über Phasen hinweg sind erforderlich. Dies zu verbieten, wird dem Wasserfall-Modell gerne unterstellt.
Sichtbare, in Software gegossene Ergebnisse, die sich nicht schön reden lassen, werden erst dann geliefert, wenn die Show vorbei ist. Das ist zu spät, um zu reagieren. Wer all sein Geld in genau eine Kette Requirements-Analysis-Design-Implementation-Test steckt, setzt alles auf eine Karte und kann dabei viel verlieren.

Ok, soweit so gut. Also kein Wasserfall, keine Planung, keine Baselines, kein Design, keine Reviews, keine Phasen, keine Übergaben und Abnahmen, alles schön im Fluß, hoch iterativ-inkrementell, auf dass der Kunde das Maximum an Funktionalität für sein Geld bekommt... ist ja klar, alles weglassen, was am Ende nicht im Betrieb Bits durch die Gegend schiebt, ist bestimmt der billigste und schnellste Weg, Software zu bauen.

Naiv, denn: Was man durch ersatzloses(!) Streichen des Wasserfall-Modells tatsächlich erhält, ist Code-and-Fix -- ein "Modell", das noch viel älter ist als der böse Wasserfall, und da wird's dann richtig teuer, weil nicht zu steuern und unvorhersehbar.

Worin besteht dann der Ersatz? Er besteht aus Planung, Baselines, Design, Reviews, Phasen, Übergaben und Abnahmen. Dazu kommen aber mit besonderem Gewicht Risiko- und Change-Management, intensive Kommunikation und ein Controlling, das uns wirklich zeigt, wo wir stehen.

Aha... Moment. Klingt aber sehr schwerfällig, etwas piefig, sogar direkt unagil. Smells like...

Bevor sich der Diskurs im Kreis bewegt, hier ein paar der schwierigen Umstände, unter denen komplexe Projekte bearbeitet werden:

Projekte sind oft mehrere zehn Mitarbeiter groß, die nicht alle hoch motiviert und top qualifiziert sind. Mitarbeiter wechseln, sie verlassen das Projekt, neue kommen hinzu. Arbeitsprozesse sind selten von Anfang an eingespielt.
Das Software-Projekt agiert nicht im luftleeren Raum, es gibt z.B. mit ihm zu koordinierende Aktivitäten wie Marketing, Anwenderschulungen, integrative Tests mit Umsystemen, Einrichtung von Betriebskapazitäten und Roll-out Planung. Die zu einem Zeitpunkt X zur Verfügung stehende Funktionalität darf deshalb nicht einfach irgendein Maximum an möglicher Funktionalität sein, sondern muss längere Zeit im Voraus weitgehend festgelegt sein und mit hinreichender Qualität zur Verfügung gestellt werden.
Es gibt einen Haufen Politik zwischen Stakeholdern, Abteilungen und auch Dienstleistern. Projekte werden leicht dazwischen zerrieben und bedürfen eines gewissen Schutzes.
Die Informationen über die Kennzahlen muss über viele Management- Ebenen konsistent und verständlich sein. Mit Aussagen wie "das Team ist hochmotiviert und wird das maximal mögliche erreichen" wird sich keiner zufrieden geben.
Der Strom an Änderungswünschen versiegt nicht. Wird er ungebremst auf die Projektmitarbeiter gelassen, wird niemals irgendwas brauchbares fertig werden.
Qualität wird viel zu selten auf Anhieb produziert. Es gibt unter Mitarbeitern ebenso erfreuliche Ausnahmen wie erschreckende Bestätigungen dieser Regel. Das Projekt braucht Fangnetze, um mindere Qualität möglichst früh zu erkennen.
Und natürlich wie oben schon erwähnt: niemand weiß zu Beginn eines Projekts, was der "richtige" Umfang ist. Um trotzdem ein brauchbares System zu erhalten, braucht man viele kleine Richtungsänderungen. Das übrigens ist ein Kernpunkt agiler Prozesse.

Es bedarf also in meinen Augen mehr als ein paar Regeln à la XP, um diesen Herausforderungen gewachsen zu sein, z.B.:

Risiko-Management erfasst die berechtigten Sorgen und Bedenken der Mitarbeiter aus dem Projekt und aus seiner Umgebung und geht durch konkrete Maßnahmen mit Bedrohungen um. Viele "Neuerungen" mit dem Label "Agil" sind nichts anderes als bewährte Risikobekämpfungsstrategien.
Kleine Releases, je nach Projektgröße zwischen zwei Wochen und vier Monaten geben häufige Gelegenheit zur Kurskorrektur, schaffen eine Messdatenbasis zur besseren Vorhersagbarkeit und erlauben den Menschen, miteinander funktionierende Abläufe zu üben und zu verbessern. Und die lassen sich klassisch durchplanen.
Phasen wie Konzeption-Entwicklung-Test sind ein einfaches Gerüst, dass der menschlichen Arbeitsweise entspricht: man nimmt sich was vor, dann führt man das durch, und dann vergleicht man und bessert nach. Wer ständig(!) seine Ziele ändert, kann sie nicht erreichen. Während eines Releases darf es kein Moving-Target geben.
Planung, Baselines und Change-Management sichern ab, dass sich der Umfang eines Release kontrolliert verändert: Änderungen ja, aber eben nicht kostenlos, stattdessen wohl organisiert und mit vorhersagbaren Konsequenzen.
Qualitätskontrollen z.B. durch Reviews direkt nach dem gemeldeten Abschluss von Arbeitspaketen geben dem "Ich bin fertig." eine ganz andere Aussagekraft. Will man die Anzahl der Software-Defekte signifikant senken, dann sind Inspektionen der wirtschaftlichste Weg dahin.
Design nach fundamentalen und messbaren Prinzipien sichert Verständlichkeit, Robustheit, Testbarkeit und Änderbarkeit und kann erheblich dazu beitragen, dass späte Änderungswünsche preiswert durchführbar sind. Im übrigen benötigt man (Grob-)Design, um sinnvoll schätz- und durchführbare Entwicklungsaufgaben aus den zu realisierenden Features abzuleiten.
Controlling und Software-Metriken bieten uns die Möglichkeit, unser Tun in Zahlen zu fassen, Auffälligkeiten früher zu entdecken, um sie zu untersuchen, und für die Zukunft bessere Vorhersagen zu machen.

Ich maße mir nicht an, damit alles benannt zu haben, die Liste ließe sich fortsetzen. Es sind wesentliche Beispiele, die zeigen, dass der Hinweis auf eine einzelne agile Methode nicht reicht, um den Schwierigkeiten angemessen gegenüber zu treten. Vielmehr sollten wir den gesamten Wissenskanon des Software- Engineering einsetzen, um den individuellen Projektproblemen Herr zu werden. Dieses Wissen ist in 'zig lesenswerten Büchern dokumentiert, man muss es ernsthaft anwenden. Dann wirkt es auch.

Wer nun einen Überblick über die zehn Knowledge-Areas verlangt, sollte den Guide to Software-Egineering Body of Knowledge konsultieren. Nicht erschrecken, wenn man vieles liest, das man aus der Praxis nicht kennt. Das scheint mir ein Teil unseres Problems zu sein...