Fallstudie: Klassisches Projektmanagement versus Scrum

Inhaltsverzeichnis

Vorwort

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

Abstract

1. Einleitung

2. Klassisches Projektmanagement und Scrum im Überblick

3. Methodik: Ablauf des klassischen Projektmanagements und Scrum im Vergleich
3.1 Planung
3.1.1 Anforderungsmanagement im klassischen Projektmanagement
3.1.2 Product Backlog und Sprintplanning in Scrum
3.1.3 Kritische Bewertung
3.2 Durchführung
3.2.1 Realisierungsablauf im klassischen Projektmanagement
3.2.2 Sprintablauf in Scrum
3.2.3 Kritische Bewertung
3.3 Testmanagement
3.3.1 Testmanagement im klassischen Projektmanagement
3.3.2 Testmanagement in Scrum
3.3.3 Kritische Bewertung
3.4 Auslieferung
3.4.1 Abnahme im klassischen Projektmanagement
3.4.2 Produktinkremente in Scrum
3.4.3 Kritische Bewertung

4. Klassisches Projektmanagement und Scrum in der Praxis
4.1 Ausgangslage
4.2 Ablauf des Projektes
4.3 Lösungsansatz mit Scrum

5. Fazit

Literatur- und Quellenverzeichnis

Vorwort

“…Wenn nun ein amerikanischer Arbeiter sein ‘Baseball’ oder ein englischer

Arbeit ‘Cricket spielt’, so wird er alle seine Kräfte anspannen, um seiner Partei zum Siege zu verhelfen; er tut sein allerbestes, so viele ‘Läufe’ als möglich zu machen. Das Gefühl der Solidarität ist so stark entwickelt, dass einer, der nicht alles hergibt, was an Leistungsfähigkeit in ihm steckt, als ‘Kneifer’ gebrandmarkt und mit allgemeiner Verachtung gestraft wird.
Am nächsten Tag kehrt derselbe Arbeiter zu seiner Arbeit zurück. Statt nun auch hier alle Kräfte anzustrengen, um möglichst viel zu leisten, wird er in den meisten Fällen mit dem Vorsatz beginnen, so wenig zu tun, als er, ohne

aufzufallen, tun kann …”

Frederick Winslow Taylor, vor rund 100 Jahren

Abbildungsverzeichnis

Abb. 1: Wasserfallmodell

Abb. 2: Überblick Scrum Ablauf

Abb. 3: Physikalisches Taskboard

Abb. 4: Überblick Scrum Rollen

Tabellenverzeichnis

Tab. 1: Teilprojekte der Fiktiv Bank AG: E-Akte

Tab. 2: Meilensteinplanung: Teilprojekt Nr. 1 e-Akte

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abstract

English

The classical project management and Scrum are two procedures to create software.

The waterfall lifecycle model shows the operation of the classical project management. In that case, the phases are horizontally ordered and are executed in succession.

It is only applicable, if it is possible to set the standards when starting the project. If mistakes are identified too late, they have to be removed with much energy. Because of the grave disadvantages, the waterfall lifecycle model with its demanding financial efforts, it is today not really convenient and is replaced by a variety of alternative and additional procedural methods such as Scrum.

The paper at hand compares the classical project management with Scrum and tries to solve an unsuccessful example of the practice.

German

Das klassische Projektmanagement und Scrum stellen zwei Vorgehensweisen zur Erstellung von Softwarelösungen dar. Das Wasserfallmodell gibt den Ablauf des klassischen Projektmanagements wider. In diesem sind die Phasen horizontal angeordnet und laufen nacheinander ab,

Es ist nur dann verwendbar, wenn es möglich ist, schon früh die Anforderungen festzuschreiben. Werden Fehler erst spät erkannt, müssen sie mit erheblichem Aufwand entfernt werden. Wegen der gravierenden Nachteile des Wasserfallmodells, die meist erhöhten finanziellen Aufwand bedeuten, hat das Wasserfallmodell heute kaum noch praktischen Wert und wurde in der IT-Industrie durch eine Vielfalt alternativer und ergänzender Vorgehensweisen, wie zum Beispiel Scrum, ersetzt.

Die vorliegende Studie vergleicht das klassische Projektmanagement mit Scrum und versucht damit ein gescheitertes Praxisbeispiel zu lösen.

1. Einleitung

Gegenwärtig ist der Geschäftsalltag ohne eine funktionierende IT-Struktur kaum denkbar. Um dem steigenden Konkurrenzdruck mit Schnelligkeit entgegenwirken zu können, müssen Geschäftsprozesse optimiert und automatisiert werden. Eine individuelle Software muss daher geplant und umgesetzt werden. Gescheiterte IT-Projekte stehen bei den meisten Unternehmen auf der Tagesordnung. Das Misslingen solcher Projekte ist größtenteils auf mangelndes Projektmanagement zurückzuführen. Um Kundenzufriedenheit und Wertschöpfung nachhaltig zu steigern, existieren verschiedene Vorgehensmodelle zur Erstellung von Softwarelösungen.

Eine Möglichkeit gegenüber des klassischen Projektmanagements ist das agile Managementframework Scrum. Agilität ist die Fähigkeit einer jeden IT-Abteilung, zeitnah auf Anforderungen von Kunden und Unternehmen zu reagieren und diese umsetzen zu können.

Der Begriff Scrum hat seine Wurzeln in der Teamsportart Rugby und wird auf Deutsch mit „Gedränge“ übersetzt. Beim Rugbyspiel stehen sich acht Spieler je Mannschaft gegenüber und versuchen das Spiel für sich zu entscheiden. Das Funktionieren eines Spielzugs hängt größtenteils von der Teamfähigkeit ab. Scrum fand seinen Ursprung bereits im Jahre 1980, nachdem erstmals bisherige Managementmethoden aufgrund einer unzureichenden Agilität in Frage gestellt wurden (vgl. Bücking, Setzwein, 2006, S.47). In Folge dessen wurden agile Ansatzpunkte entwickelt, die sich unter Scrum zusammenfassen lassen. Dieses wird als schlank bezeichnet, da ein Ziehsystem eingesetzt und Überlastungen systematisch vermieden werden (vgl. Pichler, 2008, S.3).

Ziel der Arbeit ist es, den Ablauf des klassischen Projektmanagements mit dem agilen Managementframework Scrum anhand ausgewählter Merkmale zu vergleichen. Zudem wird ein in klassischer Vorgehensweise gescheitertes IT-Projekt aus der Praxis vorgestellt und Verbesserungspotentiale mittels Scrum aufgezeigt. Ein Fazit beendet die Fallstudie.

2. Klassisches Projektmanagement und Scrum im Überblick

Das Wasserfallmodell gibt traditionell den Ablauf des klassischen Projektmanagements wider. In diesem werden die Softwareentwicklungsprozesse in verschiedene Phasen unterteilt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Wasserfallmodell (eigene Darstellung in Anlehnung an: www.ibr.cs.tu-bs.de)

Jeder einzelnen Phase ist ein definierter Start- und Endpunkt zugewiesen, der in Meilensteinsitzungen festgelegt wird. Das Wasserfallmodell ist sequentiell aufgebaut. Jede Phase beginnt erst dann, wenn die davor Liegende erfolgreich abgeschlossen wurde. Bleibt dieser Erfolg aus, wird zur vorher liegenden Phase zurückgesprungen. Des Weiteren ist dieses Vorgehen top-down orientiert und jede einzelne Phase wird vor ihrer Beendigung dokumentiert.

Nachdem das Projekt in Auftrag gegeben wurde, findet die Analyse und damit die Untersuchung der Ist-Situation statt. Nachdem diese Phase abgeschlossen ist, wird ein Entwurf ausgearbeitet, der die Soll-Situation darstellt. In der anschließenden Realisierungsphase wird der zuvor beschriebene Soll-Zustand umgesetzt. Abschließend wird das Projekt getestet, eingeführt und eventuell ein Kosten-Nutzen Vergleich durchgeführt.

Im Wesentlichen besteht das klassische Projektmanagement aus der Projektleitung, den Projektmitarbeitern und bei komplexeren Projekten dem PLA (vgl. Schnelle, 2006, S.2). Die Projektleitung plant die bereits erwähnten Phasen, setzt Termine, so genannte Meilensteine, fest und ist im ständigen Informationsaustausch mit dem PLA, der die Überwachungsfunktion wahrnimmt. Die einzelnen Projektmitarbeiter arbeiten die festgesetzten Inhalte der Meilensteine systematisch ab.

[...]