Was uns die Geschichte der Vorgehensmodelle über agile Entwicklung verrät

Ich freue mich, diese Woche wiederholt einen Gastbeitrag von Dr. Andrea Herrmann zu veröffentlichen. Diesmal geht es um die Historie von Vorgehensmodellen. Schmunzeln musste ich beim Lesen, da Andrea darauf hinwies, dass Agilität wesentlich älter als bisher angenommen ist, wozu ich mich auch schon hier geäußert hatte.

Doch bevor es zum Artikel geht, hier noch ein Aufruf von Andrea zu einer nicht-kommerziellen Umfrage zur Agilität in der Praxis. Die Universität Magdeburg führt diese Umfrage zur Verbreitung und Nutzung der agilen Software-Entwicklung in der Software-Industrie im deutschsprachigen Raum durch. Die Beantwortung der Fragen dauert ca. 10 Minuten. Die Umfrage ist anonym, Ergebnisse werden auf Wunsch gern zugeschickt

Zur Umfrage „Agilität in der Praxis“ >>

Gastbeitrag von Dr. Andrea Herrmann

Folien des Vortrags

Am 22. Mai 2017 hielt ich in Karlsruhe auf den Karlsruher Entwicklertagen einen Pecha Kucha Vortrag über die Geschichte der Vorgehensmodelle. (Dabei handelt es sich um einen fest getakteten Vortrag mit 20 Folien, mit jeweils 20 Sekunden pro Folie.) Zu diesen historischen Archiv-Forschungen hatte ich schreibmaschinengeschriebene Artikel gelesen, in denen Namen von Betriebssystemen genannt wurden, die nur noch im Computermuseum laufen, und Speicherplatzmengen, die heute von einer Armbanduhr überschritten werden. Aus Sicht des Software Engineering sind die Probleme die gleichen geblieben: Unsere Möglichkeiten, die technische Komplexität zu beherrschen, hinken der Komplexität hinterher. Oder umgekehrt erzeugen wir wohl immer ein wenig komplexere Software als wir mit unseren Mitteln sicher fehlerfrei herstellen können. Nur so kommt man auf den Mond, nehme ich an.

Zusammenfassend kam bei meinen Forschungen heraus,

1. dass Agilität gar nicht so neu ist wie gedacht und
2. dass man auch früher nicht daran geglaubt hat, dass das Wasserfallvorgehen funktioniert. Seine erste Erwähnung findet das Wasserfallmodell bei Benington (1956) und bei Royce (1970). Aber Benington schlug das Wasserfallmodell als möglicherweise hilfreich vor, nachdem ein Projekt schief gelaufen war. Während Royce aufgrund seiner Projekterfahrung sicher sagen konnte, dass das Wasserfallmodell nicht funktioniert. Er schlug ein iteratives Vorgehen mit Prototypen vor.

Royce schrieb schon 1970, dass Wasserfall nicht funktioniert und ein iteratives Vorgehen mit Prototypen besser ist. Twittern

Es war also keinesfalls so, dass man früher glaubte, der Wasserfall würde funktionieren und alle nur danach arbeiteten. Auch damals kannte man schon iterative Vorgehensweisen. Es ist auch nicht so, dass in den 90ern ganz plötzlich durch geniale Schöpfung ganz neue Vorgehensmodelle entstanden, die die Software Engineering-Welt mit einem agilen Manifest von unten revolutionierten.

Stattdessen existierten Wasserfall und iterative, leichtgewichtige (also agile) Vorgehensweisen stets beide, mal mehr oder weniger gelobt durch die Fachliteratur. In den 80ern verstärkte sich jedoch die Kritik am Wasserfallvorgehen. Die standardisierte Agilität, wie wir sie heute kennen, insbesondere Scrum und XP, wurden tatsächlich in den 90ern entwickelt. Allerdings hatten diese schon Vorgänger wie das heute fast vollständig vergessene Rapid Application Development (RAD). Dieses sah dem heutigen Scrum schon sehr, sehr ähnlich! In den 90ern wurde auch erst das Wasserfallvorgehen richtig standardisiert z.B. in Form von V-Modell XT, und das schwergewichtige Rational Unified Process RUP. Die 90er waren also insgesamt ein Zeitalter der Standardisierung von Vorgehensmodellen.

Rapid Application Development aus den 80ern sah dem heutigen Scrum schon sehr ähnlich! Twittern

Danach erlebten die agilen Methoden einen Hype und gewannen an Marktanteil. Jedoch werden immer noch ungefähr die Hälfte aller Projekte nach dem Phasenmodell durchgeführt. Die andere Hälfte ist nicht agil, denn es gibt auch Projekte ganz ohne explizites Vorgehensmodell.

Die Gegenwart des Software Engineering sieht so aus, dass Scrum bis an seine Grenzen ausgereizt und für verschiedene  Anwendungsbereiche modifiziert wird. Dazu gehören auch solche, für die es gar nicht gemacht war wie große und verteilte Teams, oder die Entwicklung sicherheitskritischer Software mit hohem Dokumentationsbedarf. Dazu hat sich u.a. das gar nicht recht agile Scaled Agile Framework (SAFe) entwickelt.

Für die Zukunft sage ich eine größere Vielfalt voraus. Es wird nicht-agile Vorgehensmodelle geben, die sich aus Marketinggründen agil nennen, jede Firma entwickelt ihr eigenes „ScrumBut“ und so weiter. So finden wir hoffentlich doch noch heraus, wie man fehlerfreie Software entwickelt!

Photo by Les Anderson on Unsplash