Erfahrungsaustausch

Gestern hab' ich mich mit einem Bekannten unterhalten, der Web-Projekte leitet, eigentlich aber aus der Ecke der Software Entwickler kommt. Die Probleme, Erkenntnisse und Eskalationen in Bezug auf Zeit und Budget in seinen Projekten lassen mich nur Schmunzeln ... "go agile" denke ich und versuche ihn davon zu überzeugen.

Ich:

Wie sehen denn die Rahmenbedingungen bei den Projekte aus?

Er:

Zeit, Budget und Ressourcen werden vorgeben. Die technische Lösung hat damit bereits Nebenbedingungen, die sich bei der Realisierung zeigen.

Ich:

Du hast also keinen Einfluss auf die Resourcenverteilung in deinen Projekten. Wie hoch ist denn die Fluktuation während des Projekts?

Er:

Ja, das ist immer problematisch. Die Ressourcenzuteilung ist nicht garantiert. Es werden oft Leute abgezogen, für die man nicht immer einen adäquaten Ersatz bekommt. Sobald jemand als freie Ressourcen ausgemacht wird, bekommt man wieder ein neues Teammitglied.

Ich:

Wie erfolgreich sind den diese Projekte?

Er:

Sehr erfolgreich. Wir haben nur selten Budget oder Zeitüberschreitungen bis zum Projektabschluss.

Ok, seltsam. Noch ein paar Fragen und ich war am "Kern". Er eröffnet mir, dass bei vielen Projekten dann nach dem Abschluss erst die grosse Überraschung kommt. Der Kunde hat dann oft noch Change Requests, die allerdings eher Bugs sind und möchte nachträglich die Spezifikation ändern. Da man den Kunden halten möchte, arbeitet man auch nach Projektabschluss noch am Projekt, ohne Aufwandsverrechnung und oft nur mit halbem Team. Was am Ende dann rauskommt, möchte keiner mehr Warten, meint er ...

Nochmal: "go agile"
Ich würde mal unterstellen, dass man das bei agilem Vorgehen besser hinbekommt!

Was heisst agiles Vorgehen?

Nach dem agilen Manifest gilt das Prinzip, dass man dem Kunden in regelmässigen Intervallen funktionsfähige, getestet, dokumentierte und brauchbare Artefakte liefert, die einen Mehrwert darstellen.

Wie kommt man von einem klassischen Wasserfall zum agilen Projekt?
Ein Praxisbericht: Schritt 1: man macht den Wasserfall zunächst iterativ.

Bei einem interativen Wasserfall werden pro Iteration Artefakte erarbeitet, die in der kommenden Iteration weiterverarbeitet oder verfeinert werden (Bild oben). Damit bleiben alle Nachteile von phasen- orientiertem Projektvorgehen erhalten: Abkapseln von Anaytikern, Kunden, Testern und Entwicklern sowie Behinderung der direkten Kommunikation aller Beteiligten. (A=Analyse,D=Design,P=Produktion,T=Test)

Da man mit dem iterativen Wasserfall jedoch keine funtionstüchtigen Artefakte mit einem Mehrwert für den Kunden liefert, kommt man zwangsläufig zum Schritt 2: der iterative Mini-Wasserfall (Bild unten).

Um dem agilen Manifest gerecht zu werden und die klassische Vorgehensweise beizubehalten, macht man alle Phasen pro Iteration.
Auch hier gewinnt man nicht viel, denn erfahrungsgemäss ist die Zeit am Ende einer Iteration sehr knapp und Testing fast unmöglich. Dazu kommt, dass die Teammitglieder so noch immer entkoppelt arbeiten und wichtige Kommunikation ausbleibt.

Untersuchen Sie genau Ihre Vorgehensweise. Finden Sie sich teilweise in diesen Aussagen wieder, dann haben Sie kein agiles Vorgehen!