Agile Scrum Handbuch

Sie möchten etwas lernen, das Sie bei Ihren Projekten unterstützt? In diesem Fall sollten Sie zwei entscheidende Punkte beachten, die meist falsch verstanden werden:

1. Die weit verbreitete Aussage „ Agile ist eine Einstellung." ist falsch. Richtig dagegen ist, dass man für Agile eine bestimmte Einstellung braucht. Bezeichnet man Agile als Einstellung, so führt dies in der Praxis lediglich dazu, dass man ohne jegliche Einschränkung und ganz nach eigenem Gutdünken arbeitet. Man nennt es einfach Agile , lässt Kritik an sich abprallen und strebt nicht wirklich nach Verbesserung.

2. Wer auch nur die Spur einer Ahnung hat, wie autoritäre Systeme funktionieren, weiß, dass solche Systeme stets ein Feindbild brauchen, um Schwächen im eigenen System zu überspielen und die Massen kontrollieren zu können. Die traditionelle Wasserfall-Methode erfüllt für viele Anwender agiler Methoden die Funktion dieses Feindbilds. Die Wasserfall-Methode wird zwar niemals eindeutig definiert, aber es wird impliziert, dass es sich um etablierte Projektmanagementsysteme handelt. Erfolgreiche Projekte benötigen jedoch kein Feindbild. Bitte denken Sie stets daran, dass erfolgreiche Systeme immer auf den vorhandenen Systemen aufbauen und nicht von Grund auf neu gebaut werden und dass jede Kritik, ganz gleich wie berechtigt sie sein mag, respektvoll und konstruktiv sein muss.

Sehen wir uns also an, was Agile wirklich bedeutet.

■ 1.1 PROJEKTMANAGEMENTMETHODE UND PROJEKTLEBENSZYKLUS

Bei der Softwareentwicklung werden auf die eine oder andere Weise folgende Schritte entweder für einzelne Funktionen oder für die Softwarelösung insgesamt durchgeführt:

■Analyse

■Design (Planung)

■Realisierung

■Integration

■Test

Natürlich können diese Schritte auch anders bezeichnet, in weniger Schritte zusammengefasst oder in mehrere Schritte aufgeteilt werden. Diese Schritte nennt man auch Phasen der Softwareentwicklung.

Die Frage ist nun, wie Sie diese Phasen organisieren und ausführen. Nehmen Sie sich kurz Zeit und überlegen Sie sich ein paar Optionen, bevor Sie den Rest des Kapitels lesen.

Nun, auf wie viele Optionen sind Sie gekommen?

Möglicherweise können Sie sich viele verschiedene Optionen vorstellen. Im Endeffekt aber, gehören alle diese Optionen zu einer der zwei generischen Formen. Übrigens bezeichnet man diese Optionen auch als Lebenszyklus der Softwareentwicklung:

Ein generischer Lebenszyklus sieht etwa so aus:

In diesem Lebenszyklus wird jede Phase abgeschlossen, bevor man mit der nächsten beginnt. Mit anderen Worten, Anforderungen werden vollständig analysiert, bevor entschieden wird, was die Lösung beinhalten muss. Dann wird die Architektur der Lösung entworfen und festgelegt, wie sich die Funktionen am besten gestalten lassen. Im Anschluss daran arbeiten die Programmierer an verschiedenen Einheiten, die dann in einer Lösung zusammengeführt und als Gesamtlösung getestet werden.

Natürlich können sich die Schritte auch überlappen; so muss man beispielsweise nicht warten bis alle Einheiten vorliegen, bevor man mit der Integration und dem Testen beginnt. In einem solchen Fall könnte der Lebenszyklus wie folgt aussehen:

Dieser Lebenszyklus unterscheidet sich nicht grundlegend vom vorherigen Lebenszyklus und besteht ebenfalls aus einer sequenziellen Abfolge von Entwicklungsprozessen.

Grundvoraussetzung für diese Art von Lebenszyklus ist der anfängliche Aufwand, die Anforderungen an das zu bauende System zu verstehen. Die Spezifikation, das Design und folglich auch die Planung liegen im Vorfeld vor. Daher spricht man bei dieser Art von Lebenszyklus auch von einer plangesteuerten Entwicklung. Wir versuchen vorherzusagen bzw. zu prognostizieren, was wir wollen und wie sich dies realisieren lässt. Man spricht daher auch von einem prognostizierten Lebenszyklus.

Prognostizierte Lebenszyklen sind bei vielen Projekten, wie z. B. bei Bauvorhaben, der normale und geeignete Weg. Zuerst werden Planung und Entwurf erstellt und danach richtet sich dann die anschließende Ausführung. Für andere Projekte dagegen, ist diese Vorgehensweise nicht optimal.

Denken Sie nur einmal an ein typisches Projekt in der IT-Entwicklung. Man investiert viel Zeit in die Spezifikation und Analyse der Anforderungen und baut dann die gesamte Entwicklung des Softwareprodukts darauf auf. Was passiert nun in der Praxis häufig? Die Kunden wünschen Änderungen. Änderungen aber sind bei diesem Lebenszyklus in dieser Phase teuer, da möglicherweise alle bisherigen Ergebnisse nochmals überarbeitet und geändert werden müssen.

Eine gängige Weisheit in der IT besagt, dass viele Kunden erst wissen, was sie wollen, wenn sie das fertige Produkt sehen. Das Produkt sehen sie aber erst gegen Ende des Projekts und damit in einer Phase, in der Änderungen mit den größten Kosten verbunden sind.

Diesem Problem können wir begegnen, indem wir den Komfort und die Struktur des prognostizierten Lebenszyklus opfern, zugunsten eines Lebenszyklus, bei dem das Produkt inkrementell, in mehreren Versionen entwickelt wird. Jede Version umfasst dabei mehr Funktionen als ihre Vorgängerversion. Diese Art der Entwicklung ist ein besonderer Luxus, den nicht alle Projekte bieten. Bei Bauvorhaben beispielsweise gibt es keine sinnvollen Inkremente und das Produkt kann erst nach Abschluss des Projekts genutzt werden. Die IT-Entwicklung jedoch bietet die Möglichkeit mehrerer funktionierender Versionen, bei der jede Version um weitere Funktionen ergänzt wird.

Fairerweise 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:

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.

■ 1.2 PROGNOSTIZIERTE VERSUS ADAPTIVE LEBENSZYKLEN

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?

■ 1.3 AGILE VERSUS WASSERFALL

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