Vergleich der klassischen und agilen Vorgehensmodelle in der IT Branche

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1. Einleitung
1.1. Problemstellung
1.2. Zielsetzung
1.3. Aufbau und Methodik

2. Grundlagen
2.1. Definition und Entwicklung der Vorgehensmodelle
2.2. Klassische Vorgehensmodelle
2.3. Das Wasserfallmodell
2.4. Agile Vorgehensmodelle
2.5. Scrum
2.5.1.1. Projektrollen
2.5.1.2. Sprints
2.5.1.3. Artefakte

3. Vergleich der klassischen und agilen Vorgehensmodelle in der IT-Branche

4. Fazit

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Tabellenverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

1.1. Problemstellung

Die IT-Branche ist ständigen Veränderungen ausgesetzt. Software wird mittlerweile in allen Lebensbereichen eingesetzt und ist nicht mehr wegzudenken. Dementsprechend steigen auch die Anforderungen an die Ersteller von Software. Diese stehen verschiede- nen gesteigerten Anforderungen gegenüber wie zum einen der Anspruch hinsichtlich einer hohen Zuverlässigkeit sowie gleichzeitig die Sicherstellung der Verfügbarkeit der Systeme, welche innerhalb kürzester Zeit erstellt werden müssen.1 Deshalb erfolgt die Erstellung neuer Software meist innerhalb eines Projektes. Doch es gibt genügend Bei- spiele bei denen IT-Projekte nicht erfolgreich verlaufen sind. So hat Ford 200 Mio. US- Dollar in ein Projekt zur Erneuerung der vorhandenen Software investiert, um nach drei Jahren zum altbewehrten zurückzukehren.2 Da es noch viele weitere dieser Beispiele gibt, stellt sich die Frage, wie Projekte erfolgreich gestaltet werden können. Einen An- satz dafür sind die Vorgehensmodelle im Projekt. Hier wird nach klassischen und agilen Vorgehensmodellen unterschieden. Seit Jahren steigen die Bedeutung und der Einsatz von agilen Vorgehensmodellen gerade auch in der IT-Branche und der Einsatz der klas- sischen Vorgehensmodelle wird geringer.3 Die vorliegende Ausarbeitung befasst sich genau mit diesen zwei Vorgehensmodellen.

1.2. Zielsetzung

Das Ziel der vorliegenden Arbeit ist es ein grundlegendes Verständnis für die klassi- schen und agilen Vorgehensmodelle in der IT-Branche zu vermitteln und deren Unter- schiede, sowie deren Vor- und Nachteile genauer erklären. Die zugrundeliegende For- schungsfrage dieser Arbeit lautet: Welches Vorgehensmodell ist für die IT-Branche besser geeignet?

1.3. Aufbau und Methodik

Die vorliegende Arbeit vergleicht die klassischen und agilen Vorgehensmodelle in der IT-Branche. Nachdem dazu im ersten Kapitel zuerst die Problemstellung und die Ziel- setzung der Arbeit definiert wurden, erfolgt im zweiten Kapitel eine Definition der Grundlagen. Dabei wird zuerst der Begriff Vorgehensmodell genauer beschrieben, was auch eine Darstellung der Entwicklung der Vorgehensmodelle beinhaltet. Anschließend werden die klassischen und agilen Vorgehensmodelle dargestellt. Das erfolgt jeweils an einem beispielhaften Vorgehensmodell. Für die klassischen Vorgehensmodelle stellt das Wasserfallmodell das Beispiel dar und im Fall der agilen Vorgehensmodelle ist dies Scrum. Im dritten Kapitel erfolgt ein Vergleich der beiden Modelle für die IT-Branche und die Forschungsfrage dieser Arbeit wird beantwortet. Abschließend erfolgt im vier- ten Kapitel das Fazit der vorliegenden Ausarbeitung und es erfolgt ein Ausblick auf weiterführende Themen.

2. Grundlagen

2.1. Definition und Entwicklung der Vorgehensmodelle

Um den Begriff des Vorgehensmodells genauer zu definieren, wird zuerst der Begriff des Projektes in der IT-Branche definiert. Nach Wieczorrek und Mertens hat ein Projekt eine klare Definition der Aufgabe, ist abgegrenzt von den operativen Unternehmensauf- gaben, besitzt einen eindeutigen Start- und Endtermin und ist einzigartig oder wurde noch nicht in dieser Form durchgeführt.4 Bei einem IT-Projekt spielt der Mitarbeiter noch eine wichtige Rolle, da dieser ab einem bestimmten Status nicht mehr problemlos ausgetauscht werden sollte. Weiterhin gibt es in IT-Projekten immer wieder gleichartige Phasen, die eine Anwendung eines standardisierten Vorgehens ermöglichen.5 Die sys- tematisierte und detaillierte Beschreibung der nacheinander folgenden Prozessschnitte wird als Vorgehensmodell bezeichnet. Das Vorgehensmodell beinhaltet den organisato- rischen Ablauf bei einer Softwareentwicklung und soll klären, was zu welchem Zeit- punkt zu tun ist.6 Zusammengefasst beinhalten Vorgehensmodelle genau definierte Schrittfolgen im Entwicklungsprozess und bieten eine Orientierungshilfe und Regeln, welche beschreiben, in welcher Form das Endprodukt vorliegen soll.7

Bereits im Jahr 1951 hat Alan Turning das erste einfache Vorgehensmodell mit vier Schritten beschrieben. Zuerst muss ein Plan erstellt werden, anschließend muss das Problem aufgeschlüsselt werden, dann sollen die Programmierung neuer Unterpro- gramme erfolgen und abschließend die Hauptprogrammierung.8 Im Jahr 1970 beschrieb Winston Royce dann ein sequentielles Vorgehensmodell, welches die Grundlage für die später folgenden Wasserfallmodelle bildet. In seinem Vorgehensmodell laufen die Ent- wicklungsphasen nacheinander ab, er beinhaltet allerdings auch die Möglichkeit, dass zu einer vorherigen Phase zurückgesprungen werden kann.9 In den achtziger Jahren wurden die Prozesse zur Softwareentwicklung kritischer betrachtet und es wurde Ver- besserungspotential entdeckt. Als Anstoß für die kritischere Betrachtung der Prozesse gilt die Softwarekrise.10 In der Softwarekrise nahm die Softwareentwicklung ein Aus- maß an, das zu hohen Entwicklungs- und Wartungskosten führte. Diese Krise konnte durch Standardisierungen und die Einführung systematischer Entwicklungsprozesse beruhigt werden.11 In den folgenden Jahren wurden detailgenaue Vorgehensmodelle entwickelt, welche allerdings auf geringe Akzeptanz bei den Entwicklern gestoßen sind.12 Deshalb wurden in den neunziger Jahren viele neue Methoden entwickelt, die den Grundstein für die agilen Vorgehensmodelle bilden. Im Jahr 2001 entstand dann bei einem Treffen von 17 Vertretern der bekanntesten Vorgehensmodelle die Bezeichnung der agilen Methoden und die Leitsätzen und Prinzipien für agile Softwareentwicklung wurden im Agilen Manifest festgehalten.13 Die klassischen und die agilen Vorgehens- modelle werden nun im weiteren Verlauf der Ausarbeitung genauer beschrieben.

2.2. Klassische Vorgehensmodelle

Die Autoren Walter Ruf und Thomas Fittkau bezeichnen die klassischen Vorgehensmo- delle auch als sequentielle Vorgehensmodelle und vergleichen diese mit dem Vorgehen bei einem Hausbau. Sie werden genutzt, wenn es sich um einmalige Projekte handelt, bei denen die Ausgangslage und das Ziel klar formuliert werden können. Sie beschrei- ben den Weg zum Ziel, der einmalig durchlaufen wird. Der Ablauf besteht aus einer Folge von Zyklen, die nacheinander durchlaufen werden. Je nach Vorgehensmodell und Autor unterscheiden sich die Anzahl und der Inhalt der Phasen.14 Als Beispiel zur Dar- stellung eines solchen Vorgehensmodells soll Abbildung 1 dienen. Das Projekt startet mit der Phase der Spezifikation und nachdem diese erfolgt ist, geht es über in die Ent- wurfs-Phase. Sobald diese beendet ist geht, erfolgt die Implementierung. Darauf folgt die Integration und abschließend die Einführung, sodass zum Enden hin alle Phasen durchlaufen sind.

Abbildung 1: Sequentielles Vorgehensmodell

Abbildung in dieser Leseprobe nicht enthalten

Quelle: In Anlehnung an Ruf, W., Fittkau, T., IT-Projektmanagement, 2008, S. 30.

Bezeichnend für sequentielle Vorgehensmodelle ist ein Phasenprodukt, welches am Ende jeder Phase kontrolliert werden kann. Weiterhin kann die nächste Phase erst gestartet werden, sobald die vorherige mit abschließendem Phasenprodukt abgeschlossen ist und das Endprodukt anhand der zu Beginn aufgestellten Anforderungen kontrolliert werden kann. Der Einsatz dieser Modelle ist besonders dann ratsam, wenn die Anforde- rungen von Anfang an feststehen und während der Projektlaufzeit nicht mehr mit Ände- rungen zu rechnen ist.15 Neben dem Wasserfallmodell, welches im nächsten Kapitel genauer beschrieben wird, zählen das V-Modell und das Spiralmodell als weitere klas- sische Vorgehensmodelle.16

2.3. Das Wasserfallmodell

Als Beispiel eines klassischen Vorgehensmodells soll an dieser Stelle das Wasserfall- modell genauer beschrieben werden. Es ist aufgrund seiner einfachen Form und des geringen Managementaufwands ein oft genutztes Modell. Dabei wird, wie bei sequenti- ellen Vorgehensmodellen üblich, der Entwicklungsprozess in mehrere Phasen unterteilt, die nacheinander abgearbeitet werden und an deren Ende das fertige Endprodukt steht.17

In seiner Ursprungsform besteht das Modell aus den fünf Phasen Anforderungsanalyse, Grobdesign, Feindesign, Implementierung sowie Test und Integration, die nacheinander angeordnet sind. Daher stammt auch der Name des Modells, da die Phasen wasserfallar- tig aufgebaut sind. Die Einfachheit des Modells ist dadurch begründet, dass jede Phase auf den Ergebnissen der vorherigen Phase aufbaut und die einzelnen Phasen direkt einer groben Projektplanung entsprechen. Am Ende jeder Phase steht ein erreichter Meilen- stein, der als Abschluss für die jeweilige Phase gilt.18 Zu Beginn des Projektes werden während der Anforderungsphase alle Anforderungen an das Endprodukt gesammelt, welche während des Projekts nicht mehr geändert werden können. Das Ziel ist es, die Anforderungen des Kunden genauestens zu verstehen, damit dieser das Projekt nach seinem Abschluss als Erfolg ansieht.19 Im Grobdesign werden die Anforderungen des Kunden weiter präzisiert und in ein Modell für die Softwareentwicklung umgewandelt, welches im Feindesign weiter optimiert wird. In der Implementierungsphase erfolgt die Umsetzung des Feindesigns. Abschließend wird das Endprodukt in der Test- und Integrationsphase getestet und überprüft, ob alle Kundenwünsche erfüllt sind.20 Da jede Pha- se bei komplexeren Projekten nicht direkt erfolgreich abgeschlossen werden kann, wur- de die Möglichkeit eingebaut, bei nachträglichen Änderungen wieder in die vorherige Phase zu springen.21

2.4. Agile Vorgehensmodelle

Im Gegensatz zu den klassischen Vorgehensmodellen steht bei den agilen Vorgehens- modellen nicht die Dokumentation im Vordergrund, sondern die abschließende Funkti- onalität. Allerdings ist die Dokumentation nicht verboten, sondern hat lediglich eine geringere Gewichtung als bei den klassischen Vorgehensmodellen und soll in möglichst geringem Umfang erfolgen.22 Bei den agilen Modellen sollen schnelle Entwicklungser- gebnisse erzielt werden, um die Zeit bis zur Markteinführung so gering wie möglich zu halten. Im Gegensatz zu den klassischen Vorgehensmodellen kommt es innerhalb der Entwicklungszeit noch zu Änderungen der Anforderungen, welche jederzeit berücksich- tigt werden. So gibt es zu Beginn des Projektes keinen standardisierten Prozess, der strikt eingehalten wird, sondern dieser wird ständig an die aktuellen Anforderungen angepasst.23 Die Vorgehensweise ist trotzdem nicht chaotisch.24 Die Anforderungen an das Projekt sollen in enger Abstimmung, am besten in persönlichen Treffen, zwischen Auftraggeber und Projektleiter erfolgen. Weiterhin sollte in relativ kleinen Teams von weniger als zehn Mitarbeitern gearbeitet werden.25 Im Jahr 2001 wurden von 17 Vertre- tern der bis dahin bekanntesten agilen Vorgehensmodelle vier Leitsätze im Manifest für agile Softwareentwicklung festgehalten. Diese vier Leitsätze beinhalten, dass Individu- en und Interaktionen höher wertgeschätzt werden als Prozesse und Werkzeuge, dass funktionierende Software wichtiger ist als eine umfassende Dokumentation, dass die Zusammenarbeit mit dem Kunden wichtiger ist als eine Vertragsverhandlung und dass das Reagieren auf Veränderungen wichtiger ist, als das Befolgen eines Plans.26 Neben den vier Leitsätzen wurden noch weitere zwölf Prinzipien erstellt, die das Vorgehen bei

[...]

¹ Vgl. Thomas, O., Varwig, A., Kammler, F., Zobel, B., Fuchs, A., DevOps, 2017, S. 179.

² Vgl. Roehrl, A., Schmiedl, S., Agil, 2004, S. 61.

³ Vgl. Komus, A., Kuberg, M., Status Quo, 2015, S. 7.

⁴ Vgl. Wieczorrek, H., Mertens, P., IT-Projekte, 2011, S. 9 f.

⁵ Vgl. Wieczorrek, H., Mertens, P., IT-Projekte, 2011, S. 11 f.

⁶ Vgl. Ruf, W., Fittkau, T., IT-Projektmanagement, 2008, S. 25.

⁷ Vgl. Schatten, A., Biffl, S., Demolsky, M., Gostischa-Franta, E., Österreicher, T., Winkler. D., Soft- ware, 2010, S. 47.

⁸ Vgl. Turning, A., Handbuch, 1951, S. 61 ff.

⁹ Vgl. Royce, W., Development, 1970, S. 330 ff.

¹⁰ Vgl. Kneuper, R., Historie, 2015, S. 31.

¹¹ Vgl. Zühlke, D., Useware, 2004, S. 4.

¹² Vgl. Kneuper, R., Historie, 2015, S. 32.

¹³ Vgl. Agile Manifest, Manifest, 2001a, S. 1; Kneuper, R., Historie, 2015, S. 33.

¹⁴ Vgl. Sandmann, C., Teschke, T., Ritter, J., Vorgehensmodell, 2000, S. 50; Ruf, W., Fittkau, T., IT- Projektmanagement, 2008, S. 29.

¹⁵ Vgl. Ruf, W., Fittkau, T., IT-Projektmanagement, 2008, S. 30

¹⁶ Vgl. Heinrich, G., Mairon, K., Systemanalyse, 2008, S. 2 f.

¹⁷ Vgl. Arndt, C., Hermanns, C., Kuchen, H., Poldner, M., Softwareentwicklung, 2009, S. 7; Trepper, T., Softwareprojektmanagement, 2012, S. 30.

¹⁸ Vgl. Kleuker, S., Grundkurs, 2011, S. 26.

¹⁹ Vgl. Kleuker, S., Grundkurs, 2011, S. 25; Trepper, T., Softwareprojektmanagement, 2012, S. 30 f.

²⁰ Vgl. Kleuker, S., Grundkurs, 2011, S. 25.

²¹ Vgl. Arndt, C., Hermanns, C., Kuchen, H., Poldner, M., Softwareentwicklung, 2009, S. 7; Kleuker, S., Grundkurs, 2011, S. 26.

²² Vgl. Hanser, E., Prozesse, 2010, S. 7; Ruf, W., Fittkau, T., IT-Projektmanagement, 2008, S. 37.

²³ Vgl. Ruf, W., Fittkau, T., IT-Projektmanagement, 2008, S. 36 f.

²⁴ Vgl. Hanser, E., Prozesse, 2010, S. 7.

²⁵ Vgl. Ruf, W., Fittkau, T., IT-Projektmanagement, 2008, S. 37.

²⁶ Vgl. Agile Manifest, Manifest, 2001a, S. 1.