Zuerst die Definition aus Wikipedia: «Ein Wasserfallmodell ist ein lineares (nicht iteratives) Vorgehensmodell, das insbesondere für die Softwareentwicklung verwendet wird und das in aufeinander folgenden Projektphasen organisiert ist. Dabei gehen die Phasenergebnisse wie bei einem Wasserfall immer als bindende Vorgaben für die nächsttiefere Phase ein.»
Das Wasserfallmodell und seine speziellen Tücken
Nun muss ich ehrlich gestehen, dass ich noch nie ein Software-Projekt erlebt habe, das wirklich exakt nach diesem Modell ablief. Mein Erfahrungsschatz bewegt sich in Projekten in der Finanzindustrie (Datenverteilsysteme), in der Maschinenindustrie (Prozessleitsysteme) und Software-Produktentwicklung. Der Hauptnachteil dieses Modells liegt in der Sequenzialisierung und ist nicht praxisgerecht. Bis die Stakeholder alle Anforderungen eines Gesamtsystems abgestimmt haben, sind die ersten schon wieder veraltet.
Das Vorgehen war in den meisten Fällen wie folgt: Wir haben das Gesamtsystem im Groben und dann die Detailanforderungen losgelöst definiert. Die Phasen waren nicht starr synchronisiert. Nach der Grobkonzeption wurde relativ schnell das Gesamtsystem im Gerüst entwickelt und danach begonnen die Detailfunktionalitäten zu implementieren und laufend mit den Stakeholdern zu validieren. Ich habe Projekte gesehen, die wirklich dieses strikte Modell befolgt und zuerst alle Anforderungen gesammelt haben, damit ja nichts vergessen ging, und so entstand ein System, das zu teuer und im Moment der Fertigstellung schon veraltet war. Unser Ziel war es, ein System in Produktion zu bringen, das die minimalen Anforderungen erfüllte und der Anwender beginnen konnte, den Nutzen daraus zu ziehen.
Auf mögliche Ausbauten achten
Die grossen Fallstricke an dieser vereinfachten iterativen Methode war: dass man aus der Sicht des Kunden und Management nie fertig wurde, das System nicht ausbaufähig entwarf und implementierte, dies zu nicht verständlichen grossen Aufwendungen bei der Folgeiteration führte und der ReleaseZeitpunkt immer ein Kompromiss war. Aus diesen Gründen haben sich folgerichtig die agilen Methoden entwickelt, welche immer noch Elemente aus dem Wasserfall enthalten.
Die Anforderung des Stakeholders (Kunden, Nutzer) sollte verstanden und dokumentiert sein. Man sollte immer ein Auge auf mögliche Ausbauten haben. Das System sollte abwärtskompatibel sein und allenfalls angepasste persistente Datenstrukturen automatisch migrieren. Als letztes sollte derselbe Code immer von einem Team betreut werden. Dies führt automatisch zu einem wartbaren Code und weniger Abhängigkeiten von Einzelpersonen.
Agile Methoden und Planbarkeit
Es gibt im agilen Umfeld zwei globale teils provokative Standardaussagen: Man kann nicht langfristig planen, und das Scrumteam bestimmt, was gebaut wird. Ich werde mich hier an die Methode SAFe Scaled Agile Framework www.scaledagileframework.com/ halten. Es scheint mir beim Lesen die richtigen Elemente zu haben und diese sind sinnvoll und praxisbezogen beschrieben. Ich habe nicht das Wissen dieses Framework gegenüber anderen zu positionieren. Der erste grosse Unterschied zum Wasserfallmodell ist, dass man nicht mehr Projektorganisationen bildet, bei welcher die Entwickler, Business-Analysten und Architekten für die Dauer des Projekts dem Projektleiter zuordnet werden, sondern dass man fixe Teams (ca. zehn Personen) bildet, welche Aufgaben zugewiesen bekommen.
Das Team bestimmt situativ, wer die Bearbeitung einer Aufgabe oder einen Teil davon übernimmt. Auch in diesem Modell kann es Platz für Projekte im klassischen Sinne (Scope, Kosten und Timeline) geben, mit dem Projektleiter, welcher jetzt an die entsprechenden Teams gelangen muss und die Aufgaben in den Arbeitsvorrat des Teams oder auch Backlog genannt, einreihen muss. Der grosse Unterschied besteht darin, dass das Team Backlog-Einträge von verschiedenen Stakeholdern, wie Projektleitern, Produktmanagement und Supportverantwortlichen, bekommen kann. Die Priorisierung der Team-Backlog-Einträge geschieht zusammen mit allen Stakeholdern anhand des grössten Nutzens.
Anforderungen und Kapazitäten
Diese Priorisierung sollte je nach Grösse des Vorhabens, Produkts oder der Firma auf verschiedenen Ebenen erfolgen. In einer Jahresplanung wird strategisch bestimmt, wie viele Ressourcen will ich mir leisten und wo will ich diese einsetzen (Kundenvorhaben, Produkterweiterungen oder Wartung). In der Quartalsplanung werden alle bestehenden und neuen Initiativen beurteilt. In dieser Planungsphase sollten zwei Aspekte betrachtet werden. Rückschau: Was wurde im letzten Quartal geliefert und welchen Nutzen erzeugt das Ergebnis. Planung: Welche Lieferungen mit entsprechendem Nutzen sind im neuen Quartal geplant. In der Quartalsplanung sollten alle Backlog-Einträge eindeutig priorisiert sein. Damit sollte transparent abschätzbar sein, wie viele Anforderungen gegenüber der verfügbaren Kapazität lieferbar sind.
Man darf nicht davon ausgehen, dass mit 100 % Kapazität im Quartal 100 % der Anforderung geliefert wird, sonst gibt es bereits nach dem ersten taktischen Stakeholder Meeting die ersten Eskalationen. Man sollte davon ausgehen, dass ein Team ca. 70 % des Backlogs in der nächsten Phase abarbeiten kann. Wenn nichts dazwischen kommt, kann es sogar höher gehen. Sollte es aber kurzfristige Opportunitäten ergeben wie z.B. dass ein Teammitglied den Verkauf beim Kundenworkshop unterstützt, ein anderes Teammitglied für eine Kundenberatung eingeteilt wird oder es tritt ein Krankheitsfall ein, muss man Einträge aus dem Backlog geordnet in die nächste Phase verschieben.
Langfristige Planung im agilen Umfeld
Aus diesen Erläuterungen sieht man, dass die eingangs erwähnten Standardaussagen widerlegt sind. Eine langfristige Planung (Jahres-, Quartal-, zwei Wochen-Sicht) ist auch im agilen Umfeld möglich. Der Projektleiter muss jedoch immer wieder beweisen, dass seine Anforderungen nach wie vor einen grösseren Nutzen gegenüber seiner Konkurrenz (andere Projekte, Produktmanageranforderungen oder Supportanfragen) erzeugen. Dadurch wird verhindert, dass das Projektbudget sinnlos aufgebraucht wird. In jeder Planungszeremonie sind die Repräsentanten des Teams und der Auftraggeber anwesend und entscheiden gemeinsam über das Ranking. Das Team kann dann selbst entscheiden, wer welches Arbeitspaket abarbeitet.
Vorbedingungen für ein agiles Umfeld
Bis jetzt wurde nur erläutert, dass diese Arbeitspakete priorisiert und abgearbeitet werden. Um in einem solchen starren, zeitlich synchronisierten Umfeld effizient arbeiten zu
können, sind ein paar wichtige Grundsätze zu befolgen. Die Arbeitspakete – sprich das zu erwartende Ergebnis und deren Abnahmebedingung – müssen klar definiert sein. Der Nutzen muss quantifiziert werden können, um eine Priorisierung vornehmen zu können. Diese Arbeiten müssen klar vor den jeweiligen Entscheidungssitzungen abgeschlossen sein. Es ist wie mit dem öffentlichen Verkehrsmittel, ist dieses abgefahren, muss ich auf das nächste warten. Hier sind die Stakeholder, die ein Arbeitsergebnis erwarten, gefordert, diese Vorarbeiten voranzutreiben und mit den agilen Entwicklungsteams abzusprechen.
Eine grosse Herausforderung des Modells besteht darin, ein Priorisierungsmodell zu etablieren, das verschiedene Anforderungen (funktionale und nichtfunktionale; ertragswirksame oder kosteneinsparende Ergebnisse) miteinander vergleicht. Das agile Arbeitsmodell eignet sich am besten, wenn man das Gesamtergebnis kontinuierlich weiterentwickeln will. Im Minimum sollte die Organisation alle Prozesse in mehreren Zyklen durchlaufen können, um die nötigen Erfahrungen und deren Effizienzgewinne anwenden zu können.
Vom Saulus zum Paulus?
Wie schon eingangs erwähnt, wurde das Wasserfallmodell zur Dinosaurierzeit der IT, in der es noch allmächtige Hosts gab, definiert. Wir sind heute in der Epoche angelangt, in der PCs, Smartphones oder Tablets mit neuen Funktionalitäten automatisch aktualisiert werden. Dies erfordert auch agile Entwicklungsmethoden. Je mehr ich mich in diese Welt einlese, finde ich interessante Konzepte, die etwas tiefer gehen als Beraterpräsentationen. Daher ist es wert, ein Buch über 300 Seiten zu lesen, in dem ein Konzept konsistent beschrieben ist, anstatt im Internet nach Textfragmenten zu suchen. Bin ich etwa doch noch ein Wasserfall-Dinosaurier?
Infoservice
Thomas Hauser
Langackerweg 10, 5303 Würenlingen
Tel. 079 573 20 27, thomas.hauser@fael.ch
