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 Team damit knapp 300 Personenstunden.