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.
Inhaltsverzeichnis
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
Zielsetzung & Themen
Die vorliegende Arbeit vergleicht das klassische Projektmanagement mit dem agilen Managementframework Scrum, um die Defizite sequenzieller Vorgehensweisen aufzuzeigen und Lösungsansätze für IT-Projekte zu entwickeln.
- Vergleich von Wasserfallmodell und Scrum im Ablauf.
- Analyse der Planungs- und Durchführungsphasen.
- Testmanagement und Auslieferungsstrategien im direkten Gegenüber.
- Fallbeispiel eines gescheiterten IT-Projekts bei der Fiktiv Bank AG.
- Identifikation von Verbesserungspotenzialen durch agile Methoden.
Auszug aus dem Buch
3.1.2 Product Backlog und Sprintplanning in Scrum
Grundgedanke von Scrum ist es, von der zentralen Planung eines Softwareentwicklungsprojekts abzusehen und dem Projektteam mehr Eigenverantwortung und Handlungsspielraum zukommen zu lassen. Die Planung in Scrum wird somit zentral vom Team durchgeführt.
Am Anfang eines jeden Entwicklungszyklus, kurz Sprint, wird eine Sprint-Planungssitzung durchgeführt. In dieser stellt der Product Owner seine user stories aus dem Product Backlog vor.
Die Aufwände der einzelnen Benutzergeschichten werden vom Team geschätzt und anschließend dokumentiert.
Nach der Schätzung werden die für den Sprint vorgesehenen Benutzergeschichten feingranular in Tasks gegliedert und zur Abarbeitung durch das Team freigegeben.
Zusammenfassung der Kapitel
1. Einleitung: Diese Einleitung führt in die Relevanz moderner IT-Strukturen ein und begründet die Wahl von Scrum als agile Antwort auf das Scheitern klassischer IT-Projekte.
2. Klassisches Projektmanagement und Scrum im Überblick: Hier werden die theoretischen Grundlagen beider Frameworks erläutert, wobei insbesondere das Wasserfallmodell und der Scrum-Prozess gegenübergestellt werden.
3. Methodik: Ablauf des klassischen Projektmanagements und Scrum im Vergleich: In diesem Hauptkapitel wird detailliert der Ablauf beider Vorgehensweisen in den Bereichen Planung, Durchführung, Testmanagement und Auslieferung verglichen.
4. Klassisches Projektmanagement und Scrum in der Praxis: Anhand des Falls der Fiktiv Bank AG wird ein gescheitertes Projekt illustriert und diskutiert, wie der Einsatz von Scrum hier zu besseren Ergebnissen hätte führen können.
5. Fazit: Das Fazit fasst die Ergebnisse zusammen und bewertet die Eignung von Scrum als Alternative zum klassischen Projektmanagement im deutschen Unternehmensumfeld.
Schlüsselwörter
Klassisches Projektmanagement, Scrum, Wasserfallmodell, Agilität, IT-Projekte, Softwareentwicklung, Sprint, Product Backlog, Projektsteuerung, Produktinkrement, Prozessoptimierung, Kundenzufriedenheit, Meilensteinplanung, Fehlervermeidung, Teamfähigkeit
Häufig gestellte Fragen
Worum geht es in dieser Arbeit grundsätzlich?
Die Arbeit analysiert und vergleicht das klassische, sequenzielle Projektmanagement mit dem agilen Framework Scrum im Kontext der Softwareentwicklung.
Was sind die zentralen Themenfelder?
Die Schwerpunkte liegen auf der Planung, der praktischen Durchführung, dem Testmanagement sowie der finalen Auslieferung von Softwareprodukten.
Was ist das primäre Ziel der Untersuchung?
Ziel ist es, die Schwächen des klassischen Projektmanagements aufzuzeigen und darzulegen, wie durch agile Methoden wie Scrum die Erfolgschancen von IT-Projekten gesteigert werden können.
Welche wissenschaftliche Methode wird verwendet?
Die Arbeit nutzt einen komparativen Ansatz sowie eine Fallstudienmethode, basierend auf einem Praxisbeispiel eines fiktiven Unternehmens.
Was wird im Hauptteil behandelt?
Der Hauptteil gliedert sich in einen theoretischen Vergleich der Phasenabläufe und eine praktische Anwendung, in der ein gescheitertes Projekt durch die Scrum-Methodik gespiegelt wird.
Welche Schlüsselwörter charakterisieren die Arbeit?
Klassisches Projektmanagement, Scrum, Agilität, Softwareentwicklung, Sprint, Product Backlog und Projektsteuerung.
Warum scheiterte das Projekt bei der Fiktiv Bank AG?
Das Projekt scheiterte unter anderem an mangelnder Kommunikation, fehlendem Fachwissen im DMS-Bereich und der starren, sequenziellen Vorgehensweise, die zu fehlerhaften Zwischenergebnissen führte.
Welchen Vorteil bietet Scrum laut der Studie bei der Auslieferung?
Durch die kontinuierliche Lieferung von Produktinkrementen nach jedem Sprint wird die Software stetig getestet, was das Risiko einer fehlerhaften Gesamtauslieferung minimiert.
- Citation du texte
- Patrick Seifert (Auteur), 2009, Fallstudie: Klassisches Projektmanagement versus Scrum, Munich, GRIN Verlag, https://www.grin.com/document/154958
