Das Projektmanagement-Labor

Vorgehensmodelle für Software-Projekte im Vergleich

Wasserfall, Scrum oder doch besser RUP? Im Expertenstreit um das richtige Vorgehensmodell für Software-Entwicklungen gibt es viele Meinungen, aber keine neutralen Kriterien. Kay Schulz setzte sich mit dieser Fragestellung auseinander und führte mit Studenten der Wirtschaftsinformatik einen aufschlussreichen Praxistest durch: In einer Art "Projektmanagement-Labor" arbeiteten mehrere Teams parallel mit verschiedenen Vorgehensmodellen an derselben Aufgabenstellung. Welche Schwierigkeiten und Erfolgserlebnisse die Studenten dabei hatten und welche überraschenden Ergebnisse der Test lieferte, erfahren Sie in diesem Beitrag.
Das Projektmanagement-Labor

Vorgehensmodelle für Software-Projekte im Vergleich

Wasserfall, Scrum oder doch besser RUP? Im Expertenstreit um das richtige Vorgehensmodell für Software-Entwicklungen gibt es viele Meinungen, aber keine neutralen Kriterien. Kay Schulz setzte sich mit dieser Fragestellung auseinander und führte mit Studenten der Wirtschaftsinformatik einen aufschlussreichen Praxistest durch: In einer Art "Projektmanagement-Labor" arbeiteten mehrere Teams parallel mit verschiedenen Vorgehensmodellen an derselben Aufgabenstellung. Welche Schwierigkeiten und Erfolgserlebnisse die Studenten dabei hatten und welche überraschenden Ergebnisse der Test lieferte, erfahren Sie in diesem Beitrag.

Sind für Software-Projekte agile Herangehensweisen besser geeignet oder traditionelle? In diesem Expertenstreit gibt es viele Meinungen und Argumente. Wer entscheiden muss, nach welchem Vorgehensmodell ein neues Projekt durchgeführt werden soll, hat letztlich keine neutralen Kriterien zur Verfügung. Überraschende Ergebnisse lieferte ein Praxistest mit verschiedenen Vorgehensmodellen, den ich mit Studenten der Wirtschaftsinformatik an der Dualen Hochschule Baden-Württemberg durchführen konnte.

Im Rahmen eines Lehrauftrags halte ich dort eine zweisemestrige Vorlesung über Projektmanagement und Systemanalyse. Bestandteil dieser Vorlesung ist die Durchführung eines Projektplanspiels im Rahmen einer Semesterarbeit. Dabei gilt es, eine konkrete Aufgabe als Projekt zu planen und durchzuführen. Zu den vorgegebenen Lernzielen gehört es dabei unter anderem, dass die Studenten praktische Projekterfahrung erwerben.

Da die Semesterarbeit in mehreren kleinen Teams durchzuführen ist, bot sich mir die Gelegenheit, eine Art "Projektmanagement-Labor" einzurichten: Ich konzipierte die Semesterarbeit so, dass jedes Team mit einem anderen Vorgehensmodell an die Aufgabe herangeht. Die Studenten haben dadurch einen besonders hohen Lerneffekt, da sie die verschiedene Modelle entweder selbst ausprobieren oder bei den anderen Gruppen beobachten können.

Mittlerweile habe ich diese Vorlesung dreimal durchgeführt, so dass ich aus den Erfahrungen mit den Projektgruppen umgekehrt Rückschlüsse über die Eignung der Vorgehensmodelle für ihren Einsatz in unerfahrenen Teams ziehen kann. Diese Erfahrungen erscheinen mir einerseits hilfreich für Projektverantwortliche in Unternehmen, die entscheiden müssen, welches Vorgehensmodell sie einsetzen sollen. Andererseits können sie auch für Trainer oder Dozenten nützlich sein, die solche Vorgehensmodelle lehren.

Die "Versuchsbedingungen"

An den Kursen nahmen jeweils ca. 25 Studenten der Wirtschaftsinformatik im dritten Fachsemester teil, die zuvor eine Vorlesung über Java-Programmierung und eine Einführung in Unified Modeling Language (UML) gehört hatten und somit einfache Software konzipieren und erstellen konnten.

Aufgabenstellung

Die im Rahmen der Semesterarbeit zu lösende Aufgabe bestand darin, eine Software für die Belegung und Verwaltung von Vorlesungen zu programmieren und zu implementieren. Dabei gab es eine Reihe von Anforderungen zu berücksichtigen, wie z.B. Maximalbelegungszahl, unterschiedliche Benutzerrechte für Studenten und Sekretariat oder mögliche Dozentenwechsel. Die vollständige Anforderungsliste erhielten die Studenten in der Anleitung für die Seminararbeit. Dort war auch gefordert, dass sie die Aufgabe projektorientiert nach einem bestimmten Vorgehensmodell planen und durchführen sollten.

Allerdings hatten sie bisher keinerlei Vorlesungen zum Thema Projektmanagement gehabt. In den ersten zehn Unterrichtsstunden gab ich daher eine Projektmanagement-Einführung und erklärte in Grundzügen vier von mir ausgewählte unterschiedliche Herangehensweisen: Wasserfallmodell, Rational Unified Process (RUP), Scrum und Lean Sigma. Mit Wasserfall, RUP und Scrum wollte ich ein möglichst breites Spektrum der in der Praxis eingesetzten Vorgehensmodelle bei Software-Entwicklungen abdecken. Lean Sigma wählte ich, da Wirtschaftsinformatiker nicht nur Software entwickeln, sondern auch Geschäftsprozesse analysieren und in Verbindung mit neuer Software optimieren sollen.

Auch wenn es in so kurzer Zeit nicht möglich ist, diese durchaus anspruchsvollen Management-Modelle detailliert vorzustellen, konnte ich doch zumindest die grundlegenden Prozessabläufe und die wesentlichen Disziplinen wie z.B. Risikomanagement oder Änderungsmanagement vermitteln:

  • Beim Wasserfallmodell war es mir wichtig hervorzuheben, dass der Projektablauf in klare Phasen aufgeteilt wird und keine Iterationen stattfinden. Eine Änderung würde hier stets einen Rückschlag des Projektfortschritts um mindestens eine Phase bedeuten.
  • Beim Rational Unified Process sollten die Studenten die grundsätzliche Gliederung in die Phasen (Inception, Elaboration, Construction, Transition) und die Disziplinen (z.B. Analysis & Design) des RUP lernen und das iterative Vorgehen verstehen.
  • Anhand von Scrum erklärte ich die Ideen des agilen Projektmanagements, wie z.B. die beständige Zusammenarbeit mit den Kunden und das Arbeiten in Sprints.
  • Bei Lean Sigma stellte ich im Wesentlichen den DMAIC-Zyklus (Define, Measure, Analyze, Improve, Control) vor. Lean Sigma ist kein Vorgehensmodell für Software-Entwicklung, sondern eines zur Optimierung von Geschäftsprozessen. Die Lean-Sigma-Teams sollten deshalb auch nicht selbst Software entwickeln, sondern die bestehenden Prozesse zur Vorlesungsverwaltung analysieren, die von mir vorgegebenen Anforderungen überprüfen und diese ggf. verbessern. Für die Phase "Improve" sollten die einzelnen Teams zudem nach etwa zwei Drittel der Laufzeit jeweils ein Entwicklerteam auswählen, das ihrer Meinung nach für die definierten Anforderungen die am besten geeignete Software liefern könnte.

Darüber hinaus ließ ich noch das Vorgehensmodell "Joker" zu. Joker bedeutete, dass dieses Team alle Freiheiten hatte, um die Aufgabenstellung der Semesterarbeit zu lösen. Es konnte ein Modell wählen oder einfach spontan drauflos arbeiten.

Arbeitsorganisation

Für das Projekt stand ein Zeitraum von zwei Monaten zur Verfügung. Die Vorlesung war offiziell auf 89 Wochenstunden festgelegt, zehn davon benötigte ich für die Einführung. Für die Projektarbeit standen also 79 Wochenstunden zu je 45 Minuten zur Verfügung. Da jedes Team aus fünf Personen bestand, betrug die Arbeitskapazität pro…

Bewertungen und Kommentare

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 26
Kommentare 6

Alle Kommentare

Johann
Stiebellehner
Dr.
Die Idee der Versuchdurchführung und des Projektmanagement-Labors ist interessant und gut, sollte aber weiter ausgebaut werden, sodass sie auch wissenschaftlichen Kriterien entspricht.
Guest
Ich bin oft mit der Farge konfrontiert, gibt es Untersuchungen ... Ich finde den Artikel und das beschriebene Vorgehen sehr hilfreich. Danke Vera Reithmeier
Anuschka
Schweizer
Wunderbare praxisrelevante Wissensvermittlung. Glückwunsch!
Kolja
Siefert
Danke und Glüclwunsch zu diesem Bericht. Er hilft bei den immer wieder auftretenden Diskussionen rund um die richtige Herangehensweise und Philosophie. Ich schliesse mich meinen Dr. Stiebellehner an, dass eine derartige Analyse sinnvoll ist und in einem nächsten Schritt weiter ausgebaut werden kann.
Guest
"Wir mussten noch nie so viel arbeiten und haben noch nie so viel gelernt." Dem kann ich nur zustimmen. Der gesamte Verlauf der Lehrveranstaltung hat mir als Student auch einiges bezüglich persönlicher Stärken und Schwächen aufgezeigt. Als Joker haben wir uns für eine Mischung aus RUP und Wasserfall entschieden, allerdings haben wir auch stark Richtung Wasserfall abgewichen. Das Ergebnis fand ich entgegen diesem Artikel allerdings etwas besser als hier formuliert. Wir hatten nicht unbedingt das Beste aller Gruppen, aber die ausgehandelten Anforderungen wurden IMHO durchaus (auch weitestgehend ohne Bugs) erfüllt. Alles in allem stimmt das Fazit nach meinem eigenen Eindruck und Gesprächen mit Teilnehmern anderer Teams. So, jetzt ist Ende für den ewig langen Kommentar.
Werner
Gerst
Dipl.-Ing.
Sehr guter Bericht und wirklich effiziente Lehrveranstaltung. Aus Sicht des Unternehmers muss jedoch eine so erstellte Software oder auch Business-Prozess aufgrund ständiger Änderungen laufend angepasst oder erweitert werden. Interessant wäre daher die im ersten Durchlauf entwickelte Software/Prozesse weiterzuentwickeln und Erfahrungen über den Lebenszyklus des Produktes zu sammeln. Meine Praxiserfahrungen zeigen das einige Modelle zwar Vorteile in der Entwicklung (Ramp-Up) haben aber in der Wartung und Pflege massive Nachteile entwickeln. Sprich Investitions-Kosten und Pflegekosten müssen gesamtheitlich mit Projekt-/Lean-Mgmt.-methoden durchgeführt und bewertet werden und sind erst dann für ein Unternehmen erfolgreich. (Voraussetzung: Software/Prozesse mit einem mittleren bis längerem Lebenszyklus) Eine Erweiterung des Versuchs mit den bereits schon erwähnten Verbesserungen und meiner Ergänzung könnte in den folgenden Semestern daher sehr spannend und sehr viel Aussagekräftiger werden.
Alle anzeigen