Sprinten mit dem V-Modell XT

Einfache Regeln, wenige Rollen, leicht und flexibel - das ist Scrum, der derzeit wohl populärste Vertreter der agilen Entwicklungsprozesse. Anpassbar, skalierbar und dazu eine klare Schnittstelle für die Zusammenarbeit von Auftraggebern und Auftragnehmern - das kennzeichnet das V-Modell XT, den Entwicklungsstandard für die Systeme der öffentlichen Verwaltung, der gern mit dem Zusatz "schwergewichtig" versehen wird. Was kann man tun, wenn man als Dienstleister einem Auftraggeber zum Einsatz des V-Modell XT verpflichtet ist, aber in den eigenen Teams Scrum etabliert hat?

Auf der einen Seite steht also das V-Modell XT mit seinen 33 Rollen, über 100 Produkttypen und zahlreichen Meilensteinen, den so genannten Entscheidungspunkten. Auf der anderen Seite steht Scrum mit drei Rollen, einer Handvoll von Produkten und einigen Meetings, zum Beispiel jeweils am Anfang und Ende der gleich langen beziehungsweise gleich kurzen Iterationen eines Projekts. Kann man diese beiden unterschiedlichen Prozesse miteinander verbinden? Wohlgemerkt: Die Frage zielt darauf ab, ob und wie man Scrum zur Projektsteuerung in V-Modell-XT-Projekten anwenden kann. Es geht nicht darum, als Auftragnehmer intern Scrum zu verwenden und nach außen - also zum Auftraggeber hin - ein V-Modell XT vorzugeben.

Es liegt auf der Hand: Will man Scrum mit dem V-Modell XT kombinieren, muss man Letzteres an die Leichtgewichtigkeit des agilen Vorgehens anpassen. Aber ist das überhaupt erlaubt, oder anders gefragt: Kann ein verändertes V-Modell XT von einem Auftragnehmer in Projekten der öffentlichen Verwaltung eingesetzt werden?

Angepasstes V-Modell ist erwünscht

Grundsätzlich lässt das V-Modell XT sowohl projekt- als auch organisationsspezifische Anpassungen zu. Scrum in das V-Modell XT zu integrieren fällt in die Kategorie der organisationsspezifischen Anpassungen, die einmalig vorgenommen werden und aus Sicht des V-Modells XT nicht nur zulässig, sondern durchaus erwünscht sind. Das V-Modell XT sieht dafür sogar einen eigenen Projekttypen vor.

Der Grund ist leicht nachvollziehbar: Ein öffentlicher Auftraggeber verfolgt mit dem Einsatz des V-Modells XT das Ziel, den Projekterfolg zu erhöhen und die Projektergebnisse zu verbessern. Dieses Ziel wird noch besser erreicht, wenn der Auftragnehmer einen auf ihn zugeschnittenen, in seinen Projektteams etablierten Prozess einsetzen darf. Für den Auftragnehmer bedeutet das gewohnte Vorgehen und der Einsatz darauf abgestimmter Werkzeuge und Methoden einen geringeren Rüstaufwand und damit auch eine kostengünstigere Projektabwicklung. Die Anpassung des V-Modells XT kann also für beide Parteien zu einer Win-win-Situation führen - vorausgesetzt, das angepasste Modell ist nach wie vor konform zum V-Modell XT.

Die Überprüfung einer solchen Konformität von organisationsspezifischen Modellen wird künftig die Aufgabe der V-Modell-Zertifizierungsstelle sein. Sie bietet das Zertifikat "V-Modell XT Konf" zurzeit noch nicht an. Die nachfolgend beschriebene Lösung zur Integration von Scrum in das V-Modell XT orientiert sich deshalb an den bisher veröffentlichten Konformitätskriterien. So basiert sie unter anderem auf dem unveränderten Metamodell des V-Modells XT.

Die AG/AN-Schnittstelle

Das V-Modell XT unterscheidet mehrere Projekttypen. Die nachfolgend beschriebene Lösung ist auf den Projekttypen Systementwicklung (AN) zugeschnitten. Es handelt sich dabei um ein Projekt eines Auftragnehmers (AN). Das V-Modell XT geht davon aus, dass ein Auftragnehmerprojekt immer von einem parallel dazu ablaufenden Projekt des Auftraggebers (AG) - in V-Modell-Terminologie Systementwicklung (AG) - begleitet wird. Die klar definierte AG/AN-Schnittstelle, die das Zusammenwirken der beiden Partnerprojekte regelt, ist eine Stärke des V-Modells XT. Eine wichtige Vorgabe für den Integrationsansatz ist deshalb, dass diese Schnittstelle durch den Scrum-Einsatz beim Auftragnehmer nicht beeinträchtigt werden darf.

Wenn man das V-Modell XT und Scrum zusammenführen will, muss man zunächst die grundsätzlichen Unterschiede erkennen. Von zentraler Beutung für die Integration ist die unterschiedliche Art der Projektsteuerung im V-Modell XT und in Scrum.

Lesen Sie auf der nächsten Seite, wie Projekte mit dem V-Modell XT gesteuert werden.

Projekte mit dem V-Modell XT steuern

Das V-Modell XT lässt sich an die verschiedensten Projektsituationen anpassen. Grund dafür ist sein modularer Aufbau aus Vorgehensbausteinen. Sie definieren, welche Produkte in einem Projekt erstellt werden müssen und wer dafür jeweils die Verantwortung trägt. Ein Vorgehensbaustein sagt nichts darüber aus, zu welchem Zeitpunkt die Produkte im Projektablauf entstehen sollen. Das übernehmen die Projektdurchführungsstrategien. Sie geben den Rahmen für die Projektplanung vor, indem sie die Meilensteine eines Projekts definieren und festlegen, in welcher Reihenfolge die Meilensteine durchlaufen werden können und welche Produkte pro Meilenstein vorhanden sein müssen. An jedem Meilenstein wird darüber entschieden, ob die nach dem V-Modell XT geforderte Stufe des Projektfortschritts erreicht wurde und ob das Projekt fortgesetzt werden soll. Das V-Modell XT spricht deshalb von Entscheidungspunkten statt von Meilensteinen.

Für Auftragnehmerprojekte enthält das V-Modell XT drei Durchführungsstrategien. Alle drei eignen sich zur iterativen Entwicklung. Die gängigste, die deshalb hier auch im Mittelpunkt der Betrachtung steht, ist die Projektdurchführungsstrategie "Inkrementelle Systementwicklung". Sie beschreibt einen Ablauf, der von der Spezifikation über Grob- und Feinentwurf, Realisierung und Integration bis zur Auslieferung und Abnahme reicht. Dieser Ablauf kann wiederholt auf Teilmengen der Systemanforderungen angewendet werden, so dass das zu entwickelnde System inkrementell wächst.

V-Modell XT gleich Wasserfall?

Um einem Missverständnis vorzubeugen: Die Projektdurchführungsstrategie Inkrementelle Systementwicklung ist kein Wasserfall. Sie schreibt kein striktes Nacheinander der klassischen Entwicklungsdisziplinen Analyse, Design, Entwicklung und Test vor. Andernfalls würde dies ohne Zweifel jeden Versuch, das V-Modell XT mit Scrum zusammenzuführen, zum Scheitern bringen. Auch in V-Modell-Projekten laufen die klassischen Entwicklungsdisziplinen innerhalb einer Iteration parallel ab. Abhängig vom Zeitablauf besitzen sie jedoch unterschiedliches Gewicht. Mit einer Entwurfsaufgabe kann beispielsweise schon begonnen werden, bevor das Pflichtenheft fertiggestellt und damit der Entscheidungspunkt "System spezifiziert" erreicht ist. Die Entwurfsergebnisse können allerdings erst dann endgültig überprüft werden, wenn das System vollständig spezifiziert ist.

Entscheidungspunkte definieren zwar, wann ein bestimmtes Produkt (Dokument oder Systemelement) fertig sein muss. Sie geben aber nicht vor, wann mit der Erstellung eines Produkts begonnen werden darf. Der Abstand zwischen den Entscheidungspunkten ist im V-Modell XT nicht festgelegt, kann also variieren. Das V-Modell XT lässt somit unterschiedlich lange Iterationen zu. Wie ein Produkt zu erstellen ist, beschreibt im V-Modell XT eine Aktivität. Das V-Modell XT definiert eine eindeutige Beziehung zwischen Aktivitäten und Produkten: Jedes geplante Produkt führt zu genau einer Aktivität im Projektplan.

Lesen Sie auf der nächsten Seite, wie man Projekte mit Scrum steuert.

Projekte mit Scrum steuern

Ein Scrum-Projekt gliedert sich in Iterationen, die als Sprints bezeichnet werden. Alle Sprints sind gleich lang - üblicherweise zwei bis vier Wochen. Motor des Scrum-Ablaufs ist das "Product Backlog", eine Liste von priorisierten Anforderungen. Für einen bevorstehenden Sprint wird unter den hoch priorisierten Anforderungen des Product Backlog eine Auswahl getroffen. Sie wird von einem interdisziplinären Team in Tasks, das heißt in elementare Entwicklungsaufgaben, zerlegt, die dann im Sprint abgearbeitet werden.

In jedem Sprint wird ein potenziell lieferfähiges Produktinkrement entwickelt. Innerhalb einer geplanten Anzahl von Sprints entsteht ein Produkt-Release. Nicht zuletzt durch die Selbstorganisation des Teams bei der Bearbeitung der Tasks hat der Prozess einen geringen Overhead. Basis für die Qualität der Arbeit eines Scrum-Teams ist unter anderem die "Definition of Done", eine vom Team erstellte Liste der Kriterien, nach denen Anforderungen als realisiert gelten.

Beim Blick auf die Verteilung der Arbeit in den verschiedenen Entwicklungsdisziplinen im Scrum-Ablauf stellt man fest: Die Unterschiede zum V-Modell XT sind in dieser Hinsicht geringer, als man erwarten könnte. In einem typischen Scrum-Projekt wird frühzeitiger in größerem Umfang entwickelt und getestet (zumindest legt Scrum dies nahe - das V-Modell XT hätte allerdings auch nichts dagegen). Naturgemäß fließt auch bei Scrum zu Beginn eines Projekts ein größerer Teil der Arbeit in das Verstehen der Anforderungen. Zum Projektende hin wird immer weniger an den Grundfesten der Architektur geändert.

Lesen Sie auf der nächsten Seite, wo sich die Steuerungsebenen der beiden Vorgehensweisen integrieren lassen.

Die Lösung aus Sicht des V-Modell XT und durch die Scrum-Brille

Der Vergleich der Projektsteuerung nach V-Modell XT und Scrum zeigt, dass die Steuerungsmechanismen der beiden Prozesse auf unterschiedlichem Niveau angesiedelt sind: Die Vorgaben des V-Modells XT, die im Wesentlichen auf das Erreichen von Entscheidungspunkten zielen, bewegen sich auf einer Makro-Management-Ebene. Im Unterschied dazu ist der Scrum-Ablauf, der auf der Realisierung von Anforderungen durch elementare Entwickler-Tasks in kurzen Sprints basiert, auf einem Mikro-Management-Niveau angesiedelt. 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.

Die Lösung aus Sicht des V-Modell XT

Die vorgestellte Projektdurchführungsstrategie Inkrementelle Systementwicklung bietet sich aufgrund ihres iterativen, inkrementellen Ansatzes als Ausgangspunkt für die Integration von Scrum in das V-Modell XT an. Um die Mikrosteuerung mit Scrum, eingebettet in eine zum V-Modell XT konforme Makrosteuerung, zu realisieren, wird die Durchführungsstrategie vereinfacht.

Die Entscheidungspunkte der Durchführungsstrategie werden bis einschließlich "Projekt beauftragt" unverändert übernommen. Danach folgt der Entscheidungspunkt "Release geplant". Er entspricht dem ursprünglichen Entscheidungspunkt "Iteration geplant" und wurde lediglich umbenannt, um sprachliche Verwirrung durch die unterschiedlichen Iterationsbegriffe in Scrum und im V-Modell XT zu vermeiden. Der gesamte Zyklus bis zur nächsten Lieferung an den Auftraggeber im Sinne des V-Modells XT wird hier - wie in Scrum - als "Release" bezeichnet.

Nach dem Entscheidungspunkt "Release geplant" setzt der Scrum-Ablauf ein, es beginnen also die Scrum-Sprints. Die Entscheidungspunkte des weiteren Projektverlaufs werden reduziert. "System spezifiziert", "Lieferung durchgeführt" und "Abnahme erfolgt" bleiben erhalten. Die vier dazwischenliegenden Meilensteine von "System entworfen" bis "System integriert" werden zu einem Entscheidungspunkt "Sprint abgeschlossen" zusammengefasst, der jeweils ein Sprint-Ende markiert.

Durch die Scrum-Brille betrachtet

Aus Sicht von Scrum stellt sich die Frage, warum an den Entscheidungspunkten "System spezifiziert", "Lieferung durchgeführt" und "Abnahme erfolgt" festgehalten wird. Die Antwort lautet: Diese Entscheidungspunkte werden in den Scrum-Ablauf als Meilensteine eingefügt, um - wie eingangs gefordert - zu gewährleisten, dass die AG/AN-Schnittstelle des V-Modells XT nicht beeinträchtigt wird. Um der AG/AN-Schnittstelle zu genügen, muss darüber hinaus dafür gesorgt werden, dass an diesen Entscheidungspunkten die relevanten, vom Auftraggeber geforderten V-Modell-Dokumente fertiggestellt sind. Schlüsselinstrument, um diese Forderung zu erfüllen, ist das Product Backlog.

In der Integrationslösung erhält das Product Backlog folgenden Charakter: 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 angereichert. Die Aufgaben, die Dokumente zu erstellen, 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.

Mit den Entscheidungspunkten "Projekt beauftragt/Release geplant" (Vertragsabschluss und Planung der ersten Entwicklungsstufe) sowie "Abnahme erfolgt/(nächstes) Release geplant" (Abnahme der ersten Entwicklungsstufe und Planung der zweiten) bleiben die Stellen zur Synchronisation von Auftraggeber- und Auftragnehmerprojekt so erhalten, wie sie das V-Modell XT vorsieht.

Lesen Sie auf der nächsten Seite die Auswirkungen der Integration auf Auftrageber und Auftragnehmer.

Viel Spielraum für den Auftraggeber

Der auf die beschriebene Weise entstandene integrierte Prozess bietet dem Auftraggeber - sozusagen als "Erbschaft" von Scrum und vom V-Modell XT - erheblichen Spielraum, sich in das Auftragnehmerprojekt einzubringen. Das beginnt bei der Planung: Je nachdem, wie intensiv der Auftraggeber mitwirken will, kann er sich entweder nur an der Festlegung der Anforderungen auf Release-Ebene oder auch an der regelmäßigen Sprint-Planung beteiligen. Und die Möglichkeiten zur Auftraggeberbeteiligung setzen sich bei der Projektkontrolle fort: Dem Entscheidungspunkt "Sprint abgeschlossen" geht die Abnahme der Sprint-Ergebnisse voraus. Sie findet im Rahmen von Sprint-Reviews statt. Formal ist der so genannte Product Owner beim Auftragnehmer für die Abnahme verantwortlich.

Die Zusammenarbeit zwischen Auftraggeber und Auftragnehmer kann jedoch davon profitieren, wenn der Auftraggeber an den Sprint-Reviews teilnimmt und sich einen Eindruck vom Entwicklungsstand des Systems verschafft. Für eine kontinuierliche Fortschrittskontrolle sieht das V-Modell XT im Auftraggeberprojekt den Entscheidungspunkt "Projektfortschritt überprüft" vor, der mit dem Auftragnehmerprojekt zu synchronisieren ist. Es empfiehlt sich also, den Entscheidungspunkt "Projektfortschritt überprüft" des Auftraggebers mit den Sprint-Enden zu synchronisieren.

Im Rahmen der Sprint-Reviews können Fragen geklärt und Änderungswünsche aufgenommen werden, um sie gegebenenfalls bereits im nachfolgenden Sprint zu berücksichtigen. Das ist vertraglich unproblematisch, solange die Änderungswünsche des Auftraggebers Details betreffen (was die Regel ist) und sich nicht auf dem Abstraktionsniveau des Lastenhefts bewegen, das Bestandteil des Vertrags zwischen Auftraggeber und Auftragnehmer ist.

Zugeständnisse auf beiden Seiten

Die Verbindung der beiden Prozesse geht, obwohl sie sich im Wesentlichen auf verschiedenen Steuerungsebenen abspielt, nicht ohne Einschränkungen in Bezug auf die V-Model-XT-Mechanismen und das agile Vorgehen nach Scrum ab. So entfällt bei dieser Lösung zum Beispiel die klassische aktivitätenbasierende Planung, wie sie das V-Modell XT kennt, samt dem üblichen und von Entscheidern oft erwarteten Balkendiagramm. Andererseits sind die Entwickler, wie oben dargestellt, damit konfrontiert, die für das V-Modell XT relevanten Dokumente zu erstellen - eine Herausforderung für agile Teams, die bekanntlich funktionierender Software Vorrang vor Dokumenten geben.

In der Praxis stellt sich aber gerade dieser Punkt als wenig kritisch heraus. Zu den für das V-Modell XT relevanten Produkten gehört zum Beispiel die "Gesamtsystemspezifikation" (Pflichtenheft). Teile dieses Dokuments können mit einem entsprechenden Werkzeug aus dem Product Backlog generiert werden. Entsprechendes gilt für die vom V-Modell XT geforderte Prüfspezifikation für das zu erstellende Gesamtsystem. Sie kann zumindest teilweise aus dem Backlog automatisch erzeugt werden, wenn dort zu jeder Anforderung Abnahmekriterien beziehungsweise Akzeptanztests erfasst sind.

Probe bestanden

Die vorgestellte Integration von Scrum in das V-Modell XT kann so, wie sie hier beschrieben wurde, in allen Projekten, die keine Teilprojekte und keine Unterauftragnehmer besitzen, direkt eingesetzt werden. Die Lösung hat dafür ihre Praxistauglichkeit bereits bewiesen. Für große Projekte mit Teilprojekten müssen in der Regel mehr V-Modell-XT-Produkte erstellt und weitere Entscheidungspunkte durchlaufen werden. Die Lösung ist flexibel angelegt und lässt sich an einen höheren "Bedarf an V-Modell XT" anpassen. (ue)

(Bilder/Grafiken: Fotolia, clabert , Microtool GmbH)