Ist das V-Modell für Ihr Projektmanagement geeignet?

Das V-Modell wurde in den 1980er Jahren von Unternehmen der Schwerindustrie als Management-System entwickelt, wird aber mittlerweile in vielen anderen Bereichen eingesetzt. Vor allem für die Organisation von IT-Projekten und in der Softwareentwicklung ist das V-Modell weit verbreitet. Doch auch in anderen Bereichen funktioniert das V-Modell sehr gut für das Management bestimmter Projekte und für die Qualitätssicherung.

Dennoch haben sich im Laufe der Jahre immer mehr andere Projektmanagement-Modelle entwickelt. Man hört immer öfter von Agilität oder Scrum. Ist das V-Modell obsolet geworden?

Sie möchten wissen, ob das V-Modell das Richtige für Ihr Projektmanagement ist? In diesem Artikel stellen wir alles Wissenswerte zu dieser klassischen Projektmanagement Methode vor.

Das V-Modell ist ein Vorgehensmodell oder auch Projektmanagement-Modell, das aus einer Top-Down- und einer Bottom-Up-Phase besteht. Es basiert auf dem Wasserfallmodell und beinhaltet das gleiche Prinzip der sequentiellen und linearen Verwaltung.

So sieht das V-Modell-Modell aus:

In diesem Diagramm werden alle Schritte, die für die Realisierung eines Produktes notwendig sind, gezeigt. Von der Formulierung des Bedarfs bis zur abschließenden Überprüfung seiner Konformität mit eben diesem Bedarf.

Die neun Schritte können in drei Phasen gruppiert werden:

• der Entwurf (Top-Down): Bedarfsanalyse und Machbarkeitsstudie, Spezifikationen, allgemeiner/architektonischer Entwurf und Detailentwurf;
• Implementierung;
• Validierung (Bottom-up-Teil): Unit-Tests, Integrationstests, Validierung und Abnahme.

• Durch das V-Modell gibt es weniger Feedbackschleifen während des Projektlebenszyklus: Bei Problemen kann jeder Schritt des Bottom-Up-Teils mit der Dokumentation geprüft werden, die während des entsprechenden Schritts des Top-Down-Teils erstellt wurde (siehe Abbildung oben).
• Es erfordert nur wenige regelmäßige Treffen.
• Die Dokumentation kann aus bereits vorhandenen Vorlagen erstellt werden.
• Die Anwendung erfordert weniger Training und weniger Voraussetzungen als andere Methoden wie Scrum.
• Es passt sich leicht an Projekte an.

• Veränderungen während der Entwicklung sind schwierig. Aufgrund des sequentiellen und linearen Aufbaus ist es nicht möglich einen einzelnen Schritt neu zu planen. Es ist jedoch nicht ungewöhnlich, dass während der Realisierungs- und Validierungsphase konzeptionelle Probleme auftreten. Ist es dann notwendig, den V-Modell ganz von vorne zu beginnen um Änderungen vorzunehmen?
• Es erfordert eine sehr aufwändige und genaue Dokumentation. Diese kann im Nachhinein nur schwer korrigiert werden, da dafür keine Zwischenstufen vorgesehen sind.
• Es gibt Anpassungsschwierigkeiten. Für die Software-Entwicklung sind z.B. die mangelnde Reaktionsfähigkeit und die Trennung zwischen Entwurf und Ausführung ein Problem.
• Mangelnder Kontakt zwischen Auftraggeber und Auftragnehmer.

Das V-Modell XT ist eine Version des V-Modell, die sich genaue auf das jeweilige Projekt anpassen lässt. XT steht dabei für Extreme Tailoring, was sich in etwa mit Extrem-Maßschneiderei übersetzen lässt. Die Abbildung zeigt die Phasen des V-Modell XT.

Wie darin zu erkennen ist, ist im V-Modell XT von vornherein eine Iteration eingeplant, in der das (Zwischen)Ergebnis des Projektes getestet und der Fortschritt überprüft wird. Bei Bedarf werden dann Anforderungen neu festgelegt und das Ergebnis überarbeitet oder das Projekt neu gestartet.

Es gibt mehrere Alternativen zum V-Modell. Im Moment ist die beliebteste Version die Scrum-Methode, die auf Basis von agilen Methoden entwickelt wurde.

Beim Wasserfall-Modell werden die verschieden Phasen eines Projektes nacheinander abgearbeitet. Jede vollendete Phase ist die Grundlage der Nächsten. Der erste Schritt ist die Planung oder Ist-Analyse, wobei festgestellt wird, wie die Ausgangssituation ist. Daraufhin wird ermittelt welches Problem es zu lösen gilt und ein Entwurf für das Produkt, das kreiert werden soll, gemacht. Schließlich wird das Projekt implementiert und in der Anwendung getestet. Der letzte Schritt bezieht sich auf die Instandhaltung nach erfolgreicher Implementierung.

Der Nachteil dieses Modells ist, ähnlich wie beim klassischen V-Modell, dass keine Iterationen oder Phasen zur Überprüfung des Projektes vorgesehen sind. Im Falle eines Scheiterns während der Testphase, muss das Team also wieder von vorne beginnen.

Momentan vergeht kaum ein Tag in Unternehmen, ohne dass nicht mindestens einmal der Begriff Agilität fällt. Der Begriff wurde aus dem Agilen Manifest abgeleitet, das im Jahr 2001 von 17 Entwicklungs-Spezialisten verfasst wurde.

In diesem Manifest werden vier Grundwerte und zwölf allgemeine Prinzipien dargelegt, die die Grundlage für agile Methoden bilden.

Agilität handelt nach folgenden Grundprinzipien:

Iterativ: Wiederholung eines Zyklus von Operationen. Das Projekt wird mit jeder Iteration verfeinert

Inkrementell: In jedem Zyklus wird ein bisschen mehr produziert um das Produkt Stück für Stück bis zum fertigen Ergebnis aufzubauen.

Die Kombination der beiden "Mona Lisas" gibt uns einen guten Einblick in das iterative und inkrementelle Wesen von Agilität:
Agile Mona Lisa: Inkrementell + Iterativ  

Außerdem ist es wichtig zu betonen, dass agile Methoden die Einbeziehung aller Beteiligten sowie große Anpassungsfähigkeit erfordern.

Beachten Sie jedoch, dass es viele agile Methoden gibt. Z.B. Extreme Programming (XP), Feature Driven Development (FDD) oder Lean Software Development.

Eine dieser Methoden ist jedoch in den letzten Jahren sehr populär geworden: die Scrum-Methode.

Scrum bedeutet auf Englisch "Gedränge". Und das aus gutem Grund: Die Scrum-Methode ähnelt einer Rugby-Mannschaft, die sich gemeinsam vorwärts bewegt und sich je nach Bedarf neu orientieren kann.

Es gibt bei Scrum zwei Formen der Aufteilung:

Zeitaufteilung: Das Projekt wird in Sprints (oder Iterationen) von zwei bis vier Wochen aufgeteilt. Am Ende eines jeden Sprints wird ein Produkt geliefert, auch wenn das Gesamtprojekt nicht abgeschlossen ist. Der Kunde kann dann Feedback geben, Verbesserungsvorschläge machen, etc.

Aufgabenaufteilung: Aus "Aufgaben" werden User Stories. Eine User Story formuliert ein Bedürfnis, auf das während des Sprints eine Antwort gegeben werden muss.

Product Owner: eine Art Projektleiter, er trägt die Vision des Produkts. Folglich setzt er Prioritäten, definiert Pflichtenhefte und validiert diese. Diese Rolle kann vom Kunden selbst übernommen werden;

Scrum Master: Er sorgt dafür, dass die Scrum-Methode eingehalten wird. Er fördert die Kommunikation und den reibungslosen Ablauf der Arbeit;

Team oder Devops Engineers: Es erledigt die Aufgaben, produziert das Produkt.

Sprint Planning: User Stories werden vorgestellt und der nächste Sprint wird organisiert;

Daily Scrum: Das Team trifft sich täglich, um den Projektfortschritt, den Sprint und eventuell aufgetretene Schwierigkeiten zu besprechen;

Sprint Review: Am Ende eines jeden Sprints erfolgt eine Demonstration der Deliverables. Dies ist der Zeitpunkt, um Feedback vom Kunden einzuholen;

Sprint Retrospektive: Als Teil eines kontinuierlichen Verbesserungsprozesses trifft sich das Team, um eine Bilanz des Sprints zu ziehen und Verbesserungen für den nächsten Sprint vorzunehmen.

Folgende Tabelle stellt die beiden Methoden gegenüber:

Welche Methode die Richtige für Sie ist, hängt letztendlich von der Art des Projektes ab, an dem Sie arbeiten wollen, und von den Teams, auf die Sie zurückgreifen können.

Sie treiben ein komplexes Projekt voran, haben aber wenig Transparenz? Sind Sie in der Lage, Teams aktiv zu mobilisieren? Entscheiden Sie sich für Scrum.

Haben Sie oder Ihr Kunde die volle Kontrolle über das Projekt oder ist es risikoarm? Verlassen Sie sich lieber auf die mitgelieferte Dokumentation? Ist es schwierig ihre Mitarbeiter regelmäßig zusammenzubringen? Für Sie könnte das V-Modell möglicherweise die bessere Lösung sein.

Sie haben Ihre Wahl getroffen? Dann entdecken Sie hier die Projektmanagement-Software, auf die Sie sich verlassen können.