Agile Scrum Handbuch. Frank Turley

Agile Scrum Handbuch - Frank Turley


Скачать книгу
müssen akzeptieren, dass unsere Arbeitsweise nicht perfekt ist, haben aber die Möglichkeit, sie schrittweise zu verbessern. Und bitte, nehmen Sie sich hier kein Beispiel an der Verbesserung des Agilen Manifests oder der Prinzipien von Agile. Lassen Sie in diesem Fall ausnahmsweise die Worte, nicht die Taten sprechen.

      Illustration Okay, damit haben wir die Prinzipien von Agile abgeschlossen. Bitte denken Sie daran, dass diese sehr häufig in Prüfungen abgefragt werden.

      Erinnern Sie sich, wie der adaptive Lebenszyklus funktioniert? Hier noch mal das Bild, damit das Buch auch umfangreich genug wird:

illustration

      Bei diesem Thema gibt es ein paar Punkte, über die wir sprechen müssen. Zunächst wählen wir für jede Iteration eine Reihe von Funktionen aus. Unser Ziel ist, bis zum Ende der Iteration ein funktionierendes Inkrement zu erstellen, das hoffentlich alle Funktionen enthält. Jetzt ist Ihre Meinung gefragt. Was halten Sie für besser, eine Iteration mit festem Umfang oder eine Iteration mit fester Dauer?

      Theoretisch ist beides möglich, aber in der Praxis haben sich Iterationen mit fester Dauer bewährt. Die Gründe hierfür sind, dass man bei Iterationen mit festem Umfang…

      ■ …mehr Zeit benötigt, um den Umfang abzuschließen. Dadurch erhält man weniger Rückmeldungen und somit weniger Möglichkeiten zur Anpassung des Produkts.

      ■ … zu viel Zeit für die einzelnen Funktionen aufwendet und zu viel Schnickschnack hinzufügt. Bei einer festen Dauer muss man sich stets auf die wichtigsten (wertschöpfenden) Punkte konzentrieren.

      Aus diesem Grund nutzen fast alle Agile-Methoden Iterationen mit fester Dauer (so genannte Timeboxes) und bestehen meist darauf, diese einzuhalten. Eine Timebox ist eine Zeitspanne mit einer maximalen (oder festen) Zeitdauer, die unter keinen Umständen verlängert werden darf (verlängert man sie einmal, dann wird dies gerne zur Gewohnheit).

      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.

      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).

      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

      Wie sollte Ihrer Meinung nach der Entwicklungsprozess in den einzelnen Iterationen ablaufen? Hier gibt es zwei Möglichkeiten:

illustration

      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.

      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


Скачать книгу