Wie wird Agilität verstanden und umgesetzt? Die Merkmale agiler Softwareentwicklung

Inhaltsverzeichnis

1. Einleitung

2. Theoretischer Hintergrund
2.1. Komplexität von IT-Projekten
2.2. Vorgehensmodelle
2.2.1. Historische Entwicklung der Softwareentwicklung
2.2.1.1. Sequentielle Softwareentwicklung
2.2.1.2. Inkrementelle Softwareentwicklung
2.2.1.3. Iterative Softwareentwicklung
2.2.1.4. Iterativ-Inkrementelle Softwareentwicklung
2.3. Agile Softwareentwicklung
2.3.1. Prinzipien und Werte
2.3.2. Definitionen agiler Softwareentwicklung
2.3.3. Frameworks und Methoden
2.3.4. Praktiken
2.4. Vorgehensmodelle im Vergleich
2.5. Zusammenfassung

3. Fragestellungen

4. Literaturanalyse
4.1. Methode
4.2. Ergebnisse
4.2.1. Analyse der Merkmale
4.2.2. Theorie abgeleitete Definition
4.2.3. Alleinstellungsmerkmale der agilen Softwareentwicklung
4.3. Zusammenfassung

5. Interviews
5.1. Methode
5.1.1. Rekrutierung der Teilnehmer
5.1.2. Stichprobe
5.1.3. Material
5.1.4. Durchführung
5.1.5. Kontrolle von Störfaktoren
5.1.6. Beurteilung der Gütekriterien
5.1.7. Auswertung
5.2. Ergebnisse
5.2.1. Kenntnisse, Wissen, Erfahrungen und Modelle in der Softwareentwicklung
5.2.2. Einsatz, Abschluss und Verträge agiler Softwareentwicklung
5.2.3. Komplexität
5.2.4. Abschluss und Erfolg von Projekten agiler Softwareentwicklung
5.2.5. Persönliche Einstellung zu agiler Softwareentwicklung
5.2.6. Definition agiler Softwareentwicklung
5.2.7. Praxis abgeleitete Definition
5.2.8. Alleinstellungsmerkmale der agilen Softwareentwicklung
5.2.9. Vergleich der Merkmale
5.2.10. Arbeitsdefinition: Agile Softwareentwicklung
5.3. Zusammenfassung

6. Diskussion
6.1. Diskussion der Ergebnisse
6.2. Theoretische und Praktische Implikationen
6.3. Kritische Würdigung und Limitationen

7. Fazit und Ausblick

Literaturverzeichnis

Anhang

“It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change.” - Charles Darwin

Abstract

Agile software development have been used for more than two decades. Since then attempts have been made to define agile software development. The definitions published so far are not generally accepted as they give an incomplete idea of agile development. As a consequence, the concept of agile software development is not explained at any point and agile methods are used with a certain degree of insight. With the spread of agile methods more projects failed due to incomplete understanding. The aim of this thesis was to understand agile software development from the perspective of literature and practice in order to develop and propose a comprehensive working definition. For this purpose, the history of software development was reworked in order to be able to grasp the development of certain approaches that are important for agile software development. Furthermore, a literature analysis of 30 definitions and the agile manifestos was conducted to capture the characteristics of agile software development from a literature perspective. In addition to the literature analysis, ten employees were interviewed by telephone who advised, researched or developed software with agile methods in order to obtain the characteristics of agile software development, reasons for and against their use, as well as further information from a practical point of view. On the basis of both methods, the unique characteristics of agile software development could be identified and a comprehensive working definition developed. The results as well as their theoretical and practical implications were discussed. Further important questions and needs for action for future research could be derived.

Zusammenfassung

Seit über zwei Jahrzehnten werden Methoden der agilen Softwareentwicklung verwendet und seither wird auch der Versuch unternommen, die agile Softwareentwicklung zu definieren. Die bisher veröffentlichten Definitionen werden nicht allgemein anerkannt, da sie ein unvollständiges Bild von der agilen Entwicklung vermitteln. In der Konsequenz wird das Konzept der agilen Softwareentwicklung an keiner Stelle erklärt und die agilen Methoden werden mit einem bestimmten Grad an Unwissenheit eingesetzt. Mit der stärkeren Verbreitung agiler Methoden scheiterten auch mehr Projekte am unvollständigen Verständnis. Das Ziel dieser Arbeit war es, das Verständnis von agiler Softwareentwicklung aus Perspektive der Literatur und Praxis zu erfassen, um eine umfassende Arbeitsdefinition zu erarbeiten und vorzuschlagen. Dafür wurde die Geschichte der Softwareentwicklung aufgearbeitet, um die Entwicklung bestimmter Ansätze, die für die agile Softwareentwicklung wichtig sind, erfassen zu können. Weiterhin wurde eine Literaturanalyse von 30 Definitionen und den agilen Manifesten durchgeführt, um die Merkmale agiler Softwareentwicklung aus Sicht der Literatur zu erfassen. Neben der Literaturanalyse wurden über Telefoninterviews bundesweit zehn Mitarbeiter befragt, die über agile Softwareentwicklung berieten, forschten oder agil entwickelten, um die Merkmale agiler Softwareentwicklung, Gründe für und gegen deren Einsatz neben weiteren Informationen aus Sicht der Praxis zu erhalten. Auf Basis beider Methoden konnten die Alleinstellungsmerkmale der agilen Softwareentwicklung identifiziert und eine umfassende Arbeitsdefinition erarbeitet werden. Die Ergebnisse, sowie deren theoretische und praktische Implikationen wurden diskutiert und es konnten weitere wichtige Fragestellungen und Handlungsbedarfe für zukünftige Forschungen abgeleitet werden.

Danksagungen

Ich möchte an dieser Stelle all denen Danken, die mich bei der Erstellung dieser Arbeit unterstützt haben.

Ein ganz besonderer Dank gilt meinem Betreuer, Dr. Michael Minge, der sich gerne die Zeit nahm, mir mit Rat zur Seite zu stehen, mich bei der Akquise von Probanden unterstützte und mir dabei half, die ein oder andere organisatorische Hürde zu überwinden.

Ich bedanke mich bei Friederice Schröder aus selbigem Fachgebiet der Kognitionspsychologie und Kognitive Ergonomie der Technischen Universität Berlin, dass sie mich bei der Erstellung des Interviewleitfadens unterstützte und bei Herrn Prof. Thüring, für die angenehme Zusammenarbeit.

Ich danke weiterhin allen, die mich durch Vermittlungen in der Probandenakquise, durch direkte Teilnahme am Telefoninterview oder anderweitig unterstützt haben. Allem voran Jasmin Rück, Dori Rück, Matthias Ritz, Max Reibert, Verena Jeske, Dominic Lindner, Jil Klünder und Helge Fahlbusch.

Abbildungsverzeichnis

1: Complexity-Matrix, eigene Abbildung nach Zimmerman (2001) basierend auf Stacey (1996)

2: Zusammenhang von Vorgehensmodellen, Framework, Methoden und Vorgehensweisen, eigene Darstellung nach Balzert (2000), Gnatz (2005) und Kuhrmann (2008)

3: Historische Entwicklung der Softwareentwicklung von 1955 bis 1990, eigene Darstellung

4: Planning Spectrum aus Boehm (2002, S.65)

5: Stacey Matrix adaptiert von Stacey (1996), selbst modifiziert mit eingezeichnetem Planning Spectrum auf der Diagonalen (Quelle: Eigene Darstellung)

6: Stacey Matrix adaptiert von Stacey (1996), selbst modifiziert mit grober Einordnung der Vorgehensmodelle (Quelle: Eigene Darstellung)

7: Vorgehen zur Erarbeitung der Arbeitsdefinition

8: Gewinnung und Aufbereitung von Merkmalen

9: Vollständige Übersicht aller extrahierten Merkmale

10: Merkmale, die aus den Manifesten extrahiert wurden

11: Merkmale, die aus den Definitionen extrahiert wurden

12: Alleinstellungsmerkmale agiler Softwareentwicklung

13: Themenbereiche des selbsterstellten Interviewleitfadens

14: Fragen des Interviewleitfadens

15: Vorgehensmodelle, die auf Anhieb genannt werden konnten (n = 11)

16: Bekanntheit von Vorgehensmodellen innerhalb der Stichprobe (n = 11)

17: Genannte Frameworks und die Häufigkeit ihrer Nennung

18: Genannte Methoden und die Häufigkeit ihrer Nennung

19: Genannte Praktiken und die Häufigkeit ihrer Nennung

20: Genannte Gründe, die für den Einsatz agiler Softwareentwicklung sprechen und die Häufigkeit ihrer Nennung (n = 11)

21: Genannte Gründe, die gegen den Einsatz agiler Softwareentwicklung sprechen und die Häufigkeit ihrer Nennung (n = 11)

22: Genannte Herausforderungen/Barrieren und deren Lösungsvorschläge

23: Wichtige Faktoren bei der Bestimmung der Komplexität mit der Häufigkeit ihrer Nennung

24: Merkmale von Vorgehensmodellen, die von den Teilnehmern zur agilen Softwareentwicklung zugeordnet wurden

25: Bewertung von Aspekten agiler Softwareentwicklung

26: Bewertung des Bekanntheitsgrades der Systemanforderungen und der Technologie von den Teilnehmern

27: Merkmale, die aus den Interview-Antworten extrahiert wurden

28: Alleinstellungsmerkmale agiler Softwareentwicklung

29: Vollständige Übersicht aller gefundenen Merkmale

30: Vollständige Übersicht aller Alleinstellungsmerkmale agiler Softwareentwicklung Merkmale aus den Interview-Antworten, die noch nicht in der vorläufigen Arbeitsdefinition verarbeitet wurden

Anhänge

Anhang A: Abbildungen und wichtige Merkmale der Vorgehensmodelle

Anhang B: Wichtige Merkmale der Vorgehensmodelle

Anhang C: Interviewleitfaden

1. Einleitung

Die Entwicklung der IT-Technik führte vor allem in den Anfängen der Softwareentwicklung auch zu einer steigenden Komplexität von Softwareprojekten, bei denen die notgedrungene Verwendung der bisher bekannten aber ungeeigneten Vorgehensmodelle zur sogenannten Softwarekrise führte (Mcllroy, Buxton, Naur, & Randell, 1968). Das Ergebnis waren weitgehend unbrauchbare Ergebnisse und unzufriedene Beteiligte (vgl. Jarzombek, 1999). Denn in der Praxis bewegten sich die Softwareprojekte zunehmend im sogenannten komplexen Bereich (Goll, 2015). Dieser Bereich ist dadurch gekennzeichnet, dass die Anforderungen an ein System als auch die Technologien zur Umsetzung nicht klar definiert sind (Stacey, 1996). Unter solchen Umständen funktionieren bisherige Modelle nur bedingt (Dyba, 2000), weswegen die Einführung sogenannter agiler Methoden Abhilfe versprach. Im Jahr 2001 wurden diese agilen Methoden in Form von Werten und Prinzipien über das agile Manifest durch Beck et al. (2001) formuliert. Agile Softwareentwicklung wurde als Lösung bisheriger Probleme der Softwaretechnik und damit als Ausweg aus der Software Krise propagiert, weswegen viele Unternehmen ihre Entwicklung mit traditionellen Modellen auf eine agile Entwicklung umstellten (vgl. West, Grant, Gerush, & D'silva, 2010; Porrawatpreyakorn, 2013).

Jedoch erschwert die unterschiedliche Vorstellung der Begriffe agil, Agilität und agile Softwareentwicklung die Einführung und den Einsatz agiler Methoden ungemein (Laanti, Similä, & Abrahamsson, 2013). Nach Analyse mehrerer Definitionen wird schnell klar, „wie diffus der Begriff der Agilität in der Softwareentwicklung ist“ (Halamzie, 2013, S.15). Es existieren zwar Definitionen, aber auch Dern (2011) berichtet, dass Recherchen zur Definition agiler IT-Systeme keine eindeutige und allgemein akzeptierte Definition erbrachten. Jedoch sind agile IT-Systeme nicht gleichzusetzen mit einer agilen Softwareentwicklung. Agilität kann schließlich im Kontext vieler Unternehmensbereiche betrachtet werden. So hat jedes Unternehmen einen bestimmten Grad an Agilität, der abhängig von der Unternehmensstruktur, den Mitarbeitern, der Arbeitsorganisation und vielen weiteren Faktoren ist (Tsourveloudis & Valavanis, 2002). In dieser Arbeit liegt das Augenmerk auf Agilität im Kontext der Softwareentwicklung, welche jedoch ausgehend von der Softwareentwicklung unternehmensweite Auswirkungen haben kann.

Dabei ist zu beachten, dass die agile Softwareentwicklung lediglich ein grundsätzliches Vorgehensmodell neben vielen weiteren darstellt (vgl. Chroust, 1992), chronologisch oft unvollständig beschrieben mit dem Phasenmodell über das Spiralmodell hin zur aktuellen agilen Entwicklung (vgl. Broy, & Kuhrmann, 2013; Herzog, 2015). In vielen Publikationen werden Modelle, die vor der agilen Softwareentwicklung existierten, auch als traditionelle oder plan-basierte Modelle zusammengefasst (vgl. Theocharis, Kuhrmann, Münch, & Diebold, 2015). Viele Modelle der Softwareentwicklung überschneiden sich zumindest teilweise (Broy, & Kuhrmann, 2013), da sie meist basierend auf bisher Bestehenden entwickelt wurden, mit dem Ziel, die Probleme der Vorgänger zu beheben (Herzog, 2015). So überrascht es kaum, dass z.B. iterative und inkrementelle Ansätze in nahezu jeder agilen Methode vorkommen. Problematisch ist dabei, dass diese Ansätze selten den traditionellen Vorgehensmodellen zugeordnet, sondern oft als Alleinstellungsmerkmal agiler Softwareentwicklung aufgeführt werden. Iterative und inkrementelle Ansätze stellen zunächst das Hauptmerkmal des Spiralmodells dar (vgl. Boehm, 1988; Broy, & Kuhrmann, 2013), sind allein genommen sogar ein eigenständiges Vorgehensmodell und in der Praxis lediglich ein Bestandteil agiler Methoden (vgl. West, Gilpin, Grant, & Anderson, 2011; Theocharis et al., 2015).

Diese Verwendung von ähnlichen und gleichen Ansätzen über die Modelle hinweg, trägt zu einer Unübersichtlichkeit bei, die das Verständnis und eine Definition agiler Softwareentwicklung erschweren. Das hat zur Folge, dass viele Publikationen eine entsprechende Definition agiler Softwareentwicklung vermeiden, diese stattdessen umschreiben oder eigene Definitionen aufstellen. Folglich sind Unternehmen als Anwender agiler Methoden verunsichert, was sich unter anderem darin äußert, dass sie in Umfragen angeben, sie würden agil entwickeln, obwohl häufig eine Mischform aus verschiedenen Modellen und deren Methoden die Praxis ist (West, Gilpin, Grant, & Anderson, 2011; Kuhrmann et al., 2018). So setzen nach Befragungen von VersionOne (2016) 95 % der Unternehmen agile Prozesse ein, wo hingehen nur 38 % der Unternehmen nach einer Befragung von PMI (2015) agile Prozesse nutzen. Ein weiteres Anzeichen dieser Verunsicherung ist die Tatsache, dass ca. 12 % aller agilen Projekte laut einer Umfrage von 6point6 endgültig scheitern (Porter, 2017) und nach einer Langzeitstudie der Standish Group International (2016) sogar 19 %. Als einer der Gründe wird mangelnde Erfahrung mit agilen Methoden angeführt (VersionOne, 2016). Dennoch werden agile Methoden eingesetzt, obwohl sie sich nur in bestimmten Fällen eignen (vgl. Stacey, 1996). Friedrichsen und Johann (2012) beschreiben den Einsatz konkret für überschaubare Projekte mit nur einem Jahr Laufzeit und Teamgrößen von maximal sieben Mitarbeitern.

Auf der einen Seite wird also sehr viel über den Einsatz agiler Methoden, deren Erfolgsfaktoren, sowie über mögliche Hindernisse und Barrieren debattiert. Auf der anderen Seite scheint aber die Grundlage noch unklar zu sein, wie die agile Softwareentwicklung definiert wird und wie sie sich von anderen Vorgehensmodellen im Kern unterscheidet. Eine einheitliche und allgemein akzeptierte Definition würde die Forschung unterstützen und ein besseres Verständnis für den Einsatz agiler Methoden in der Praxis schaffen. Deshalb ist es das Ziel dieser Arbeit eine einheitliche Arbeitsdefinition zu erarbeiten und vorzuschlagen.

Dazu sollen die charakteristischen Merkmale der bekanntesten Vorgehensmodelle im Rahmen einer umfassenden Literaturrecherche und -analyse erarbeitet und gegenübergestellt werden. Mittels dieser Merkmale soll eine möglichst trennscharfe Abgrenzung zur agilen Softwareentwicklung erreicht werden, die gleichsam dessen Alleinstellungsmerkmale hervorheben sollen. Die charakteristischen Merkmale der agilen Softwareentwicklung werden im Rahmen einer weiteren Literaturanalyse identifiziert, um die Bildung einer rein literaturbasierten Arbeitsdefinition zu unterstützen.

Zusätzliche dazu werden Unternehmenskontakte über Interviews befragt, um Merkmale agiler Softwareentwicklung aus einer praxisnahen Perspektive zu erfassen. Diese Merkmale bilden eine weitere eigenständige, aus der Praxis abgeleitete Arbeitsdefinition, die anschließend mit der literaturbasierten Arbeitsdefinition verglichen wird, um Unterschiede im Verständnis zu identifizieren.

Im letzten Schritt bilden die Merkmale aus den Literaturanalysen zusammen mit denen aus den Interviews die finale Arbeitsdefinition. Dafür werden alle identifizierten Merkmale und die gefundenen Unterschiede zwischen der literaturbasierten und praxisbasierten Arbeitsdefinition diskutiert.

2. Theoretischer Hintergrund

Die Entwicklung von Software benötigt ein gut organisiertes und strukturiertes Vorgehen. Die Softwareentwicklung ist dabei ein Teilgebiet der Softwaretechnik, die im Ganzen die „zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen“ (Balzert, 2000, S. 36) darstellt. Die Softwaretechnik bedient sich bei der Organisierung von IT-Projekten bestimmter Vorgehensmodelle, die aus der Softwareentwicklung heraus entstanden sind (Broy & Kuhrmann, 2013). Zu diesen Vorgehensmodellen gehört auch die agile Softwareentwicklung.

Die Entwicklung verschiedener Vorgehensmodelle war historisch stark durch den praktischen Grund getrieben, der stets zugenommenen Komplexität neuerer IT-Projekte begegnen zu können (vgl. Dyba, 2000; Larman & Basili, 2003). Appelo (2011) betont daher, dass die agile Softwareentwicklung ihren Ursprung aus den Komplexitäts-Theorien hat. Effektive Ansätze, die mit neuen Vorgehensmodellen vorgestellt wurden, bildeten oft die Basis für darauffolgende Modelle. Da die agile Softwareentwicklung erst nach vielen anderen Vorgehensmodellen entstand, kann davon ausgegangen werden, dass manche Ansätze von vorherigen Vorgehensmodellen übernommen wurden. Deshalb wird zunächst erläutert, was unter der Komplexität von IT-Projekten zu verstehen ist, bevor anschließend auf die Vorgehensmodelle eingegangen wird, die vor der agilen Softwareentwicklung veröffentlicht wurden. Diese nähere Betrachtung der Vorgehensmodelle ist auch notwendig, um die agile Softwareentwicklung von den anderen Modellen abgrenzen zu können.

Im Anschluss daran wird erläutert, was in der Literatur als agile Softwareentwicklung beschrieben wird und welche Methoden und Praktiken diesem Modell zugeordnet werden.

2.1. Komplexität von IT-Projekten

Die Entwicklung der IT-Technik führte vor allem in den Anfängen der Softwareentwicklung auch zu einer steigenden Komplexität von Softwareprojekten. Dies beschrieb Edsger Dijkstra nach den 70er Jahren: „ when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.“ (Dijkstra, 1972, S.20). Da die bisherigen Projekte mit vorhandenen Vorgehensmodellen erfolgreich bearbeitet werden konnten, gab es zunächst keine adäquaten Vorgehensmodelle für die immer häufiger gewordenen IT-Projekte höherer Komplexität. In der Praxis führte dies zu der notgedrungenen Verwendung der bisher bekannten aber ungeeigneten Vorgehensmodelle, was zur Folge hatte, dass sehr viele IT-Projekte scheiterten (vgl. Jarzombek, 1999). Dieses Phänomen trat Mitte der 70er Jahre auf und wurde als Softwarekrise bezeichnet (Mcllroy, Buxton, Naur, & Randell, 1968).

Die steigende Komplexität bewegte die Softwareentwicklung letztendlich dazu, adäquate Vorgehensmodelle zu entwickeln. Mittlerweile stehen der Softwareentwicklung zahlreiche Vorgehensmodelle zur Verfügung, die sich je nach Komplexität des Projektes mehr oder weniger eignen. Es existiert also kein universelles Vorgehensmodell (Sommerville, 2015), welches alle Komplexitätsstufen abdeckt. Allerdings kann die Identifikation der Komplexität dazu genutzt werden, ein passendes Vorgehensmodell für ein bestimmtes Projekt zu finden. Die Verwendung ungeeigneter Modelle kann andernfalls zum Scheitern von Projekten führen (vgl. Jarzombek, 1999; Porter, 2017). Deshalb ist es ratsam, die Komplexität vorher abzuschätzen, was über Instrumente, wie der Complexity-Matrix von Stacey (1996), möglich ist. Die Komplexität eines IT-Projektes wird dabei maßgeblich durch die Beschreibung der Anforderungen und die einzusetzende Technologie mitbestimmt (vgl. Stacey, 1997). Basierend darauf hat Stacey (1997) die Complexity-Matrix als ein Instrument entwickelt, um die Komplexität eines IT-Projektes mit einer Matrix ungefähr bestimmen zu können. Zimmerman (2001) hat diese Matrix aufgegriffen und in die vier Bereiche einfach, kompliziert, komplex und chaotisch eingeteilt. Die Aufteilung in die vier Bereiche ist dabei nicht exakt gekennzeichnet, da sie auf Beschreibungen von Stacey (1997) beruhen, der IT-Projekte in sieben verschiedene Komplexitätsstufen einteilte, welche wiederum entlang der Diagonalen der Matrix durch Zimmerman (2001) eingezeichnet wurden. Die Complexity-Matrix ist in

Abbildung 1 dargestellt und bildet sich aus dem Bekanntheitsgrad der Anforderungen auf der Ordinatenachse und dem Bekanntheitsgrad der einzusetzenden Technologie auf der Abszissenachse.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Complexity-Matrix, eigene Abbildung nach Zimmerman (2001) basierend auf Stacey (1996).

In der ersten Komplexitätsstufe beschreibt Stacey Projekte, in denen sämtliche Anforderungen klar definiert sind. Das Vorgehen ist sehr strukturiert, direkt und das Ergebnis ist deshalb vorhersehbar. Diese Stufe definiert den einfachen Bereich nach Zimmerman (2001), da eine sehr geringe Komplexität vorliegt. Die zweite Stufe stützt sich ebenfalls auf ein strukturiert geplantes Vorgehen, wobei für manche Variablen eingeplant wird, dass sich diese ändern dürfen. Aufgrund der leicht erhöhten Unsicherheit befindet sich diese Stufe an der Schwelle zum komplizierten, aber noch im einfachen Bereich, da sämtliche Änderungen absehbar sind und eingeplant werden können.

Der komplizierte Bereich definiert sich durch Vorhersehbarkeit trotz gewisser Unklarheiten bezüglich der Anforderungen und Technologien (Cohn, 2010). In der Praxis werden diese Unsicherheiten eingeplant. Dabei steht der Großteil dennoch fest, aber einfache Änderungen, wie z.B. die Farbe von Bedienelementen, bleiben für Anpassungen variabel. Die dritte Stufe zeichnet sich durch einen Austausch von Informationen im Sinne eines Lernprozesses aus, um Probleme lösen zu können, die unklar definierten Anforderungen oder auftretenden technologischen Problemen entsprungen sind. Diese Stufe stellt deshalb den Übergang zum komplexen Bereich dar, in dem laufend Lösungen gefunden werden müssen.

Nach Goll (2015) bewegt sich die Mehrheit der IT-Projekte aber im komplexen Bereich, der von Highsmith und Highsmith (2002) auch als chaordisch bezeichnet wird, einer harmonischen Koexistenz von Chaos und Ordnung, in der ähnliche kollaborative Werte und Prinzipien geteilt werden, die eine grobe Ordnung ermöglichen und dadurch gleichzeitig ein positives Chaos aufrechterhalten. Dies macht eine adaptive Projektdurchführung notwendig, bei der sich das Projekt letztendlich über die Laufzeit entwickelt (Cohn, 2010).

Projekte der vierten Stufte begegnen den Umständen bzw. Problemen des komplexen Bereiches durch die Einbeziehung von Stakeholdern, hauptsächlich des Auftraggebers, für regelmäßiges Feedback im Rahmen eines Lösungsfindungsprozesses. Die fünfte Stufe geht einen Schritt weiter und bindet die Stakeholder aktiv in den gesamten Entwicklungsprozess ein. Dafür müssen weitere Teile strukturierter Prozesse aufgegeben werden, da aufgrund überwiegend unbekannter Anforderungen und Technologien händeringend um Lösungen gesucht wird, was eine aktive Mitarbeit mit kurzen Entscheidungswegen fordert. Projekte der sechsten Stufe bemühen sich nicht um eine endgültige Lösungsfindung, da sich deren Anforderungen laufend ändern. Beispiele stellen Projekte im Bereich des Aktienhandels dar. Diese Projekte haben lediglich zum Ziel, das zugrundeliegende System besser zu verstehen.

Die letzte Stufe befindet sich im chaotischen Bereich, in welchem nahezu alle Anforderungen und Technologien unbekannt sind. Strukturierte Vorgehensweisen helfen in diesem Bereich nicht weiter. Regeln und Vorschriften sind gar hinderlich, weswegen das Vorgehen von Boehm (2002) als Hacking bezeichnet wird. Das Ziel solcher Projekte liegt darin, Handlungsvorschläge zu generieren, indem Arbeitsmuster ausfindig gemacht werden, die letztendlich das Chaos beseitigen und Struktur schaffen sollen.

Zu den vier Bereichen wurden in den vergangenen Jahrzehnten Vorgehensmodelle entwickelt, um entsprechende Projekte bewältigen zu können. Im Folgenden wird erklärt, was unter einem Vorgehensmodell zu verstehen ist und welche Vorgehensmodelle über die Zeit entstanden sind. Dies soll dabei helfen, die Kernidee agiler Softwareentwicklung zu erfassen.

2.2. Vorgehensmodelle

Vorgehensmodelle sind grundlegende Kategorien für bestimmte Prinzipien, Frameworks und Methoden, welche wiederum die genaue Vorgehensweise mittels Vorgaben und Regeln bestimmen (vgl. Balzert, 2000; Gnatz, 2005; Kuhrmann, 2008). Abbildung 2 visualisiert diese Zusammenhänge.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Zusammenhang von Vorgehensmodellen, Framework, Methoden und Vorgehensweisen, eigene Darstellung nach Balzert (2000), Gnatz (2005) und Kuhrmann (2008).

Die bekanntesten Vorgehensmodelle sind das Sequenzielle- bzw. Phasenmodell, Spiralmodell und die agile Entwicklung (vgl. Broy, & Kuhrmann, 2013). Diese Auflistung wird durch das V-Modell, die inkrementelle Softwareentwicklung, iterative Softwareentwicklung, die evolutionäre Entwicklung und Cleanroom Softwareentwicklung weitestgehend vervollständigt (vgl. Larman & Basili, 2003). Ob alle diese Vorgehensmodelle auch eigenständige Modelle darstellen, ist allerdings umstritten. Das liegt zum Teil daran, dass manche Vorgehensmodelle, wie die iterative Softwareentwicklung, komplett in anderen Vorgehensmodellen vorkommen können und das wirft wiederum die Frage auf, ob ähnliche Modelle nur eine Weiterentwicklung oder aber ein eigenständiges Modell darstellen (Larman & Basili, 2003).

In jedem Fall geben die Vorgehensmodelle bestimmte Werte und Prinzipien vor, denen die Frameworks und Methoden folgen sollen, damit die Kernidee des Modells auf die Softwareentwicklung übertragen werden kann.

Frameworks

Die Werte und Prinzipien definieren das grobe Konstrukt in Form eines Vorgehensmodells und stellen bereichsweise konkrete Anforderungen an die Softwareentwicklung. Ein Framework bildet sprichwörtlich den Rahmen der Softwareentwicklung und befindet sich hierarchisch gesehen innerhalb eines Vorgehensmodells, aber noch über den konkreteren Methoden. In der Literatur werden Vorgehensmodell, Framework und Methode sehr häufig synonym verwendet, was unter anderem der Verwirrung um den Begriff agiler Softwareentwicklung zusätzliche Dynamik verleiht. Anthony Draffin beschreibt diesen Umstand so: “It is shocking that intelligent, well educated people don't know the difference between a framework and a methodology. It's also shocking that prominent and respected organizations display this same ignorance. Who cares? Is this a semantic argument? No, this isn't a semantic argument and the difference between the two is an important distinction. It's important because a framework allows you to be loose and flexible; to have 'poetic license'. A methodology is much more prescriptive. Both can be handy at different times.” (Draffin, 2010).

Ein Framework kann die Art und Weise der Softwareentwicklung bereits sehr stark vorgeben, weswegen Framework und Methode oft nicht zeitgleich verwendet werden bzw. nur der Einsatz sehr bestimmter Methoden in Kombination mit einem Framework möglich ist. Das entweder ein Framework oder eine Methode angetroffen wird, ist sicherlich der Grund für deren oft fälschliche synonyme Verwendung. Ein wichtiger Unterschied zu einer Methode besteht darin, dass ein Framework den Spielraum für die Umsetzung der Bedingungen lässt. Ein Framework ist dabei lediglich eine logische Struktur für die Klassifizierung und Organisation komplexer Informationen. Beispielweise schreibt die agile Softwareentwicklung als Vorgehensmodell mittels Prinzipien und Werten vor, das eine regelmäßige Auslieferung von Software erfolgen sollte. Das agile Framework Scrum greift diese Vorgabe auf und schreibt vor, dies mittels kurzer Iterationen umzusetzen, die innerhalb des Scrum-eigenen Vokabulars Sprints genannt werden. Wie lange diese Iterationen aber sein können, wird als Handlungsspielraum offen gelassen, was in einer entsprechenden Methode hingegen definiert sein könnte.

Methoden

Methoden gehen also einen Schritt weiter und stellen eine konkretere Vorstellung eines Vorgehensmodells bzw. eines Frameworks dar, weil sie dieses für die praktische Anwendung übersetzen. Genauer gesagt ist eine Methode „ [...] eine spezifische und wiederholbare Vorgehensweise, bestehend aus Vorgaben und Regeln, die einen (nachweisbar erfolgversprechenden) Lösungsansatz für ein definiertes Problem beschreibt. Eine Methode strukturiert das Vorgehen (die Aktivitäten) in einem definierten Problembereich und gibt Hinweise zu den zu erstellenden Artefakten. “ (Broy & Kuhrmann, 2013, S.86).

In der Softwareentwicklung entstehen die Methoden oft aus praktischen Gründen, unabhängig davon welchem Vorgehensmodell sie zugeordnet werden könnten. Die reine Klassifizierung der Arbeitsmethoden scheint für die Praxis anfangs zumindest keinen direkten Nutzen zu haben. Die Methoden werden dann meist retrospektiv von der Forschung oder Literatur heraus einem der bisherigen Vorgehensmodelle zugeordnet. Wenn es nur eine Methode gibt, die nirgends zugeordnet werden kann, stellt diese ihr eigenes Vorgehensmodell dar. Dabei ist zu beachten, dass mehrere Methoden verschiedener Vorgehensmodelle auch kombiniert werden können, was als Tailoring oder (Situational) Method Engineering bezeichnet wird (Brinkkemper, 1996). Eine grundlegende Analyse der Methode ist für eine eindeutige Zuordnung daher unerlässlich.

Vorgehensweise - Phasen der Softwareentwicklung

Die Verwendung einer Methode bestimmt die Vorgehensweise maßgeblich. Diese beschreibt die Abfolge von bestimmten Projektphasen, die als Software-Development-Life-Cycle (SDLC) in einer bestimmten Reihenfolge definiert wurden. Im Standard-SDLC sind das die Phasen Konzeption, Anforderungsanalyse, Entwurf bzw. Design, Implementierung, Überprüfung und ggf. Wartung oder ähnliche Phasen, die ebenfalls der Prozessstruktur der internationalen Norm ISO/IEC 12207 folgen (Stoica, Ghilic-Micu, & Mircea, 2013). Welche Phasen ein Softwareprojekt durchläuft, ist dabei abhängig von der verwendeten Methode, wobei jede Methode den SDLC oder eine modifizierte Variante auf eine bestimmte Art und Weise einbezieht. Die genaue Analyse von Methoden verdeutlicht, dass selten alle Phasen für einen direkten Einsatz berücksichtigt bzw. abgedeckt werden (vgl. Abrahamsson, Salo, Ronkainen & Warsta, 2017).

2.2.1. Historische Entwicklung der Softwareentwicklung

Die agile Softwareentwicklung entstand erst nach vielen anderen Vorgehensmodellen. Es kann daher nicht ausgeschlossen werden, dass die agile Entwicklung auch einige Ansätze vorheriger Modelle übernommen hat. Literatur zur agilen Softwareentwicklung kann hingegen schnell den Anschein erwecken, dass es sich dabei um einen innovativen und fundamental neuen Ansatz der Softwareentwicklung handelt (vgl. Plattner, Meinel, & Weinberg, 2009), obwohl er historisch betrachtet starke Überschneidungen mit vorherigen Modellen aufweist. Viele der aufgegriffenen Ideen fanden schließlich bereits Jahrzehnte zuvor Verwendung in diversen Projekten (Larman & Basili, 2003). Um zu klären, wie sich die agile Softwareentwicklung entwickelt hat, folgt eine tiefergehende historische Aufarbeitung der vorangegangenen Vorgehensmodelle.

Im Folgenden werden die Vorgehensmodelle und deren Ansätze innerhalb ihrer Paradigmen näher erläutert, um zu klären, ob und in welcher Ausprägung diese Ansätze für die agile Softwareentwicklung übernommen wurden.

2.2.1.1. Sequentielle Softwareentwicklung

Die sequentielle Softwareentwicklung entstand aus der Idee heraus, die Entwicklung an bekannte Prozesse, wie der Fließbandfertigung aus der Produktion, anzulehnen. Schließlich gab es vorher noch kein formalisiert beschriebenes Vorgehen für die Entwicklung von Software, da Computer noch nicht weit verbreitet waren und so ermöglichten sequentielle Vorgehensmodelle erstmals die Standardisierung von Softwareentwicklungsprozessen durch eine detaillierte Planung (Boehm & Turner, 2003).

In diesen Anfängen wurde das Nine-phase stage-wise-model ¹ von Benington im Rahmen eines Symposiums als das erste sequentielle Modell der Softwareentwicklung vorgestellt (Everett, Zraket, & Benington, 1957). Dieses Modell wurde direkt aus den Ingenieurwissenschaften adaptiert und folgt daher dem typischen sequenziellen Verlauf ohne Rückkopplungen, wie er z.B. aus der Produktion oder Konstruktion zu damaliger Zeit bekannt war (Benington, 1983). Nach Everett, Zraket und Benington (1956) sollte jede Phase des Software Development Life Cycles vollständig abgeschlossen sein, bevor die nächste Phase begonnen wird. Das Ergebnis jeder Phase ist dann durch Planung vorhersehbar. Entsprechend eignet sich das Phasenmodell gut für vorhersehbare IT-Projekte, in denen sämtliche Anforderungen bekannt sind und klar definiert werden können (Sommerville, 2015). Damit konnten einfache IT-Projekte bewältigt werden. Wenn die Anforderungen an das IT-Projekt jedoch unklarer werden, kann das Projekt nicht komplett zu Beginn geplant werden. Der sequentielle Verlauf erlaubt schließlich auch keine Korrekturen in der laufenden Entwicklung und so eignet sich das Phasenmodell nur für einfache, vorhersehbare IT-Projekte (Dyba, 2000).

Sicherlich ebenso von der Produktionsindustrie inspiriert, wurde die Teilefertigung bzw. inkrementelle Fertigung zeitnah nach Veröffentlichung des Phasenmodells auf die Softwareentwicklung übertragen.

2.2.1.2. Inkrementelle Softwareentwicklung

Die Grundidee inkrementeller Entwicklung liegt darin, ein Projekt in abgeschlossene kleinere Teile zu zerlegen, die jeweils einen eigenen kleinen Software Development Life Cycle vom Anfang bis zum Ende durchlaufen (Boehm, 1981). Das inkrementelle Modell² ist damit ein mehrfach angewandtes Phasenmodell (Pressman, 2005). In der genauen Definition ist die inkrementelle Entwicklung eine stufenweise festlegende Strategie, bei der verschiedene Teile des Systems zu unterschiedlichen Zeiten oder Raten entwickelt und integriert werden, sobald sie abgeschlossen sind (Cockburn, 2008).

Dieses Vorgehen ermöglicht ein paralleles Arbeiten und benötigt dafür wiederum eine flexible Softwarearchitektur, welche eine modulare Integration der Module bzw. Teilergebnisse zulässt. Diese Architektur muss wie ein Gerüst fungieren, was mit den Teilergebnissen ausgefüllt wird, bis es vollständig ist. Im Vergleich zum Phasenmodell können alle Ergebnisse schließlich nicht einfach aufeinander aufbauen, da diese parallel oder aber zu ganz unterschiedlichen Zeiten integriert werden. Die inkrementelle Entwicklung setzt jedoch auch auf weitgehend bekannte Anforderungen, da die Teile des Systems, also die Inkremente, vorher geplant werden müssen, um eben diese passende Architektur zu schaffen. So gilt für die inkrementelle Entwicklung, dass für die Verwendung eines solchen modularisierten top-down- Ansatzes die Probleme und deren Lösungen von Beginn an bekannt sein müssen (Basili & Turner, 1975).

Kleinere Anforderungsänderungen können aber innerhalb der Inkremente berücksichtigt werden. Ebenso könnte die Software nach jeder Integration eines Inkrements ausgeliefert werden, die dann, wenn auch eingeschränkt, bereits frühzeitig eingesetzt werden kann. Das inkrementelle Vorgehensmodell ist allein genommen allerdings noch keine Lösung für IT-Projekte höherer Komplexitätsstufen. Das liegt daran, dass Änderungen, die nicht zu Beginn des Projektes absehbar und planbar sind, generell nur in nachfolgenden Generationen des Produktes berücksichtigt werden können, was schon von Shewhart und Deming (1939) in der Produktion erkannt wurde. Die inkrementelle Entwicklung bewegt sich hingegen innerhalb einer Produktgeneration und nicht darüber hinaus.

Mit der Zeit wurden die IT-Projekte größer, komplexer und die Entwicklung dauerte umso länger, teilweise mehrere Jahre (vgl. Dijkstra, 1972). In der Praxis bewegten sich die Softwareprojekte in den 70er Jahren zunehmend im sogenannten komplizierten und komplexen Bereich (Goll, 2015). Diese Bereiche sind dadurch gekennzeichnet, dass die Anforderungen an ein System als auch die Technologien zur Umsetzung zu Beginn des Projektes nicht klar definiert sind (Stacey, 1996), was das Phasen- bzw. Wasserfallmodell und das inkrementelle Entwicklungsmodell für entsprechend komplexere Projekte disqualifiziert. Änderungswünsche, die nach Anbruch der Entwicklung eingereicht wurden, konnten in der Entwicklung nicht mehr berücksichtigt werden. Die sequentiellen Vorgehensmodelle waren diesen hohen Anforderungen nicht gewachsen und deren notgedrungene Verwendung führte zu vielen unbrauchbaren Ergebnissen. Dieser Abschnitt der Softwareentwicklung wurde später als Software-Krise bezeichnet (Mcllroy, Buxton, Naur, & Randell, 1968; Dijkstra, 1972).

Iterationen

In der Produktion wurden hingegen schon frühzeitig die Vorzüge eines sich wiederholenden Vorgehens erkannt (Shewhart & Deming, 1939). Die wiederholte Überarbeitung eines Produktes kommt einem evolutionären Vorgehen gleich, bei dem sich das Produkt über mehrere Generationen entwickelt und verbessert. Mit dem Plan-do-study-act Zyklus beschrieben Shewhart und Deming (1939) erstmals ein solches iteratives, sich widerholendes Vorgehen zur Verbesserung der Produktqualität für Produktionsprozesse. Royce (1970) betonte später, dass die Softwareentwicklung allgemein in mindestens zwei Iterationen ablaufen müsse. Die erste Iteration sollte ein “Pilot-Modell“ hervorbringen, auf dessen Basis dann Feedback eingeholt werden kann. Für die Softwareentwicklung veröffentlichten Zurcher und Randell (1968) in den 70er Jahren zur Hochzeit der Softwarekrise dann das Grundgerüst eines iterativen Vorgehensmodells. Dieses Konzept sollte in den folgenden Jahren weiter ausgebaut werden und in den 90er Jahren letztendlich zur agilen Softwareentwicklung führen.

Die Iterationen hatten stets das Ziel, im Rahmen eines Lernprozesses Verbesserungen bzw. Änderungen anzustoßen, die das Produkt entsprechend verbessern. Mills (1976) fasste den Vorteil des iterativen Vorgehens damit zusammen, dass eine Möglichkeit geschaffen wurde, regelmäßig Feedback aus der realen Welt einzuholen, um zu lernen und damit Änderungswünschen begegnen zu können. Für das Feedback bietet es sich an, die Software nach jeder Iteration auszuliefern, damit der Auftraggeber oder Nutzer ³ die Software validieren kann. Insgesamt betrachtet findet dadurch eine laufende Verifikation statt, mit welcher sich die wahren Anforderungen herauskristallisieren (Mills, 1988). Dieser Lernprozess wurde in den Anfängen iterativer Softwareentwicklung nicht explizit beschrieben, aber dennoch von Beginn an praktiziert (vgl. O'Neill, 1983).

Diese frühe Entwicklungsstufe der Softwareentwicklung hatte mit Lernprozessen, Iterationen, mehreren Auslieferungen, Feedback, Verifikationen und Validierungen bereits in den 70er Jahren einen sehr starken Vorgeschmack von agiler Softwareentwicklung (Larman & Basili, 2003), welche zunächst als iterative Softwareentwicklung veröffentlicht wurde (Zurcher & Randell, 1968).

2.2.1.3. Iterative Softwareentwicklung

Definiert nach Cockburn (2008) ist die iterative Entwicklung⁴ eine Strategie, bei der zeitlich terminiert ist, Teile des Systems bis zum gewünschten Ergebnis durch Überarbeitung zu verbessern. In der Softwareentwicklung werden die Phasen des Software-Development-Life­Cycles dafür einfach wiederholt. Das Ergebnis jedes Zyklus ist eine lauffähige Software, die sich über die nachfolgenden Iterationen bis zur angestrebten Funktionalität entwickelt (Basili & Turner, 1975).

Ein iteratives Vorgehen ermöglicht die flexible Erweiterung eines Produktes um neue Anforderungen oder aber die Änderung von bestehenden Funktionen über zukünftige Iterationen. Das Ergebnis jeder Iteration kann zudem eine lauffähige Software sein, die ausgeliefert und bereits frühzeitig eingesetzt werden kann. Das Produkt kann sich über mehrere Generationen entwickeln und benötigt daher nicht alle Anforderungen zu Beginn des Projektes. Lediglich die Anforderungen, die innerhalb einer Generation entwickelt werden sollen, müssen zum Beginn einer Iteration bekannt sein. Ein iteratives Vorgehen ist damit robust gegenüber Anforderungsänderungen, da diese in den nachfolgenden Generationen berücksichtigt werden können und ermöglicht dadurch erstmals die Bearbeitung von komplizierten IT-Projekten mit stellenweise unbekannten Anforderungen.

Bei komplexen IT-Projekten mit vielen unbekannten und häufig wechselnden Anforderungen kommt dieses Vorgehensmodell jedoch auch an seine Grenzen. Deshalb war Anfang der 80er Jahre generell das Bestreben zu beobachten, Techniken für die Bearbeitung komplexer IT-Projekte zu finden (vgl. Mills, 1974). Und da die schrittweise Annäherung in Form eines iterativen Vorgehens immer mehr Beachtung fand, wurde viel mit der Erweiterung bestehender Vorgehen um Iterationen experimentiert (vgl. Wirth, 1971). In dieser Zeit war in der Softwareentwicklung oft von iterative enhancement, also der iterativen Erweiterung, zu lesen (vgl. Basili & Turner, 1975).

2.2.1.4. Iterativ-Inkrementelle Softwareentwicklung

Eine Erweiterung des inkrementellen Vorgehensmodells um Iterationen wurde erstmals von O'Neill (1983) als „ integration engineering“ beschrieben, der dieses Vorgehen für ein Projekt bei IBM im Jahr 1972 nutzte. Diese Kombination verleiht der Softwareentwicklung eine sehr hohe Flexibilität und rüstet diese für komplizierte IT-Projekte, wie O'Neill (1983) rückblickend feststellte. Die Abgrenzung der iterativen von der inkrementellen Entwicklung ist dabei weiterhin wichtig, da es sich um zwei unterschiedliche Konzepte handelt, die sich sehr gut ergänzen, jedoch in Publikationen fälschlicherweise oft synonym verwendet oder verwechselt werden (Ludewig & Lichter, 2013).

Diese iterativ-inkrementelle Entwicklung⁵ sieht vor, dass mehrere Inkremente eine Version bzw. einen funktionierenden Stand der Software ergeben, der in der kommenden Iteration über neue Inkremente erweitert wird. Das erlaubt Änderungen zu jeder Zeit der Entwicklung und nicht erst zum Ende einer Iteration oder gar erst nach Auslieferung der Software. Dringende Änderungen können als Inkrement innerhalb einer Iteration priorisiert abgearbeitet werden. Das Ergebnis jeder Iteration kann anschließend veröffentlicht werden oder in kürzeren Frequenzen sogar jedes abgeschlossene Inkrement innerhalb einer Iteration. Über die vielen Veröffentlichungen gelangt die Entwicklung noch schneller an Feedback und kann auf dessen Basis korrigieren oder erweitern.

Leichtgewichtige Bürokratie

Die hochfrequente Veröffentlichung von Software brachte aber auch Probleme mit sich. Die Bürokratie, speziell die ausgeprägte Planung zu Beginn und die Dokumentation, nahm rund um die Software stark zu, da jede Änderung am Programm allein schon eine Anpassung der Dokumentation nach sich zog (Kelly & Keenan, 2010). Diese schwergewichtige Bürokratie lähmte den Entwicklungsprozess, was Martin (1991, S. 128) mit dem Satz “Bureaucracy is the enemy of speed “ zusammenfasste. Ebenso ist es schwer, alle Anforderungen korrekt und konsistent zu planen und zu dokumentieren, wenn das Projekt einer sich ständig ändernden Umgebung unterliegt (Zhang et al., 2010).

In der Folge setzten sich Praktiken durch, die dies über leichtgewichtige bürokratische Prozesse lösten. Die Leichtgewichtigkeit der Bürokratie bezieht sich aber keineswegs darauf, dass weniger dokumentiert und geplant wird (vgl. Broy & Kuhrmann, 2013). Die Prozesse mussten lediglich für die iterativ-inkrementelle Entwicklung optimiert werden, damit innerhalb einer Iteration weniger Aufwand anfiel oder sich dieser zumindest besser verteilt an den aktuellen Stand der Software orientierte.

Evolutionäre Entwicklung

Die häufigen Auslieferungen stellen aber auch ein weiteres Problem der iterativ-inkrementellen Entwicklung dar. Die Frequenz der vielen Veröffentlichungen musste mit dem Auftraggeber abgeglichen werden, damit Zeit für Feedback eingeplant werden konnte und die Entwicklung in der Zwischenzeit nicht still stand. In der Praxis setzen sich daher gleichmäßig getaktete Auslieferungen durch, häufig in ein bis zwei wöchigen Intervallen, die von allen Beteiligten eingeplant werden konnten (vgl. Ambler, 2002b).

Diese regelmäßigen Auslieferungen führten zu Feedback, welches wiederum die Evolution der Software ermöglichte. Dadurch etablierte sich der Begriff der evolutionären Auslieferungen, auch deshalb, weil Gilb (1985) die iterativ-inkrementelle Entwicklung generell als evolutionäres Entwicklungsmodell vorstellte.

Seitdem werden eine enge Kommunikation, kontinuierliches Feedback mit Rückkopplungen und iterative Zyklen als Kernelemente eines guten Prozessdesigns betrachtet (vgl. Bazjanac, 1974). Wenig später betonte Mills (1976), dass Softwareentwicklung in inkrementellen Stufen stattfinden sollte, mit kontinuierlicher Nutzereinbindung und Neuplanungen in jeder dieser Stufen. Mit diesem Stand iterativ-inkrementeller Entwicklung konnte bereits ein Großteil der IT-Projekte bewältigt werden.

Die Verwendung sequentieller Modelle hielt jedoch weiterhin an. Royce (1970) griff das Phasenmodell von Benington auf, fasste es in fünf Stufen zusammen und präsentierte es als ein fehleranfälliges, risikobehaftetes und verbesserungswürdiges Beispielmodell, in der Form des Wasserfall-Modells, wie es die Softwareentwicklung heute kennt. Die Bezeichnung Wasserfall-Modell⁶ wurde erstmals von Bell und Thayer (1976) gewählt, da das Modell von Royce (1970) kaskadenartig wie ein Wasserfall von Phase zu Phase fließt. Das United States Department of Defense legte dieses Modell dennoch als Standard 2167A für sämtliche Entwicklungen im Einflussbereich fest (vgl. Larman & Basili, 2003). Viele Unternehmen und Institutionen lösten sich ebenfalls nicht von der sequentiellen Entwicklung, mit der Folge, dass weiterhin viele IT-Projekte bis in die 90er Jahre überwiegend unbrauchbare Ergebnisse hervorbrachten (vgl. Jarzombek, 1999).

Parallel dazu beschäftigten sich einige Softwareingenieure bereits mit dem Feintuning iterativ-inkrementeller Softwareentwicklung, mit deren Einsatz große Institutionen wie IBM oder die NASA äußerst erfolgreich waren (vgl. Madden & Rone, 1984).

Qualitätssicherung

Zu diesen Verbesserungen gehörte der Fokus auf Risiken und die damit verbundenen Testverfahren. Das 1979 veröffentlichte V-Modell von Boehm (1979) machte den Anfang und rückte die Qualitätssicherung in Form einer Validierung und Verifizierung der Ergebnisse unmittelbar in den Fokus der Softwareentwicklung. Dieses Modell markiert insofern einen Wendepunkt in der Softwareentwicklung, da der vorherige Fokus von der Effektivität zur Effizienz wechselte. Schließlich war die Komplexität der IT-Projekte zu diesem Zeitpunkt kein großes Hindernis mehr für die iterativ-inkrementelle Entwicklung, die Ergebnisse und Prozesse konnten hingegen weiter optimiert werden. Dokumentierte Projekte, wie das Projekt Mercury der NASA, zeigen jedoch auch, dass Praktiken der Qualitätssicherung in Form einer testgetriebenen Entwicklung bereits in den 60er Jahren angewandt wurden (Larman & Basili, 2003) - eine Praktik, die die Softwareentwicklung erst 2003 wiederentdeckte (Tacker, 2017).

Zur Verifikation und Validierung wurden bis zum V-Modell⁷ keine Modelle veröffentlicht, die objektive Prüfverfahren als festen Bestandteil der Softwareentwicklung integrierten. Das V-Modell setzt den Phasen der Anforderungsanalyse, der Anforderung und Architektur und dem detaillierten Design der Software jeweils eine Phase gegenüber mit welcher der Inhalt verifiziert und validiert werden soll (vgl. Dröschel & Wiemers, 2015). Cockburn (2008) beschreibt die Validierung des V-Modells als eine Tatsache des Lebens, denn in der Realität muss sich die entwickelte Software auch mit den tatsächlichen Anforderungen messen. Es sei demnach sinnvoll, in der Softwareentwicklung eine laufende Überprüfung zu integrieren.

Wenige Jahre nach dem V-Modell stellte Mills (1993) gegen 1981 das Cleanroom- Vorgehensmodell⁸ vor, welches auch ein evolutionäres Vorgehen beschreibt (vgl. Linger & Trammell, 1996; Dyer & Mills, 1983). In der Definition ist die Cleanroom Softwareentwicklung ein Theorie-basierter, Team-orientierter Prozess zur Entwicklung und Zertifizierung von Softwaresystemen mit hoher Reliabilität unter statistischer Qualitätskontrolle (Mills, 1992; Linger, 1993; Linger, 1994). Die statistische Zertifizierung ist zu der Zeit ein neuer Ansatz. Cleanroom betrachtet den Softwaretest als statistisches Experiment, um letztendlich die Reliabilität der Software berechnen zu können. Damit sticht Cleanroom als ein sehr mathematisches Modell hervor, welches den Vorteil bietet, die Zuverlässigkeit der Softwarefunktionalität über die Reliabilität ausdrücken zu können. Mit diesem Vorgehensmodell rückte aber auch ein neuer Aspekt guter Softwareentwicklung weiter in den Fokus: Die Zufriedenheit der Entwickler. Untersuchungen von Sherer, Kouchakdjian und Arnold (1996) ergaben, dass die Zufriedenheit der Entwickler aufgrund verbesserter Kommunikation, Koordination und der dadurch entstehenden gemeinsamen Vision durch das Cleanroom-Vorgehensmodell erhöht wurde. Durch die höhere Zufriedenheit soll letztendlich qualitativ hochwertige und zuverlässige Software produziert werden.

Swartout und Balzer (1982) erklärten später zum V-Modell, dass die Phase der Anforderungsanalyse mit der des Designs in starker Wechselwirkung steht. Vor diesem Hintergrund schlagen auch sie generell eine Validierung über einen iterativen und evolutionären Ansatz vor, um die wahren Anforderungen besser zu erfassen. Daraufhin folgte von Boehm (1988) 1985 das iterativ-inkrementelle Spiralmodell⁹, was zunächst Prototypen zur Unterstützung der Anforderungsanalyse erstellt. Diese Prototypen können zur reinen Demonstration des Designs erstellt und verworfen oder aber funktional bis zum fertigen Produkt ausgebaut werden (vgl. Ketabchi, 1988; Crinnion, 1992). Das Spiralmodell ist wie Cleanroom auch risikofokussiert, zieht aber Risiken direkt als zentralen Maßstab des Projektfortschritts heran. Zu Beginn einer jeden Iteration werden sämtliche mögliche Risiken identifiziert und bewertet, sodass zunächst immer das größte Risiko beseitigt werden kann. Das Projekt gilt als gescheitert, wenn die Risiken nicht beseitigt werden konnten und gegenteilig als abgeschlossen, wenn alle Risiken beseitigt wurden. Diese sogenannte Risiko-getriebe Entwicklung soll letztendlich das Risiko verringern, bei großen Projekten zu scheitern (Boehm & Hansen, 2000).

Übergang zur agilen Softwareentwicklung Curtis, Krasner, Shen und Iscoe (1987) erklärten zwei Jahre später, dass eine erfolgreiche Softwareentwicklung einen zyklischen Lernprozess beinhalten muss, mit einer hohen Aufmerksamkeit auf die Fähigkeiten der Mitarbeiter und deren Kommunikation, sowie einer gemeinsamen Vision. Vielfach wird betont, dass die Entwicklung großer Softwaresysteme als ein Lern- und Kommunikationsprozess betrachtet werden muss. Dieser Stand iterativ­inkrementeller Entwicklung beinhaltete schon sehr viele Ansätze, die auch eine agile Softwareentwicklung ausmachen. Es ist also kein Zufall, dass dieser Zeitraum auch die erste Methode hervorbrachte, die später rückwirkend der agilen Softwareentwicklung zugeschrieben wurde - Scrum, mit der auch die Idee selbstorganisierender Teams eingeführt wurde (Takeuchi, & Nonaka, 1986).

Zusammenfassung

Die ersten Vorgehensmodelle wurden vorgestellt, um den noch einfachen Prozess der Softwareentwicklung formalisiert beschreiben und ordnen zu können. Die weitere Entwicklung fand jedoch aus der Notwendigkeit heraus statt, mit der steigenden Komplexität von IT- Projekten schritthalten zu können. An der historischen Entwicklung ist sehr gut erkennbar, dass die Softwareentwicklung dabei zunächst einen starken Fokus auf Effektivität hat. Über die Zeit entstanden viele neue Ideen und Ansätze dafür, wie der Prozess der Softwareentwicklung hinsichtlich Effizienz und Effektivität verbessert werden könnte. Diese Ansätze markieren neben den grundsätzlichen Modellen historische Meilensteine, da sie zu Verbesserungen oder zu neuen konkreten Vorgehensmodellen bzw. Methoden geführt haben. Abbildung 3 stellt die wichtigsten Meilensteine und Ansätze auf der Zeitachse dar. Diese Zeitpunkte markieren überwiegend die ersten Nennungen dieser Ansätze in Publikationen. Es ist jedoch ebenfalls bekannt, dass viele Ansätze in der Produktion oder im Rahmen von IT-Projekten bereits deutlich früher verwendet und nur nicht explizit z.B. als konkrete Vorgehensmodelle veröffentlicht wurden. Ein Beispiel stellt die iterative Entwicklung dar, die bereits in den 30er Jahren von Shewhart und Deming (1939) als Plan-do-study-act Zyklus zur Verbesserung der Qualitätskontrolle in Produktionslinien vorgeschlagen wurde. Diese Ansätze fanden lediglich Jahrzehnte später ihren Einzug in die Softwareentwicklung (vgl. Gilb, 1976; Zultner, 1988).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 verdeutlicht ebenfalls, dass viele Ansätze bereits vor der agilen Softwareentwicklung in vorherigen Vorgehensmodellen verwendet wurden. Welche Ansätze von der agilen Softwareentwicklung letztendlich aufgegriffen wurden, wird im Rahmen des folgenden Abschnitts erläutert.

2.3. Agile Softwareentwicklung

Unter dem Begriff Agilität ist zunächst nur Beweglichkeit bzw. Wendigkeit zu verstehen (Duden Online, o.J.). Diese Beweglichkeit kann aufeinzelne Unternehmensbereiche oder gar auf das gesamte Unternehmen übertragen werden. Jedes Unternehmen hat einen bestimmten Grad an Agilität, der abhängig von der Unternehmensstruktur, den Mitarbeitern, der Arbeitsorganisation und vielen weiteren Faktoren ist (Tsourveloudis & Valavanis, 2002). Agilität stellt dabei eine Wertedimension dar. Übertragen auf die Softwareentwicklung soll der Begriff auf einen sehr flexiblen Entwicklungsprozess deuten. Agilität sollte nach Aulinger (2017) aber nicht mit Flexibilität gleichgesetzt werden, da eine ausgewogene Flexibilität, zusammen mit dem richtigen Maß an Stabilität, nur einen Aspekt einer agilen Organisation darstellt. Lindner, Ott und Leyh (2017), kamen im selben Jahr hingegen noch zu dem Schluss, dass die Begriffe Agilität, Flexibilität, Anpassung und Dynamik in der Literatur allzu oft synonym verwendet werden und eine Abgrenzung im Kontext der agilen Softwareentwicklung nicht möglich ist. Der Name agile Softwareentwicklung verleitet auch dazu, alle anderen Vorgehensmodelle fälschlicherweise als nicht-agile Vorgehen einzustufen. Jedoch kann jedem Vorgehensmodell ein bestimmter Grad an Agilität zugesprochen werden. Es wäre ebenso ein Fehlschluss, zu behaupten, dass agile Softwareentwicklung den höchsten Grad einer agilen Entwicklung darstellt.

Zusammengefasst sollte Agile Softwareentwicklung deshalb nur als Name für eine bestimmte Klasse von Methoden verstanden werden, die zwar einen sehr hohen, nicht aber maximalen Grad an Agilität mit sich bringen. Dave Thomas beschrieb diesen Umstand als Co­Autor des Agilen Manifests auf seinem Blog wie folgt: „ The word 'agile' has been subverted to thepointwhere itiseffectively meaningless [...]. Butonce the wordagile becomes meaningless, developers can no longer use it as a guide to what is useful in their practice.” (Thomas, 2014).

Den Erkenntnissen von Larman und Basili (2003) zufolge, stellt die agile Softwareentwicklung nur eine stark erweiterte inkrementell-iterative Entwicklung dar und kein eigenständiges Modell. Deshalb sind nahezu alle Aspekte iterativ-inkrementeller Entwicklung ein Teil von jeder agilen Methode (Sommerville, 2011). Es wird ohnehin diskutiert, ob agile Softwareentwicklung überhaupt ein Vorgehensmodell darstellt. Denn im Gegensatz zu den bisherigen Vorgehensmodellen ist der Kerngedanke agiler Entwicklung nicht einfach als Modell visualisierbar, da es sich lediglich um Rahmenbedingungen in Form einer Philosophie handelt, die den bereits gut ausgearbeiteten Softwareentwicklungsprozessen nur die notwendige Flexibilität für komplexe Projekte verleihen sollen (Cohn, 2010). Diese Rahmenbedingungen sind über die vier Leitsätze und zwölf Prinzipien agiler Entwicklung im agilen Manifest (Beck et al., 2001) definiert worden. Agile Entwicklung ist demnach eher eine Sammlung von Ansätzen und kann deshalb nicht ohne weiteres als eigenständiges Vorgehensmodell bezeichnet werden. Sommerville (2011) erklärt agile Entwicklung aus diesem Grund zu einer Philosophie, da sie ebenso wie eine Philosophie darüber informiert, wie Methoden letztendlich umgesetzt und angewandt werden sollten. Eine Philosophie ähnelt damit zwar stark einem Vorgehensmodell, distanziert sich aber dadurch, dass die Vollständigkeit und Detailtiefe eines konkreten Modells nicht beansprucht wird. In dieser Arbeit wird die agile Softwareentwicklung dennoch als eigenständiges Vorgehensmodell behandelt.

Die großen Unterschiede der agilen Softwareentwicklung zu anderen Vorgehensmodellen bestehen in den wenigen Regeln, leichtgewichtigen Definitionen und Dokumentationen, sowie der hohen Kollaboration und Änderungsfreudigkeit (Broy & Kuhrmann, 2013). Damit positioniert sich die agile Softwareentwicklung zumindest teilweise als „Gegensatz zu sogenannten schwergewichtigen Vorgehensweisen mit hohem Regelungs­und Organisationsaufwand" (Broy & Kuhrmann, 2013, S. 97). „Agile Ansätze verfolgen die Technik, Anforderungen zu partitionieren. Die Anforderungen für später zu liefernde Teile brauchen erst später festzustehen.“ (Goll & Hommel, 2015). Dazu legt die agile Softwareentwicklung den Fokus auf eine hohe Zufriedenheit des Auftraggebers, die durch schnelle Auslieferung qualitativ hochwertiger Software, aktive Teilnahme der Beteiligten und dem Schaffen von Verbesserungen erreicht werden soll (Highsmith & Highsmith, 2002).

Diese Unterschiede ermöglichen einen schnelleren Austausch über Probleme und Hindernisse, die folglich auch schneller berücksichtigt und behoben werden können. Im Gegensatz zu einer Wasserfall-Organisation findet die Kommunikation gleichmäßig verteilt über die gesamte Projektlaufzeit statt. Quantitativ unterscheidet sich die Kommunikation aber nicht von einem Projekt gleicher Laufzeit unter Wasserfall-Organisation (Klünder, Handke, Gfesser, Schneider, & Kauffeld, 2017). Der entscheidende Unterschied besteht aber in der Aktualität der kommunizierten Inhalte, die unter agiler Organisation stets auf dem neusten Stand sind und somit Aspekte berücksichtigen können, die erst im Laufe der Entwicklung auftreten.

Weiterhin wird Agilität durch eine enge Zusammenarbeit mit dem Auftraggeber und dem Abbau von Bürokratie erreicht (Cohn, 2010). Die aktive Einbeziehung des Auftraggebers in den Entwicklungsprozess bedeutet schnellere Entscheidungen durch direkte Kommunikation, kürzere Entscheidungswege und schnelles Feedback (Lindvall et al., 2002). Iterative Vorgehensmodelle beziehen zwar ebenfalls die Meinung des Auftraggebers mit ein, jedoch begrüßt die agile Softwareentwicklung eine deutlich stärkere Zusammenarbeit, die bei manchen agilen Methoden so weit gehen kann, dass Mitarbeiter des Auftraggebers vor Ort in der Softwareentwicklung vorgesehen sind (vgl. Beck & Gamma, 2000).

Flachere Hierarchien ermöglichen kürzere Entscheidungswege, betonen eine hohe Kollaboration und legen die Verantwortung mehr in die Hände der Mitarbeiter. Highsmith und Highsmith (2002) beschreiben die Perspektive agiler Methoden deshalb insgesamt als chaordisch, einer harmonischen Koexistenz von Chaos und Ordnung, da sie ähnliche kollaborative Werte und Prinzipien teilen die von sich aus eine grobe Ordnung ermöglichen und dadurch gleichzeitig ein positives Chaos aufrechterhalten. Die Mitarbeiter können sich dadurch kreativer verhalten, was vor allem für eine Lösungsfindung notwendig ist.

Dies stellt einen weiteren Faktor dar, der das Überleben des Projektes im komplexen Bereich sichert. Der Entwicklungsprozess muss einen ständigen Lernprozess umfassen, damit sich das Wissen im Unternehmen für Lösungsfindungen und Innovationen frei bewegen kann (McLaughlin, 2007). Projekte des komplexen Bereiches, die versucht wurden mittels traditioneller Vorgehensmodelle zu bearbeiten, scheiterten unter anderem an dieser fehlenden Lösungsfindung (vgl. Jarzombek, 1999).

Um noch mehr Agilität erreichen zu können, muss die entwicklungsbegleitende Bürokratie abgebaut werden, weil „jede Art einer ausführlichen Dokumentation den Fortschritt hemmt und Änderungen unterbindet, da bei Änderungen viele Dokumente aus Zeitdruck in der Praxis gar nicht nachgezogen werden können.“ (Cohn, 2010, S.79). Das ist eines der großen Nachteile des inkrementellen Entwicklungsmodells, welches schnell zum Opfer des steigenden Dokumentationsaufwands werden kann. Agile Softwareentwicklung versucht diesen Aufwand von Anfang an zu minimieren. Es ist ein Missverstehen agiler Ansätze, dass keine Dokumentation erstellt werden muss, um höchstmögliche Agilität erreichen zu können (Broy & Kuhrmann, 2013). In jedem Fall geht mit dem Abbau der Bürokratie und der damit hauptsächlich einhergehenden leichteren Dokumentation auch Sicherheit verloren (Cohn, 2010), die unter anderem bei der Entwicklung von Systemen hoher Kritikalität notwendig sein kann oder vertragsrechtlich sogar erforderlich ist (Broy & Kuhrmann, 2013).

Die Entwicklung agiler Softwareentwicklung wird über den aktuellen Stand sicherlich noch fortgeführt werden. Gartner Inc. (2009) stufte den Stand agiler Softwareentwicklung 2009 als „Early Mainstream“ ein und prophezeite, dass es noch ca. fünf bis zehn Jahre dauern sollte, bis das „Plateau of Productivity“ erreicht sei, mit dem auch die Akzeptanz des Modells einhergeht. Diese Zeit ist nun weitestgehend vergangen und nach den Ergebnissen von VersionOne (2016), setzten 2016 bereits 95 % der Unternehmen agile Prozesse ein.

Eine genauere Vorstellung von der agilen Softwareentwicklung sollen die 2001 definierten Prinzipien und Werte des agilen Manifests geben, die im Folgenden vorgestellt werden.

2.3.1. Prinzipien und Werte

Um die 90er Jahre herum entstanden Methoden, die den bisherigen Vorgehensmodellen nicht direkt zugeordnet werden konnten. Zu diesem Zeitpunkt sprach noch niemand von agiler Softwareentwicklung. Diese Methoden wurden als Antwort auf die mäßigen Projekterfolge hin formuliert und sie zogen die Aufmerksamkeit vieler Projektmanager und Softwareentwickler schnell auf sich. Über zehn Jahre nach Veröffentlichung dieser ersten neuartigen Methoden trafen sich die Autoren und Softwareentwickler im Jahr 2001 in Utah, um Richtlinien dieser neuen Vorgehensweise zu definieren. Das Ergebnis waren vier Werte und zwölf Prinzipien, die als Manifest für Agile Softwareentwicklung (Beck et al., 2001) veröffentlicht wurden. Durch diese retrospektive Formulierung wurde diesen neuartigen Methoden zumindest ein konkreter Name gegeben: Agile Softwareentwicklung.

Das Ergebnis dieses Manifests war, dass eine agile Softwareentwicklung diese vier Werte und zwölf Prinzipien berücksichtigen muss, um sich agile Softwareentwicklung nennen zu können. Im Folgenden werden diese Werte und Prinzipien interpretiert, da das Manifest selbst keine Erklärungen liefert.

Werte agiler Softwareentwicklung

Das Manifest für agile Softwareentwicklung beschreibt die Werte wie folgt:

„ Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Funktionierende Software mehr als umfassende Dokumentation

Zusammenarbeit mit dem Kunden¹⁰ mehr als Vertragsverhandlung

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein. “ (Beck et al., 2001).

Obgleich die Werte auf der linken Seite über die der rechten Seiten gestellt werden, so müssen trotzdem beide Seiten berücksichtigt und wertgeschätzt werden. Beispielsweise würde eine Entwicklung unter vollständiger Missachtung von Prozessen und Werkzeugen leiden. Diese Wertehierarchie soll jedoch hervorheben, dass Softwareentwicklung nicht durch starre Prozesse oder übermäßige Bürokratie formalisiert werden sollte, da genau dieser Umstand zum Misserfolg bisheriger Vorgehensmodelle geführt hat.

Eine gute Softwareentwicklung lebt hingegen von den beteiligten Individuen und ihren Interaktionen. Das Ziel, vor allem nützliche Software auszuliefern, gelingt bei komplexen Projekten nur durch die Zusammenarbeit mit dem Auftraggeber und durch das Reagieren auf Veränderungen. Dadurch distanziert sich die agile Entwicklung am deutlichsten vom Wasserfall-Modell und versucht mittels der vier Werte den Fokus der Softwareentwicklung mehr auf das Ziel bzw. auf das Ergebnis anstelle des Weges zu legen. Letztendlich soll der Weg flexibel entsprechend der Situation von den Individuen gewählt werden, wenn sich das Ziel durch die Zusammenarbeit mit dem Auftraggeber verändert. Schwergewichtige Dokumentationen, vertraglich exakt festgelegte Pläne, Prozesse und Werkzeuge nehmen der Softwareentwicklung andernfalls die Möglichkeit, den besten Weg zum Ziel in unvorhergesehenen Situationen zu finden.

Seit der Veröffentlichung des Manifests werden diese Werte jedoch nicht immer richtig interpretiert. Nach Beck (2011) ist es wichtig, dass zwar auch die bisherigen Werte berücksichtigt werden, aber das Ziel der bisherigen Werte wird offenbar häufig außer Acht gelassen. Damit der Fokus auf die wichtigen Merkmale gelenkt wird, beschrieb Beck im Jahr 2011 eine überarbeitete Version des agilen Manifests als das Beyond Agile Manifest (Beck, 2011). Er greift dabei die bisherigen vier Werte auf und erweitert diese jeweils um eine höhere Ebene:

„Team vision anddiscipline over individuals andinteractions (overprocesses andtools)

Validated learning over working software (over comprehensive documentation)

Customer discovery over customer collaboration (over contract negotiation)

Initiating change over responding to change (over following aplan)” (Beck, 2011).

Das Ziel des ersten Wertes sollte sein, dass das Team eine gemeinsame Vision vom Ergebnis und dessen Qualität hat sowie diszipliniert arbeitet. Das könne durch einen guten Umgang untereinander und einem allgemeinen Fokus auf die Individuen erreicht werden. Lockere Prozesse und eine freiere Wahl der Werkzeuge sollten letztendlich die Freiheit geben, das Ziel bzw. den Zielzustand zu erreichen und zu halten.

Der Entwicklungsprozess, der gemäß dem zweiten Wert vor allem funktionierende Software produzieren soll, verbessert sich nicht von allein. Dieser Prozess kann deutlich effizienter werden, wenn aus den bisherigen Entwicklungen gelernt wird. Praktiken, wie regelmäßige Code-Reviews, verbessern die Qualität und beschleunigen die Lösungsfindung bei bekannten Problemen.

Der dritte Wert spricht an, dass eine starke Zusammenarbeit mit dem Auftraggeber allein nicht ausreicht, um die Zufriedenheit des Auftraggebers mit dem Produkt zu adressieren. Der Auftraggeber kann nur dann ein nützliches Produkt bekommen, wenn die Anforderungen aktiv erforscht werden. Zusammen mit dem vierten Wert soll dabei nicht erst passiv auf Änderungswünsche gewartet werden. Dem Auftraggeber soll das Potential der Software offenbart werden, damit er es voll ausschöpfen kann.

Ob eine Softwareentwicklung alle vier Werte berücksichtigt, lässt sich fast nur durch nähere Betrachtung des Entwicklungsprozesses sagen. Aus einer konkreten agilen Methode sollten jedoch alle vier Werte bereits formal ablesbar sein.

Prinzipien agiler Softwareentwicklung

Zusätzlich zu den vier Werten haben die Autoren des Agilen Manifests die folgenden zwölf Prinzipien definiert:

„ Wir folgen diesen Prinzipien:

1 Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
2 Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
3 Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
4 Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
5 Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
6 Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
7 Funktionierende Software ist das wichtigste Fortschrittsmaß.
8 Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
9 Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
10 Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell.
11 Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
12 In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an. “ (Beck et al., 2001).

Diese Prinzipien definieren einerseits den Rahmen, in dem agile Softwareentwicklung betrieben werden sollte und stellen andererseits konkrete Forderungen für Methoden. Frühe und kontinuierliche Auslieferungen (aus Prinzip 1 und 3) verweisen bereits auf ein iteratives Vorgehen. Die Möglichkeit für Anpassungen und Änderungen in der laufenden Entwicklung (aus Prinzip 2 und 11) unterstreichen das zusätzlich. Die Auslieferung wertvoller und funktionierender Software (aus Prinzip 1 und 3) stellt eine Abgrenzung zum Spiralmodell dar, in denen der funktionelle Einsatz der Prototypen nicht vorgesehen ist. Die agile Softwareentwicklung strebt hiermit einen schnellen Return-On-Investment an, sodass der Auftraggeber schnell ein einsatzfähiges Produkt bekommt. Ein weiteres Kernelement ist die Abwendung von der tayloristischen Perspektive hin zu einer humanistischen, mitarbeiterzentrierten Softwareentwicklung (aus Prinzip 4, 5, 6, 11 und 12) (vgl. Chau & Maurer, 2004; Dings0yr, et al., 2012). Die Interaktion wird gezielt zwischen den Projektbeteiligten gefördert, die Mitarbeiter werden unterstützt, ihnen wird Vertrauen entgegengebracht und sie genießen viele Freiheiten in ihrer Arbeitsgestaltung. Damit die Softwarequalität unter all den Freiheiten nicht außer Acht gelassen wird, schreibt das Manifest eine nachhaltige Entwicklung vor, mit ständigem Augenmerk auf der Qualität des Produktes und auf die Effektivität der Entwickler (aus Prinzip 8, 9 und 12). Unabhängig davon sollen die Entwickler auch nur die Anforderungen umsetzen, die umgesetzt werden müssen (aus Prinzip 7). Durch diese Prinzipien soll die Entwicklung funktionierender Software gewährleistet werden, die sogleich das Maß des Erfolgs darstellt (aus Prinzip 7).

Nach Veröffentlichung des agilen Manifests wurde zunehmend der Versuch unternommen, die agile Softwareentwicklung zu definieren. Die Ergebnisse werden im folgenden Abschnitt vorgestellt.

2.3.2. Definitionen agiler Softwareentwicklung

Nerur und Balijepally (2007, S.81f), erklären die agile Softwareentwicklung wie folgt: „ The trend in management thinking, moving from a deterministic/mechanistic view of problem solving to a dynamic process, characterized by iterative cycles and the active involvement of all stakeholders, is reflected in software development as well. The “emergent metaphor of design” in the table is manifest in the agile methods in today's emerging software-development thinking. Agile methods are people-centric, recognizing the value competent people and their relationships bring to software development. In addition, it focuses on providing high customer satisfaction through three principles: quick delivery of quality software; active participation of concerned stakeholders; and creating and leveraging change. Big upfront designs/plans and extensive documentation are of little value to practitioners of agile methods. Important features of this approach include evolutionary delivery through short iterative cycles — of planning, action, reflection — intense collaboration, self-organizing teams, and a high degree of developer discretion. “.

Agile Softwareentwicklung ist nach Collier (2012) ein Ansatz um Software zu entwickeln, bei dem sich die Anforderungen und die Lösungen über die Zusammenarbeit von sich selbst-organisierenden und multifunktionalen Teams, dem Auftraggeber und den Nutzern entwickelt. Durch den Einsatz von adaptiven Planungen, evolutionärer Entwicklung, frühen Auslieferungen und kontinuierlichen Verbesserungen begünstigt dieser Ansatz eine schnelle und flexible Reaktion auf Änderungen (Herzog, 2015).

Agile Softwareentwicklung stellt für Ambler (2011) hingegen ein Modell der Softwareentwicklung dar, deren Methoden einem iterativen und inkrementellen Ansatz folgen, die es ermöglichen, durch regelmäßiges Feedback (Subramaniam & Hunt, 2006), wenigen effizienten Regeln ohne schwergewichtige Softwarebürokratie (Cockburn, 2001) und einer hochfrequenten face-to-face Kommunikation zwischen allen Projektbeteiligten (Vasiliauskas, 2014) schnell und flexibel auf Änderungen reagieren zu können (Larman, 2004).

Einzeln betrachtet, beschreibt leider keine Definition den Charakter vollständig, obwohl die Definition von Nerur und Balijepally (2007) bereits sehr umfassend ist. „ Letztendlich ist Agilität nicht präzise definiert.“ (Goll & Hommel, 2015, S.73) und das, obwohl die ersten Methoden bereits seit den 90er Jahren eingesetzt werden.

Die meisten publizierten Definitionen verweisen einfach auf die eher schwammig formulierten zwölf Prinzipien und vier Werte des agilen Manifests (Laanti et al., 2013). Laanti et al. (2013) analysierten und kategorisierten komplette Definitionen, mit dem Ergebnis, dass alle analysierten Definitionen unterschiedliche Aspekte und diese auch unterschiedlich stark beschrieben. Die Werte und Prinzipien des Manifests werden seitdem in nachfolgenden Publikationen unterschiedlich interpretiert. Beispielweise hebt ein agiles Prinzip die Effizienz hervor, wozu Goldman bereits Jahre vor dem Agilen Manifest in seiner Definition schrieb, dass agil zu sein nicht zwingend etwas mit Effizienz zu tun haben muss (Goldman, 1994). Es ist ebenso ein Missverständnis, wenn mit Verweis auf Agilität argumentiert wird, dass in einem Projekt keine Dokumentation erstellt werden muss, weil die Dokumentation als untergeordneter Wert im Manifest definiert wurde (Broy & Kuhrmann, 2013). Als letztes Beispiel wird das Prinzip der täglichen Zusammenarbeit von Cockburn (2006) lediglich in Form von starker Kommunikation bezeichnet, wohingegen Ambler (2007) von Kollaboration spricht. Laanti et al. (2013) erklären, dass gerade solche Unterschiede zu Verwirrung größerer Organisationen führen können und verweisen zusätzlich auf widersprüchliche Beschreibungen durch unterschiedliche Publikationen. Die Recherchen von Dern (2011) zur Definition agiler IT- Systeme kamen zum selben Ergebnis und brachten keine eindeutige und allgemein akzeptierte Definition hervor. Halamzie hebt nach Betrachtung verschiedener Definitionen noch hervor, „wie diffus der Begriff der Agilität in der Softwareentwicklung ist“ (Halamzie, 2013, S.15). Laanti et al. (2013) kommen nach umfangreicheren Analysen von zehn verschiedenen Definitionen zu dem Schluss, dass selbst die “Gurus“ der Szene Probleme haben, agile Softwareentwicklung zu definieren. Dennoch gibt es hinsichtlich einzelner Aspekte auch starke Überschneidungen zwischen den Definitionen. So konnten Lindner, Ott und Leyh (2017) mittels Literaturanalyse im Wesentlichen sieben Eigenschaften identifizieren: Schnelligkeit, Flexibilität, Anpassung, Dynamik, Vernetzung, Selbstorganisation und Vertrauen. Eine genaue Betrachtung mehrerer Definitionen verdeutlicht das Unterfangen, agile Softwareentwicklung über Analysen selbiger zu definieren. Nach Boehm und Turner (2003) darf sich eine wahre Methode agiler Softwareentwicklung erst als eine solche bezeichnen, wenn sie die folgenden Attribute vorweisen kann: Iterationen, Inkremente, selbstorganisierende Teams und Emergenz bei der sich die Arbeitsstruktur, Prozesse und Prinzipien erst während der Projektlaufzeit herauskristallisieren. Gebraucht wird eine adaptive Projektdurchführung, die fehlendes Wissen kompensiert und sich der jeweiligen Situation anpasst (Cohn, 2010).

2.3.3. Frameworks und Methoden

Viele Studien beschäftigen sich nur mit der Methode Extreme Programming (vgl. Beck & Gamma, 2000) und dem Framework Scrum (vgl. Schwaber & Beedle, 2002) und vernachlässigen dabei die Ansätze anderer Methoden und Frameworks (Dyba & Dings0yr, 2008). Darüber hinaus wird diskutiert, ob Frameworks wie Scrum, nicht eher eine Methode darstellen. Dies führt mitunter zur Verwechslung von Methoden, Frameworks und Vorgehensmodellen. Für ein umfassenderes Bild von agiler Entwicklung könnte der Vergleich von mehreren Methoden und Frameworks hilfreich sein.

Ein solcher umfassender Vergleich wurde von Abrahamsson et. al. (2017) unter anderem mit den Methoden Extreme Programming, Scrum, der Crystal Familie , Feature Driven Development, dem Rational Unified Process, Dynamic System Development und Adaptive Software Development durchgeführt. Sie kommen zu dem Schluss, dass die Methoden schwer vergleichbar sind, weil sie die Probleme der Softwareentwicklung jeweils aus einer anderen Perspektive angehen, sowie unterschiedlich stark beschrieben und erprobt sind. In der Literatur wird auch zu keiner einzigen agilen Methode erklärt, wie diese vollständig implementiert werden kann (Abrahamsson et al., 2017). Die Einführung einer agilen Methode kann sich demnach schwer gestalten und ein Wechsel zwischen zwei Methoden wäre ebenso schwer umsetzbar, auch wenn beide Methoden der agilen Softwareentwicklung zugeschrieben werden.

Diese Bedingung, ob Methoden, die aktuell der agilen Softwareentwicklung zugeschrieben werden, überhaupt die Werte und Prinzipien des Manifests erfüllen, wird in der aktuellen Methodenlandschaft nicht immer erfüllt oder zumindest kontrovers diskutiert. Extreme Programming wird in diesem Zusammenhang häufig kritisiert (vgl. McBreen, 2002), ist dabei aber nicht die einzige Methode, deren Zuordnung angefochten wird. Es wirkt dem Verständnis agiler Softwareentwicklung ebenso entgegen, dass Methoden und Prinzipien von den Vertretern agiler Entwicklung bewusst verwechselt werden, damit keine umfangreichen Methodenbeschreibungen entstehen, die die Prinzipien überlagern könnten (Hüsselmann, 2014).

Historisch betrachtet entstanden die Methoden und Frameworks in den zwei Jahrzehnten vor dem Agilen Manifest. Da die Werte und Prinzipien des Agilen Manifests bereits den Methoden und Frameworks entlehnt sind, ist eine nähere Betrachtung selbiger im Rahmen dieser Arbeit nicht sinnvoll. Dazu kommt, dass manche Methoden auf vorherigen agilen Methoden aufbauen. So schrieb Kent Beck in der Entwicklung von Extreme Programming 1995 eine Mail an Jeff Sutherland, dem Autor von Scrum, mit dem Inhalt: „ Is there a good place to get reprints of the SCRUM paper from HBR? I've written patterns for something very similar andI want to make sure I steal as many ideas as, possible.“ (Sutherland, 2005).

Nichtsdestotrotz ist Kent Beck neben Jeff Sutherland auch einer der Autoren des Agilen Manifests und hat zur Definition der Werte und Prinzipien beigetragen. Jedoch müssen Methoden, die der agilen Softwareentwicklung angehören wollen, die Werte und Prinzipien des Manifests einhalten. Andernfalls könne beim Einsatz dieser Methoden nicht von agiler Softwareentwicklung gesprochen werden. Es scheint allerdings, als teilen die agilen Methoden selbst nicht einmal die nachträglich daraus abgeleiteten Werte und Prinzipien. Deshalb ist eine nähere Betrachtung der einzelnen Methoden für die Erarbeitung einer Arbeitsdefinition agiler Softwareentwicklung nicht zielführend.

2.3.4. Praktiken

Die Methoden agiler Softwareentwicklung schreiben stellenweise schon den Einsatz bestimmter Praktiken vor. Scrum hat bspw. tägliche kurze Meetings, sogenannte Daily Standups, fest in den Entwicklungsprozess integriert. Die Praktiken beschreiben auf der untersten Projektorganisationsebene, wie die Planung ablaufen sollte und verhelfen der agilen Methode zu noch mehr Agilität. Bekannte Praktiken sind Daily Standup Meetings, Retrospektive Bewertungen, Reviews, Road- und Storymapping, sowie regelmäßige Auslieferungen und kurze Iterationen. Daneben gibt es noch viele weitere Praktiken, die aber aufgrund ihrer hierarchischen Einordnung unter dem Vorgehensmodell folglich auch den Werten und Prinzipien des agilen Manifests folgen müssten. Beispielsweise sind regelmäßige Auslieferungen und kurze Iterationen aufgrund des Agilen Manifests ein fester Bestandteil jeder agilen Methode und damit auch von der agilen Softwareentwicklung als Vorgehensmodell. Eine genauere Betrachtung der Praktiken ist für die Erarbeitung einer Arbeitsdefinition agiler Softwareentwicklung also auch nicht zielführend.

2.4. Vorgehensmodelle im Vergleich

In der Literatur werden häufig nur traditionelle Vorgehensmodelle der agilen Softwareentwicklung gegenübergestellt. Was dabei “traditionell“ ist, wird selten erklärt. In diesem Abschnitt sollen alle in dieser Arbeit genannten Vorgehensmodelle zumindest hinsichtlich ihrer Agilität beurteilt werden. Die Vorgehensmodelle können darüber hinaus anhand weiterer Eigenschaften verglichen werden, die für die Projektorganisation jedoch bei weiterem nicht so wichtig sind wie die Agilität. Letztendlich haben sich die Modelle nach dem Phasenmodell meist hin zu einem Mehr an Agilität aufgrund steigender Komplexität weiterentwickelt. Das heißt wiederum, dass die Modelle in einer Agilitäts-Reihenfolge stehen, was Boehm (2002) mit dem sogenannten Planning Spectrum zumindest grob visualisierte. Dieses Planning Spectrum wird in Abbildung 4 dargestellt und beschreibt eine Dimension, die von rechts nach links Modelle oder eher Vorgehensweisen mit wenig Agilität hin zu jenen mit extremer Agilität einordnet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Planning Spectrum aus Boehm (2002, S.65).

[...]

---

¹ Eine Abbildung des Nine-phase stage-wise Modells ist im Anhang A dargestellt.

² Eine Abbildung des inkrementellen Modells ist im Anhang Anhang A dargestellt.

³ Speziell zum Feedback wird in der Literatur nicht klar abgegrenzt, ob dies vom Auftraggeber oder von den Nutzern der Software eingeholt werden sollte, wobei Feedback von den Nutzern klar favorisiert wird (vgl. Mills, 1976). In der Praxis kommt es auf die genaue Situation an, in der sich das entwickelnde Unternehmen befindet. Stellt das entwickelnde Unternehmen auch den Auftraggeber dar, z.B. bei internen Projekten, dann kann Feedback meist direkt von den Nutzern eingeholt werden. Bei externen Auftraggebern sind die Nutzer jedoch nicht immer zugänglich, z.B. wenn dies die Mitarbeiter des Auftraggebers sind. In diesem Fall wird die Aufgabe, Feedback von den Nutzern einzuholen, häufig an den Auftraggeber übertragen, der das Feedback an die Entwicklung weiterleitet. In dieser Arbeit werden Auftraggeber und Nutzer im Zusammenhang mit Feedback so wiedergegeben, wie sie auch in den angegebenen Quellen verwendet werden. Die Begriffe sind jedoch synonym zu verstehen.

⁴ Eine Abbildung des iterativen Modells ist im Anhang Anhang A dargestellt.

⁵ Eine Abbildung des iterativ-inkrementellen Modells ist im Anhang Anhang A dargestellt.

⁶ Eine Abbildung des Wasserfall-Modells ist im Anhang Anhang A dargestellt.

⁷ Eine Abbildung des V-Modells ist im Anhang A dargestellt.

⁸ Eine Abbildung des Cleanroom-Modells ist im Anhang Anhang A dargestellt.

⁹ Eine Abbildung des Spiralmodells ist im Anhang Anhang A dargestellt.

¹⁰ Die Literatur um agile Softwareentwicklung verwendet die Begriffe Kunde und Auftraggeber synonym, da sie nicht näher zwischen den Begriffen unterscheidet. In dieser Arbeit wird der Begriff Auftraggeber ebenfalls synonym für Kunde verwendet.