Die Softwarekrise

Die zunehmende Popularität agiler Methoden ist auf die sogenannte Softwarekrise zurückzuführen. Die Herausforderung effiziente und nützliche Computerprogramme in einem bestimmten definierten Zeitrahmen zu erstellen. Die Krise verschärfte sich durch den Trend Software-Teams nach den gleichen Methoden zu führen, die auch im Bau- und Produktionsprozess üblich sind. Im Allgemeinen sind dort die hergestellten Produkte identisch, denken Sie an Autos derselben Marke, des gleichen Modells, die nacheinander vom Fließband laufen. Konstrukteure und Manager erstellen in der Regel präzise Checklisten mit klar definierten Tools und Prozessen, an die sich die Mitarbeiter halten müssen. Es wird eine umfassende Systemdokumentation erstellt, so dass sich Fehler leicht nachvollziehen und dann am Schluss auch ausmerzen lassen. Im Bauwesen sieht es ähnlich aus. Sobald Sie ein Vertrag über den Bau eines Hauses unterschreiben, sind die Anforderungen eingefroren. Wollen Sie was ändern oder hinzufügen fallen zusätzliche Kosten an. Veränderungen sind im Allgemeinen sehr verpönt und werden natürlich immer kostspieliger, je weiter das Projekt dann auch fortgeschritten ist. In der frühen Software-Entwicklung wurde dann versucht, diese Ansätze im Bauwesen und der Produktion nachzuahmen indem man dem sogenannten Wasserfallmodell folgte. Das Wasserfallmodell umfasst fünf Phasen. Anforderungen, Analyse-Entwurf, Entwicklungen, Testen und zum Schluss Einsatz und Wartung. Jede Phase endete mit einer genau definierten eingefrorene Leistung, die als Eingabe für die nächste Phase dient. Anforderungen werden dann frühzeitig erfasst und als Eingaben für Phase Analyse-Entwurf verwendet. Wenn die Analyse-Entwurfsphase abgeschlossen ist, haben wir ein vollständig konzipiertes System, das dann für die Entwicklung bereit ist. Wenn die Entwicklung abgeschlossen ist, wird erwartet, das System für das Testen bereit ist und so weiter und so fort. Was soll jetzt an diesem Ansatz falsch sein? Es gibt zwei offensichtliche Problem. Erstens bekommt der Kunde das Produkt erst in der frühen Testphase zu sehen, dann sind aber in der Regel bereits zwei Drittel der Zeit auf der Zeitachse des Produkts verstrichen. Vielleicht erkennen Sie in der ersten Phase Einsatz und Wartung, dass das entstehende Produkt keine Chance mehr hat aufgrund von geänderten Marktbedingungen, der organisatorischen Ausrichtungen oder der veränderten Wettbewerbslandschaft. Oder Sie stellen fest, dass die Architektur des Produkts einen erheblichen Mangel aufweist, der den Einsatz ausschließt. Anders ausgedrückt könnte Ihre Produktentwicklung völlig scheitern, nachdem Sie viel Geld und Zeit dafür aufgewendet haben. Das zweite Problem beim Wasserfallmodell entsteht durch das Topdown-Management, von den Mitgliedern des Entwicklungsteams wird erwartet, dass sie Checklisten und detaillierten Kontrollen befolgen, mit anderen Worten Prozesse werden wichtiger erachtet, als das Wissen und die Erkenntnisse des Teams. Jede Phase ist mit einer Abschlussbedingungen versehen und diese Vorgaben müssen erfüllt sein, bevor das Entwicklungs-Team mit der nächsten Phase beginnen kann. Schon in den frühen 90er Jahren hinterfragte die Softwareindustrie den aus dieser, der verarbeitenden Industrie übernommenen und ziemlich direkt auf die Entwicklung von Software übertragenen Ansatz. Laut beispielsweise eines Berichts der Standish Group aus dem Jahr 1994, konnten nur rund 16 Prozent der begutachteten Projekte innerhalb des Budgets und pünktlich mit den ursprünglich geplanten Funktionen erfolgreich abgeschlossen werden. Bei 53 Prozent der Software-Projekte hat man das Budget überschritten, Funktionen nicht realisiert, beziehungsweise den Termin nicht eingehalten. Und dort ein Buch von Scott Ambler und Larry Constantine aus dem Jahr 2000 endeten 85 Prozent der begutachteten Softwareprojekte komplett auf der Müllhalde. Da war so zweifellos ein neuer Ansatz für die Softwareentwicklung gefragt. Und damit kommen wir zu den agilen Methodiken.