Agile Scrum Handbuch. Frank Turley

Чтение книги онлайн.

Читать онлайн книгу Agile Scrum Handbuch - Frank Turley страница 5

Agile Scrum Handbuch - Frank Turley

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

muss an dieser Stelle jedoch gesagt werden, dass bei einem Bauvorhaben, beispielsweise einem Bauvorhaben für ein Krankenhaus, unabhängig von der Anzahl der Änderungen, am Ende immer ein Krankenhaus und nicht zum Beispiel ein Freizeitpark entsteht. Bei der IT-Entwicklung dagegen, kann es durchaus vorkommen, dass man ein Projekt mit einem bestimmten Ziel startet und sich dieses Ziel im Laufe des Projekts massiv und grundlegend ändert.

      IT-Projekte ermöglichen also eine iterative und/oder inkrementelle Bereitstellung. Diese Möglichkeit machen wir uns in folgendem Lebenszyklus zu Nutze:

illustration

      Bei diesem Lebenszyklus gibt es keine echten Prognosen. Anstatt das Produkt zu prognostizieren (und sich auf diese Prognose zu verlassen), werden in kurzen Zeiträumen Produktinkremente erstellt. Jedes Inkrement (die neueste Version des Produkts) wird dem Kunden und den Benutzern vorgestellt. Die Aktivitäten im nächsten Zeitraum richten sich dann nach dem jeweiligen Feedback. Statt einer Prognose wird das Projekt also kontinuierlich weiterentwickelt und an das Feedback angepasst bzw. adaptiert. Daher auch die Bezeichnung adaptiver Lebenszyklus.

      Um ein Inkrement zu erstellen, müssen alle Entwicklungsprozesse innerhalb einer bestimmten Zeitspanne ausgeführt werden. Im nächsten Zeitraum wird das Ganze dann wiederholt bzw. iteriert. Man nennt diese Methode der Entwicklung deshalb auch iterative Entwicklung. Die Zeitspannen, in denen diese Prozesse und Handlungen wiederholt werden, bezeichnet man auch als Iteration. Daneben gibt es noch eine weitere Bezeichnung, auf die wir aber später noch näher eingehen werden.

      Prognostizierte und adaptive Lebenszyklen haben beide Vor- und Nachteile. Die richtige Wahl hängt von vielen Faktoren ab. Der wichtigste Faktor ist jedoch die Art des zu erstellenden Produkts.

      Stellen Sie sich die zwei folgenden grundlegenden Fragen, bevor Sie den für Ihr Projekt benötigten Lebenszyklus festlegen.

      1. Muss ich mich flexibel anpassen? Lautet die Antwort auf diese Frage nein, dann eignet sich ein prognostizierter Lebenszyklus besser! Prognostizierte Lebenszyklen sind einfacher und strukturierter. Ein adaptives System ist in den Fällen erforderlich, in denen ein gewisses Risiko besteht, dass man bei Projektstart ein Krankenhaus bauen soll und zu guter Letzt eine Art Freizeitpark dabei herauskommt.

      2. Kann ich mich überhaupt flexibel anpassen? Diese Frage ist sogar noch wichtiger. Wer anpassungsfähig sein möchte, muss die Möglichkeit zur iterativen Entwicklung und inkrementellen Bereitstellung haben. Denken wir noch einmal an unser Bauprojekt: Können Sie das Gebäude iterativ planen? Können Sie zum Beispiel nur das Fundament planen, ohne den Rest des Gebäudes zu entwerfen bzw. ohne die Lasten zu bestimmen, die das Fundament tragen muss? Die Antwort auf diese Frage ist einfach und lautet NEIN! Eine iterative Entwicklung ist bei Bauprojekten nicht möglich. Das Gleiche gilt, wie bereits erwähnt, für die inkrementelle Bereitstellung. Ein ada ist daher für den Bau eines Gebäudes nicht geeignet (bitte verwechseln Sie dies nicht mit Projekten in den Bereichen Innenarchitektur und -ausstattung oder gar Renovierung, für die adaptive Systeme durchaus in Frage kommen können).

      Was ich hier vermitteln will ist, dass prognostiziert oder adaptiv keine Frage von gut oder schlecht ist.

      Machen wir eine kleine Übung. Stellen Sie sich ein IT-System vor: Um für eine sehr große Organisation mit Niederlassungen an sechs Standorten eine Netzwerkinfrastruktur zu errichten, soll für das Betriebssystem der 300 Computer einer Organisation oder eines IT-Projekts ein Update durchgeführt werden. Welcher Lebenszyklus der IT-Entwicklung ist Ihrer Meinung nach für dieses Projekt besser geeignet?

      Agile ist die populäre Bezeichnung für Systeme mit adaptiven Lebenszyklen. Diese Definition des Begriffs Agile ist viel besser als zu sagen „Agile ist eine Einstellung“.

      Sprechen die Anhänger von agilen Methoden über prognostizierte Lebenszyklen (englisch: Predictive Lifecycles), verwenden sie die Bezeichnung Wasserfall. Dies gilt vor allem für IT-Projekte; kein Mensch würde sagen: „Dieses Gebäude wurde mit Hilfe der Wasserfallmethode gebaut.“

      Um ganz sicherzustellen, dass Sie die Terminologie beherrschen, sollten Sie sich bewusst sein, dass das Wort Wasserfall inzwischen praktisch ein Unwort ist und dass Sie durchaus wütend und beleidigt reagieren dürfen, wenn jemand sagt, dass Sie die Wasserfallmethode verwenden! Ich schlage deshalb vor, dass wir uns in diesem Buch an die offizielle Bezeichnung halten und von prognostizierten Lebenszyklen sprechen.

      Agile wird in der Regel als neue Methode beworben. Das Wort Agile für adaptive Lebenszyklen zu verwenden ist sicherlich neu, aber wie sieht es mit dem Lebenszyklus selbst aus?

      Ich weiß nicht, wie es Ihnen geht, aber ich kann mir nur schwer vorstellen, dass die vielen Projekte und Programme in der langen Geschichte der Menschheit ganz ohne adaptive Lebenszyklen ausgekommen sind. Fällt Ihnen vielleicht ein Beispiel ein?

      Ich kann Ihnen ein Beispiel nennen. Denken Sie einmal an eine in der Vergangenheit äußerst gängige Praxis (bzw. ein äußerst gängiges Projekt oder Programm): Krieg führen. Kann man einen Krieg mit einem prognostizierten Ansatz führen? Lässt sich alles von Anfang an planen und festlegen? Ganz bestimmt nicht. Zwar gibt es wahrscheinlich einen übergeordneten Plan, eher eine Art Strategie, aber den Krieg an sich müssen Sie Schlacht um Schlacht (d. h. in Iterationen) führen (manchmal werden möglicherweise mehrere Schlachten gleichzeitig gekämpft). Und je nach Ausgang der einzelnen Schlachten wird dann die Strategie für die weitere Kriegsführung flexibel angepasst.

      Dieses Beispiel ist zwar kein angenehmes Thema, zeigt aber ganz klar, dass adaptive Ansätze nicht neu sein können.

      Was also ist neu?

      Irgendwann in der Vergangenheit wurden der so genannte wissenschaftliche Managementansatz und der Taylorismus zur Norm und jeder andere Ansatz galt als minderwertig oder sogar falsch. Da Taylorismus voll und ganz auf prognostizierten Systemen beruhte, dominierten diese Systeme sozusagen die ganze Welt.

      Dann kam eine Zeit, in der immer mehr Projekte in der IT-Entwicklung initiiert wurden. Die prognostizierten Systeme waren für das Management dieser Projekte nicht wirklich die beste Lösung. Man versuchte zwar dies zu tolerieren, aber der Druck stieg und es kam zu Demonstrationen und schließlich zur Revolution! Und, wie das bei Revolutionen so üblich ist, frisst auch diese Revolution ihre Kinder, aber dazu ein andermal.

      Bald schon kamen die ersten adaptiven Systeme in der IT-Entwicklung zum Einsatz und wurden allmählich strukturiert und in reproduzierbare Managementsysteme überführt. 2001 schlossen sich dann einige Pioniere auf diesem Gebiet zusammen und erarbeiteten ein Manifest.

      Beginnen wir mit dem Namen. Es wird erzählt, dass nach langen Beratungen zwei Möglichkeiten übrigblieben: Das Agile Manifest oder Das Adaptive Manifest. Leider fiel die Entscheidung auf Das Agile Manifest. Das Adaptive Manifest wäre

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