Читать книгу Agile Schule (E-Book) - Ralf Romeike - Страница 7

Allein entwickelte Software ist typischerweise nicht sehr komplex, wird von wenigen genutzt oder hat eine kurze Lebenszeit. Anders ist es mit großen Softwaresystemen: Sie werden von vielen für viele geschrieben und meist über Jahrzehnte genutzt und weiterentwickelt.

Die Entwicklung solcher Softwaresysteme begann Mitte des letzten Jahrhunderts mit Steuerelementen für Raumfahrt und militärische Streitkräfte. Anfangs wurde im Großen ebenso «intuitiv» wie im Kleinen entwickelt. In den folgenden Jahrzehnten beauftragten Banken, Telefon- und Transportgesellschaften, Unternehmen für Medizintechnik und viele weitere Branchen zunehmend umfangreichere Softwarelösungen, die nur noch von Teams entwickelt werden konnten. Rasch wurde klar: Das Risiko zu scheitern war ohne ein strukturiertes Vorgehen groß. Dass es damals, als sich die Informatik als Wissenschaft erst entwickelte, noch kaum systematisch ausgebildete Informatiker, aber viele Ingenieure in der Softwareentwicklung gab, mag erklären, weshalb man in den 1960er-Jahren bewährte Vorgehensweisen aus Bau- und Produktionsprozessen übernahm und sie für die Softwareentwicklung anpasste. So entstand ein wasserfallähnlicher Verlauf in Phasen, der einen Schwerpunkt auf die sehr präzise Analyse und Definition der Anforderungen legte, um dadurch, analog zum Bauwesen, teure oder gar unmögliche spätere Änderungen zu vermeiden. Anschließend wurde gemäß den Anforderungen ein detaillierter Plan ausgearbeitet und im Folgenden genau umgesetzt. Kommuniziert wurde dabei im Wesentlichen durch das Weiterreichen der umfangreichen Dokumentation. Diese heute als klassisch bezeichneten Vorgehensweisen brachten Struktur in den Prozess, aber auch neue Probleme. Planungsfehler wurden beispielsweise oft erst am Ende des Projekts erkannt und waren zu diesem Zeitpunkt nur mit erheblichem Zusatzaufwand meist in Form von Überstunden behebbar. Außerdem beschrieben die verschriftlichten Wünsche des Kunden aufgrund von Kommunikationsschwierigkeiten oder unzureichender Kenntnisse oft nicht das, was eigentlich gebraucht wurde, sodass die Arbeit von Monaten oder Jahren «umsonst» war. Nach Abschluss einer klassischen Planung eingebrachte Wünsche durften nicht mehr berücksichtigt werden, auch wenn eine Planänderung aus Sicht des Entwicklerteams möglich und sinnvoll gewesen wäre. Die Praxis der Softwareentwicklung zeigte Ende des 20. Jahrhunderts immer deutlicher, dass langfristige Pläne oft nur für kurze Zeit gute Pläne sind, insbesondere in einer Welt, deren Anforderungen und Einsatzszenarien immer volatiler, komplexer, unsicherer und mehrdeutiger werden.

Abbildung 2.1: Probleme bei klassischem Vorgehen: Was der Kunde beschreibt, was er anfangs bräuchte, was umgesetzt wird, was noch gerettet werden kann und was er am Ende tatsächlich gebraucht hätte