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:

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:

Es bedarf also in meinen Augen mehr als ein paar Regeln à la XP, um diesen Herausforderungen gewachsen zu sein, z.B.: 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...