Agile Unified Process == Waterfall Process?

[lkbaerenfaenger]

Hallo,

ich habe ein Verständnisproblem: Ich bin bisher davon ausgegangen, dass der Hauptunterschied zwischen traditionellen (z.B. Wasserfall-Prozess) und agilen Entwicklungsprozessen im Folgenden besteht: Während traditionelle Ansätze einmal (zu Beginn des Projekts) Requirements Enginnering betreiben, darauffolgend einmal die Spezifikation implementieren, und dann einmal eine Test- bzw. Auslieferungsphase durchlaufen, zeichnet sich der agile Ansatz dadurch aus, dass etliche Iterationen stattfinden, die jeweils aus den Phasen Requirements Enginnering, Implementation, Testing und Delivery bestehen. Der Vorteil, so habe ich es verstanden, besteht dann darin, dass man flexibel auf Anforderungsänderungen reagieren kann. Es gibt einfach nie den Punkt, an dem die Phase des Requirements Engineering in der Vergangenheit liegt: Die nächste Iteration beginnt wieder damit, und so kann man den geänderten Anforderungen dort einfach Rechnung tragen.

1. Frage: Ist das korrekt so?

Dann wundert mich jedoch, warum sich der "Agile Unified Process", der in Foliensatz 13 auf Folie 27 vorgestellt wird, agil nennt. Denn hier findet eine Machbarkeitsstudie in der Phase 1 (Inception) statt. Darauffolgend werden die kritischen Teile der Software in Phase 2 (Elaboration) implementiert, in Phase 3 (Construction) die weniger kritischen, und, letztlich, in Phase 4 (Transition) wird das ganze ausgeliefert. Was, wenn sich in Phase 3 die Anforderungen ändern? Schade, die Machbarkeitsstudie war in Phase 1 dran, da kann man dann nix machen... Wenn der AUP wirklich agil (i.d.S. wie oben beschrieben) wäre, dann würde doch jede Iteration/jeder Sprint aus den Phasen 1 bis 4 bestehen, oder nicht?

2. Frage: Ist der "Agile Unified Process" eher so etwas wie ein moderner Wasserfall-Prozess?
3. Frage: Ich sehe schon, dass in den Beschreibungen der einzelenen Phasen des AUP immer mal das Wort "iterative" fällt. Aber wie kann etwas iterativ sein, wenn am Anfang eines Projekts die Machbarkeitsstudien durchgeführt werden und am Ende die Auslieferung stattfindet? Iterativ bedeutet doch, dass diese Dinge jeweils am Anfang und am Ende einer Iteration und nicht am Anfang und am Ende eines Projekts gemacht werden...

I am very confused, über Aufklärung würde ich mich sehr freuen!

Vielen Dank im Voraus und liebe Grüße
Lucas

EDIT:
4. Frage: Wo genau besteht der Zusammenhang zwischen Folie 27 und Folie 28(-31) in Foliensatz 13? Auf Folie 27 werden, wie bereits erwähnt, die Phasen des AUP beschrieben, und das ganze wirkt, wie ebenfalls bereits erwähnt, sehr "un-agil". Auf Folie 28(-31) wird AUP visualisiert, und das ganze wirkt auf mich genau so, wie ich mir einen agilen Prozess vorstelle. Nur ist auf der Grafik nichts mehr zu sehen von den zuvor beschriebenen Phasen... Wie passt das zusammen?

[svenamann]

Hallo,

zu Frage 1: Ja, ich denke du hast das prinzipiell richtig verstanden.

zu Frage 2: Der AUP geht davon aus, dass sich die Wichtigkeit der einzelnen Aufgaben im Laufe des Projekts verschiebt. Auch in agilen Projekten werden die Anforderungen mit der Zeit klarer. D.h. währen zu Beginn sehr viel Arbeit in Anforderungsanalyse gesteckt werden muss, wird der nötige Zeitaufwand im Projektverlauf weniger. Damit ist später im Projekt z.B. mehr Zeit für Entwicklungsarbeit und gegen Ende liegt der Fokus auf der Auslieferung. Auch wenn laut der agilen Idee zu jedem Zeitpunkt theoretisch ausgeliefert werden könnte, ist mit dem tatsächlichen Ausliefern i.d.R. noch konkrete Arbeit verbunden (Rechner installieren/konfigurieren, Kundenschulung, ...) der zuvor nicht anfällt. Ich finde diese Grafik veranschaulicht das ganz gut: http://www.ambysoft.com/artwork/lifecycleAgileUP.gif
Ich würde AUP nicht als modernen Wasserfallprozess bezeichnen.

zu Frage 3: Iterativ bedeutet nicht, dass ich jede Iteration das selbe tue. Wie oben beschrieben, ändert sich der Projektfokus mit der Laufzeit ganz von alleine. Dennoch wird in kurzen Etappen gearbeitet, um auf Anforderungsänderungen reagieren zu können. Gegen Projektende ändert sich hoffentlich nichts mehr an der Kernanforderungen der Anwendung, sonst wird das Projekt vermutlich scheitern, egal wie agil der Prozess ist.

zu Frage 4: Ist auch schon beantwortet, denke ich.

Löst das deine Verwirrung?
Gruß,
Sven