Es kommt immer wieder vor, dass OPITZ CONSULTING als Dienstleister von einem Auftraggeber zum Einsatz des V-Modell XT verpflichtet wird, wohlwissend, dass wir agile Vorgehensweisen bei der Projektdurchführung bevorzugen.

Eine spannende Herausforderung ist es für uns daher, praktikable Konzepte und Vorgehen zu entwickeln und zu erproben, bei denen unsere gelebten agilen Vorgehensweisen in das etablierte V-Modell eingebettet werden.

V-Modell XT und agile Frameworks bzw. Methoden lassen sich zu einem innovativen Integrationsmodell kombinieren: Es bietet viel Flexibilität für dynamische Anforderungen; zudem lässt es sich leicht in mehrere Teilprojekte aufteilen und kostengünstig abwickeln.

Auf der einen Seite steht also das V-Modell XT „“ mit seinen mehr als 30 Rollen, über 100 Produkttypen und zahlreichen Entscheidungspunkten („Meilensteinen“) ein hochskalierbares und mit klaren Schnittstellen für die Zusammenarbeit von Auftraggebern und Auftragnehmern ausgestattetes Vorgehensmodell.

Auf der anderen Seite finden wir bewährte agile Vorgehensmodelle bzw. Frameworks wie Scrum, Kanban „“ mit wenigen Rollen, einer Handvoll Produkten und einer anderen Meetingstruktur/-Kultur.

Die Frage ist also: Wie kann man diese unterschiedlichen Vorgehensmodelle miteinander verbinden?

Generell ist das V-Modell XT darauf ausgelegt, sowohl den Auftraggeber (AG) als auch den Auftragnehmer (AN) von der Projektidee über Ausschreibung, Vertragsschluss und Entwicklung bis hin zum Projektabschluss methodisch durchgängig zu unterstützen. Weiterhin berücksichtigt dieses Vorgehensmodell beispielsweise, ob es sich um ein Entwicklungs- oder ein Wartungsprojekt handelt oder welche Merkmale das Projekt auszeichnen: Geht es rein um Software oder auch um Hardware? Spielen Sicherheit oder Ergonomie eine besondere Rolle? Muss ein Altsystem migriert werden? Sollen Teilleistungen von Unterauftragnehmern erbracht werden?

Genau diese vielfältigen Einsatzmöglichkeiten verursachen bei vielen Betrachtern den Eindruck einer enormen „“ vermeintlichen – Komplexität. Um diese aufzulösen, wird der Begriffszusatz „XT“ des V-Modell XT angewandt. Das „XT“ steht für „eXtreme Tailoring“. Dadurch sind mit dem V-Modell XT vielfältige projekt- und organisationsspezifische Anpassungen möglich. In einem konkreten Projekt wird mit Hilfe des Zuschnitts immer nur eine Teilmenge des Modells angewendet, so dass sich nach dem Projekt-Setup mit dem im V-Modell XT enthaltenen Projektassistenten stets eine deutlich reduzierte Dokumentation ergibt, die sich auch auf die möglichen Dokumentenartefakte (hier „Produkte“ genannt) niederschlägt. Dieses integrierte Werkzeug ist eine Open-Source-Lösung zur softwaretechnischen Unterstützung der auszuwählenden Tailoring-Maßnahmen.

Auf Basis dieses Projekt-Tailoring wird abschließend im automatisch erstellten Projekthandbuch festgelegt, welche der vorgeschlagenen Produkte überhaupt gepflegt werden soll. So können z. B. unterschiedliche Produkte wie einzelne Spezifikationstypen zu einer Dokumentation zusammengefasst werden. Des Weiteren wird festgelegt, wo bzw. wie die Projektdokumentation gepflegt werden soll (z. B. dateibasiert in Word oder in Excel oder in einem Kollaborationstool wie Confluence). Fazit: Das V-Modell XT bietet spätestens ab der aktuellen Version 2.1 auch offiziell sehr viele Möglichkeiten, um den formalen Aufwand deutlich zu reduzieren.

Unter diesen Voraussetzungen fällt es nun schon deutlich leichter, an die Integration agiler Vorgehensweisen in das V-Modell XT zu denken. Eine solche Integration ist darin auch in die Kategorie der „organisationsspezifischen Anpassungen“ ausdrücklich vorgesehen und wird in der Regel nicht projektspezifisch, sondern nur einmalig vorgenommen. Am Ende erhält man damit ein „agiles V-Modell“.

V-A_1

Wie könnte eine solche Integration praktisch aussehen?

Im V-Modell XT gibt es Entscheidungspunkte für die Fertigstellung von Dokumenten und Systemelementen, an denen über den weiteren Projektfortschritt entschieden wird. Der genaue zeitliche Ablauf, wann und in welcher Reihenfolge diese Entscheidungspunkte durchlaufen werden, wird durch vordefinierte Strategien, sogenannte „Projektdurchführungsstrategien“, beschrieben.

Mit Hilfe dieser Strategien können auf Gesamtsystem-, System-, Hardware- und Softwareebene Iterationen durchgeführt werden. Das V-Modell XT hält neben der „inkrementellen Entwicklungsstrategie“ für die Flexibilität und Anpassungsfähigkeit im Umgang mit Anforderungen bzw. noch unbekannten Technologien auch eine „prototypische Entwicklungsstrategie“ bereit, bei der die Dokumentation erst nach der Fertigstellung der zugehörigen Systemelemente erstellt wird.

Diese Strategie könnte damit der Verbindungpunkt für eine Verbindung beider Vorgehensweisen sein. Dies bedeutet nicht, dass wir mit dieser Entwicklungsstrategie als Ergebnis nur Prototypen erzeugen können „“ es entstehen „echte“ Produkte.

Projektsteuerung zusammenführen

Die Projektsteuerung ist im V-Modell XT auf einem anderen Niveau angesiedelt als bei agilen Vorgehensweisen wie Scrum. Die Vorgaben des V-Modell XT, die im Wesentlichen auf das Erreichen von Entscheidungspunkten zielen, bewegen sich auf einer Makro-Management-Ebene. Im Unterschied dazu befindet sich der Scrum-Ablauf, der auf der Realisierung von Anforderungen durch elementare Entwickler-Tasks in kurzen Sprints basiert, im Bereich des Mikro-Management. Diese unterschiedlich hohen Ebenen der Steuerung machen es möglich, beide Prozesse zu kombinieren, indem die Mikro-Steuerung mit Scrum in die Makro-Steuerung nach dem V-Modell XT eingebettet wird.

Um eine V-Modell XT konforme Einbettung zu realisieren, d. h. die im Modell definierten Schnittstellen zwischen Auftraggeber und Auftragnehmer nicht zu beeinträchtigen, wird dafür gesorgt, dass an den entsprechenden Entscheidungspunkten die relevanten, vom Auftraggeber geforderten V-Modell-Dokumente (bzw. die Inhalte dieser Produkte) fertiggestellt sind. Ein Schlüsselinstrument, um diese Forderung zu erfüllen, ist das Product Backlog.

Schlüsselinstrument Product Backlog

Mit dem Einsatz der beschriebenen prototypischen Projektdurchführungsstrategie erhält das Product Backlog eine zentrale Stellung: Es besteht überwiegend aus Anforderungen an das zu erstellende System, die sich aus dem Lastenheft und „“ später im Projektverlauf „“ aus Ü„nderungsanträgen und Fehlermeldungen ergeben. Die Anforderungen werden nach Bedarf verfeinert und um technische Informationen ergänzt.

Die Erstellung von Dokumenten, die nach dem V-Modell XT gefordert sind, werden ebenfalls wie Anforderungen behandelt und in das Product Backlog aufgenommen. Das Scrum-Team hält in seiner „Definition of Done“ fest, dass die Anforderungen für ihre Integration in die Dokumente aktualisiert und „kundenkompatibel“ formuliert werden.

Der auf die beschriebene Weise entstandene integrierte Prozess bietet dem Auftraggeber erheblichen Spielraum, sich analog zum Product Owner im Scrum-Vorgehensmodell, in das Auftragnehmerprojekt einzubringen.

Die folgende Abbildung stellt eine solche Integration beider Vorgehensweisen dar:

V-A_2

Nach dem Entscheidungspunkt „Iteration geplant“ setzen im Scrum-Ablauf die Sprint-Planung und -Durchführung ein. Die nachfolgenden Iterationen sind auf den verschiedenen farbig (blau, grün und rot) markierten Ebenen ineinander verschachtelt. Für jede Ebene gibt es die bekannten agilen Elemente:

  • Product Backlog
  • Sprint Backlog
  • „Definition of Done“-Kriterien Der Inhalt der DoD-Kriterien ergibt sich u. a. aus den Produkten der jeweiligen Entscheidungspunkte des V-Modell XT, die in den jeweiligen Ebenen zusammengefasst sind.

Die Entscheidungspunkte „Gesamtsystem entworfen“ „Lieferung durchgeführt“ und „Abnahme erfolgt“ gewährleisten, dass die vom V-Modell XT erforderliche AG-/AN-Schnittstelle bestehen bleibt. Mittels dieser Schnittstelle an den Entscheidungspunkten müssen alle vom Auftraggeber geforderten V-Modell-Dokumente fertiggestellt und vorgelegt werden.

Fazit

Die Integration von agilen Vorgehensmodellen in das V-Modell XT ist nicht trivial, aber möglich. Das V-Modell XT unterstützt bei der sinnvollen Aufteilung des Gesamtsystems in Teilsysteme und bei der Definition der Schnittstellen zwischen diesen. Für die Entwicklung jedes dieser Teilsysteme können wiederum die Stärken von agilen Prozessen wie Scrum ausgespielt werden. In diesem Umfeld ist die richtige Zusammenstellung von „cross-funktionalen“ Teams wichtig. Wesentliche Informationen über die benötigten Kompetenzen liefert hierzu das V-Modell XT.

Der vorab aufgezeigte Ansatz zeigt eine Möglichkeit, wie man das V-Modell XT und agile Methoden und Frameworks wie Scrum sinnvoll miteinander kombinieren könnte. Die Konformität dieser Lösung ist offiziell zwar noch nicht von der V-Modell-Zertifizierungsstelle freigegeben, aber sie deckt sich mit den Lösungsvorschlägen einer Reihe von anerkannten V-Modell-Autoren (z. B.D. Rauh, M. Wittmann; V-Modell-XT Konformität und „“Assessment, in: OBJEKT-spektrum 3/2009und S. Canditt, D. Rauh, M. Wittmann; Das V-Modell XT mit Scrum inside, in: OBJEKT spektrum Themenspecial Agility 2011).

 

Alle Beiträge von anl

Schreibe einen Kommentar