4.5 Selbstorganisation
5.1 Kanban
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
