Länge der Iterationen
Wir haben also festgestellt, dass Iterationen zeitlich beschränkt, d. h. timeboxed, sind. Welche Dauer sollte eine solche Iteration demnach haben? In den Agile-Prinzipien wurde dies bereits erwähnt. Erinnern Sie sich?
Ausgehend von diesen Prinzipien sollte eine Iteration maximal zwei Monate dauern. Bei Scrum beträgt das Maximum einen Monat.
Diese Zeit reicht aus, um einige neue Funktionen zu entwickeln und diese Kunden und Benutzern vorzustellen, um Feedback zu erzeugen. Ist die Dauer der Timebox zu lang, besteht die Gefahr, dass wir am Ende zu wenig Feedback haben.
1.7.3 Gleiche oder unterschiedliche Dauer für Iterationen?
Was meinen Sie? Ist es besser, wenn alle Iterationen die gleiche Dauer haben oder sollte die Dauer flexibel sein?
Iterationen von gleicher Dauer sind disziplinierter und haben den Vorteil, dass man sich nicht ständig für eine neue Dauer entscheiden muss.
Bei Scrum müssen alle Iterationen die gleiche Länge haben, wobei diese Länge flexibel angepasst werden kann. Sie können ein Projekt beispielsweise mit zweiwöchigen Sprints (so nennt man bei Scrum eine Iteration) starten. Stellen Sie nach einer Weile fest, dass Sie in zwei Wochen nicht genügend Funktionen erstellen können, dann können Sie Ihre Sprints künftig auf drei Wochen verlängern. Das geht! Was bei Scrum dagegen nicht geht ist, dass Sie vor jedem Sprint fragen: „Okay, wie lange ist unser Sprint dieses Mal?“.
Nicht alle Methoden gehen hier gleich vor. Bei DSDM, einer anderen agilen Methode, planen Sie die Dauer der Timeboxes basierend auf ihrem Umfang (bei DSDM werden Iterationen als Timeboxes bezeichnet).
1.7.4 Was ist, wenn einige Funktionen nicht fertig werden?
Wir wählen also ein paar Funktionen für eine zeitlich beschränkte (timeboxed) Iteration aus. Was passiert nun, wenn wir es nicht schaffen, bis zum Ende der Iteration alles fertigzustellen?
Das ist überhaupt kein Problem! Unser Ziel ist die Erstellung eines Software-Inkrements, um Feedback für unsere Anpassungen zu erzeugen und später, bei der Einführung in die Produktivumgebung, maximale Wertschöpfung zu ermöglichen. Unser Ziel ist es NICHT, möglichst viele Funktionen zu entwickeln.
Diese Aussage stützt sich auf drei Prinzipien von Agile. Wissen Sie welche?
Antwort: 1, 7, 10
1.7.5 Was passiert in den Iterationen?
Wie sollte Ihrer Meinung nach der Entwicklungsprozess in den einzelnen Iterationen ablaufen? Hier gibt es zwei Möglichkeiten:
Entweder Sie nehmen, wie auf der linken Seite dargestellt, alle Funktionen einer Iteration als Gesamtheit und führen für diese Gesamtheit einen Entwicklungsprozess nach dem anderen durch (in einer Art Mini-Wasserfall).
Oder Sie konzentrieren sich auf eine oder mehrere Funktionen und führen für diese Funktion(en), wie auf der rechten Seite dargestellt, alle Entwicklungsprozesse durch. Dies ist die bessere Option. Können Sie erklären, warum?
Da wir uns für zeitlich beschränkte (timeboxed) Iterationen entschieden haben, besteht immer die Gefahr, dass wir nicht mit allem fertig werden. In einem solchen Fall hätten Sie bei der Option mit dem Mini-Wasserfall keine einzige neue Funktion vollständig vorliegen und könnten somit auch kein Feedback erzeugen. Bei der anderen Herangehensweise dagegen, haben Sie immer ein paar Funktionen, die Sie Ihrem Kunden präsentieren und für die nächste Iteration anpassen können.
1.7.6 Empowerment1
Einige Entscheidungen werden von Führungskräften, andere vom Projektteam getroffen. In welchem Verhältnis dies geschieht wird teilweise durch das Vorgehen im Rahmen des Entwicklungsprojekts vorgegeben.
Wann müssen die meisten nichttechnischen Entscheidungen getroffen werden?
Die meisten nicht-technischen Entscheidungen fallen in der Analysephase, in der wir versuchen, die Anforderungen festzulegen, und in der finalen Testphase, in der wir prüfen, ob die Funktionen unsere Anforderungen erfüllen. Blättern Sie bitte noch einmal an den Anfang des Kapitels und sehen Sie sich noch einmal an, wie sich die Entscheidungen bei prognostizierten und adaptiven Ansätzen verteilen.
Im prognostizierten Lebenszyklus konzentrieren sich viele Entscheidungen auf den Anfang und das Ende des Lebenszyklus, so dass wir die meisten Entscheidungen den Führungskräften überlassen können. Wie sieht es aber bei adaptiven Systemen aus? Bei diesen Systemen müssen Entscheidungen über den gesamten Lebenszyklus verteilt, fast täglich getroffen werden. Würde man auch hier die Entscheidungen immer an die Führungskräfte eskalieren, würde das Projekt wahrscheinlich niemals fertig werden.
Deshalb braucht man bei adaptiven Lebenszyklen motivierte, zur Selbstverantwortung und Selbstbestimmung ermächtigte und befähigte Teammitglieder, die die meisten Entscheidungen selbst treffen können und diese nicht an Führungskräfte eskalieren müssen.
■ 1.8 IST AGILE NUR ETWAS FÜR IT-PROJEKTE?
Wie Sie bemerkt haben, gehe ich davon aus, dass alle agilen Projekte im Bereich der IT-Entwicklung angesiedelt sind. Sie haben auch festgestellt, dass das Agile Manifest und die Prinzipien von Agile von Software sprechen. Beschränken sich agile Methoden demnach auf Projekte in der IT-Entwicklung?
Meine Antwort auf diese Frage lautet wie folgt:
■ Ich persönlich glaube, dass Agile sich nicht für alle Projekte eignet. Diese Meinung wird nicht von allen geteilt. Es gibt Experten (in der Regel Experten, die keine Erfahrung mit anderen Projekttypen haben), die der Meinung sind, Agile eigne sich für alle Projekttypen.
■ Agile lässt sich mit Abstand am besten in der IT-Entwicklung anwenden.
■ Es mag möglich sein, Agile bei einigen anderen Projekttypen anzuwenden, aber meiner Erfahrung nach ist dies mit einigen Schwierigkeiten verbunden. Möglicherweise lassen sich jedoch bei einem Großprojekt, vorausgesetzt die Rahmenbedingungen stimmen, einige Teilprojekte erfolgreich mit Agile bearbeiten.
■ Was ich bisher gesagt habe, betrifft Projekte. Wie aber verhält es sich bei Programmen2? Programme sollten generell und ohne Ausnahme mit adaptiven Methoden ausgeführt werden, wobei sich die adaptiven Methoden, die man auf ein Programm anwenden kann, von den adaptiven Methoden unterscheiden, die man für Projekte verwendet (z. B. Scrum).
Diese Ausführungen sind etwas für die Praxis und damit Sie etwas fürs Leben lernen. Wird Ihnen diese Frage jedoch in einer Prüfung zum Thema Agile gestellt, dann lautet die richtige Antwort: „Agile (oder die jeweilige agile Methode, die Gegenstand der Prüfung ist) ist nicht auf IT-Projekte beschränkt“,
