Brückenschlag:Das V-Modell XT mit Scrum insideAgile Vorgehensweisen wie Scrum und „schwergewichtige” Prozesse wie das V-Modell XT scheinen sich auf den ersten Blick nichtzu vertragen, da deutliche Unterschiede in der Philosophie der beiden Vorgehensweisen existieren. Jede hat ihre Stärken undSchwächen. Ist es sinnvoll und möglich, die Stärken der jeweils anderen Vorgehensweise zu nutzen? Dieser Frage geht der Artikelnach.

(Logistik, Produktion, Safety undSecurity) und zu anderen Themen, wiez. B. Lebenszyklus-Kosten, insbeson -dere auch für Fertigungs-, Betriebs- undAussonderungskosten.

■ Unerfahrene Teams erhalten durch dasV-Modell XT Hilfestellung – so könnensie vermeiden, das Rad immer wiederneu zu erfinden. Denn auch in einersehr innovativen und änderungsfreund-lichen Umgebung gibt es bewährteRäder, die man wiederverwenden soll-te. Einige der „Lücken” im Scrum-Framework können so durch geeigneteBestandteile des V-Modell XT gefülltwerden (siehe Abbildung 1).

Scrum in derSystementwicklungWelche Schwierigkeiten bereitet die An -wendung von Scrum in der System -entwicklung? Scrum erhebt den Anspruch,als Projektmanagement-Rahmenwerk soallgemeingültig zu sein, dass es nicht nur inder Softwareentwicklung zum Einsatzkommen kann, sondern in jedem beliebigenUmfeld. Warum aber beschränkt sich –Schätzungen zufolge – die Anwendung den-noch zu mehr als 90 % auf die Software -entwicklung? Warum bereitet es Schwierig -

und/oder Technologie neu sind. DieStärken sind unter anderem:

■ enge und vertrauensvolle Zusammen -arbeit mit dem Kunden

■ Anpassungsfähigkeit und Flexibilitätdurch die Vermeidung von frühzeitigendetaillierten Spezifikationen, kurzeItera tionen und Feedback-Zyklen,zumindest in der Softwareentwicklung

■ selbstorganisierende Teams und da -durch eine gesteigerte Mitarbeiter -motivation

■ kontinuierliche Verbesserungen imProjekt

Auf der anderen Seite können auch agileUnternehmen vom V-Modell XT profitie-ren:

■ Um sich an Ausschreibungen mit Vor -gabe V-Modell XT beteiligen zu kön-nen, ist es notwendig, eine „VM-Hülle”um die agile Vorgehensweise zu legen,ohne die Agilität damit in zu engeFesseln zu zwängen.

■ Das V-Modell XT liefert wichtige Hin -weise zur Zusammensetzung derTeams, zur frühzeitigen Einbeziehungder Schnittstellen zu Spezialdomänen

Wir wollen mit diesem Artikel dazu beitra-gen, eine Brücke zu schlagen. Durch unserejahrelange Mitarbeit an der Entwicklung desV-Modell XT (vgl. [Rau09], [Kra09]) undunsere Tätigkeit als Trainer, Prozess-Consultants und Coachs im V-Modell XT–und auch im agilen Umfeld (vgl. [Can09])wissen wir, dass es diese Brücke bisher kaumgibt. Dieser Artikel richtet sich sowohl an„Agilisten” als auch an V-Modell XT-Anwender, die sich vorurteilsfrei damit aus-einandersetzen wollen, wie sie von derjeweils anderen Seite lernen und profitierenkönnen. Dabei betrachten wir Scrum als denhäufigsten Vertreter von agilen Me thoden.

Integration von Scrumund V-ModellWarum ist die Integration von Scrum undV-Modell XT sinnvoll? Beide Ansätze ha -ben unterschiedliche Zielsetzungen undAusrichtungen: Flexibilität und Leichtge -wichtigkeit bei Scrum stehen einer forma-len Prozessunterstützung beim V-ModellXT gegenüber. Tabelle 1 zeigt die grund-sätzlichen Unterschiede.

Die Stärken der agilen Vorgehensweisensind auch für eine V-Modell XT-lastigeUmgebung wichtig, speziell für Projekte,bei denen Anforderungen noch instabil

der au tor

Sabine Canditt

(E-Mail: sabine.canditt@allianz.de)unterstützt als Certified Scrum Coach (neben CSM,CSP und CST), Expertin und Coach für AgilitätTeams und Organisations einheiten und engagiertsich für die agile Community innerhalb und außer-halb ihrer Firma.

1 www.objektspektrum.de

fachartikel

Doris Rauh

(E-Mail: doris.rauh@siemens.com)ist V-Modell-XT-Autorin und war u. a. verantwortlichfür die Definition der Konformitätsprüfung und desAssessment-Verfahrens des Modells. Sie führtV-Modell-XT-Schulungen durch und berät bei derAnwendung bzw. Anpassung des V-Modell XT.

Marion Wittmann

(E-Mail: marion.wittmann@siemens.com)ist V-Modell-XT Coach und Autorin des V-Modell XT.Zuletzt war sie beteiligt an der Definition der V-Modell-Konformitätsprüfung und des V-Modell-Assessment-Verfahrens.

keiten, ein Flugzeug in Iterationen von 30Tagen, inklusive aller qualitätssichernderMaßnahmen, zu entwickeln?

Eine agile Entwicklung setzt voraus, dassdie Kosten für Änderungen im Verlauf desProjekts maßvoll ansteigen und nicht expo-

nenziell in die Höhe schnellen (sieheAbbildung 2). Wenn das nicht gegeben ist,sind späte Änderungen, die eine agile

2Online-Themenspecial Agility 2011

Online-Themenspecial Agility 2011 fachartikel

SCRUM V-MODELL XT

Charakterisierung ■ Empirisches Projektmanagement-Framework, ■ Vorgehensmodell zur Entwicklung von Systemen, diebesonders geeignet für komplexe Umgebungen, Hardware und Software umfassen können.bei denen Anforderungen und Technologien neu ■ Entwicklungsprozess und Vorgehensweisen, z. B. füroder noch unsicher sind. Projektmanagement und Qualitätssicherung.

■ Verschiedene Projektdurchführungsstrategien je nach Stabilität der Anforderungen bzw. Erfahrungen mit der Technologie.

Bestandteile ■ Drei Rollen und eine Handvoll Meetings ■ Über 30 Rollen und ca. 100 Artefakte.und Artefakte.

■ Das selbstorganisierende Team entscheidet ■ Rollen, die für einzelnen Aspekte der Entwicklungeigenständig über die Aufgabenaufteilung und die verantwortlich sind, z. B. Systemarchitekt und dafür notwendigen Kompetenzen. Informationssicherheitsbeauftragter.

Typische Einsatzszenarien ■ Ideal: Softwareentwicklungsprojekte mit einem ■ Mittlere und größere Entwicklungsprojekte für Systemeoder wenigen Teams. mit Hardware- und/oder Softwareanteilen.

■ Auch anwendbar für mehrere 100 von ■ Auch für die Entwicklung von kleinen Softwaresystemen Mitarbeitern, auf mehrere Standorte verteilt. anwendbar.

Umgehen mit Änderungen ■ Hauptmotivation und inhärenter Bestandteil ■ Flexibilität gegenüber sich ständig änderndenvon Scrum (vgl. [Bra09]). Anforderungen steht nicht so stark im Vordergrund.

■ Anforderungen werden nicht zu Beginn komplettEine spezielle Projektdurchführungsstrategie soll diese

erfasst und spezifiziert, sondern kontinuierlich,Problematik lösen.

„just in time”.

Schnittstelle Auftrag- ■ Kommunikation und kurze Feedbackschleifen ■ Definierte Vorgehensweisen für zwei eng miteinandernehmer/Auftraggeber zwischen Auftraggeber und Auftragnehmer, kooperierende Projekte mit genau definierten

Vertrauensverhältnis. Schnittstellen, eines auf Auftragnehmer- und eines auf Auftraggeberseite. Feedback-Schleifen in den frühen Projektphasen sind erwünscht, aber nicht verpflichtend.

Iterationen ■ Kurze Iterationen gleicher Länge ■ Meist längere Iterationen gekoppelt an die vertraglich(Sprints, kürzer als 30 Tage). festgelegten Liefergegenstände. Mit jeder dieser

■ Am Ende einer Iteration potenziell auslieferbares Iteration müssen Entscheidungspunkte mit

Produktinkrement. entsprechendem Aufwand durchlaufen werden.

■ Zusätzlich auch kürzere interne Zyklen auf unteren Ebenen ohne Lieferung an den Auftraggeber möglich.

Entscheidungspunkte ■ Entscheidungspunkt beim Übergang in den ■ Zu jedem Entscheidungspunkt müssen definierte undnächsten Sprint: Der Product Owner (PO) qualitätsgesicherte Ergebnisse (Systemelemente und begutachtet die Arbeitsergebnisse und entscheidet Dokumente) vorliegen, die die Basis für den weiteren über den weiteren Verlauf. Projektverlauf bilden.

Dokumente ■ So wenig Dokumentation wie möglich. ■ Vorgegebene Templates (z. B. Architekturspezifikation)

■ Spezielle Dokumentation oder Verwendungbestimmter Templates (z. B. Architekturspezifikation)ist nicht Teil des Frameworks und muss gegebenen-falls als Teil der Done-Kritierien festgelegt werden.

Projektspezifische ■ Ergänzungen zum Framework notwendig ■ Erzeugung einer projektspezifischen ProzessbeschreibungImplementierung (z. B. „Definition of Done”, spezielle Engineering- und der zugehörigen Templates durch werkzeug-(siehe Abbildung 1) Methoden, Dokumente). unterstütztes Tailoring, d. h. durch Kürzen einer

Übermenge von potenziellen Projektergebnissen.

Kontinuierliche Verbesserung ■ Wesentliches Prinzip von Scrum; Retrospektiven ■ Eigener Projekttyp für eine kontinuierlicheam Ende jedes Sprints für jedes Team, sodass Prozessverbesserung, üblicherweise fürdie vorgeschlagenen Maßnahmen bereits im organisationsweite Prozesse ohne Auswirkungen auf nächsten Sprint zum Tragen kommen können. gerade laufende Projekte

Tabelle 1: Gegenüberstellung von Scrum und V-Modell XT.

methodenfrei sind und ein iterativ-inkre-mentelles Vorgehen fordern bzw. zulassen,auch wenn die äußerste Iteration im V-Modell XT bis zur jeweils nächstenLieferung an den Auftraggeber normaler-weise deutlich länger dauert als ein Scrum-Sprint.

In Scrum werden zwar nach jedem Sprintpotenziell auslieferbare Inkremente er -zeugt. Eine tatsächliche Auslieferung anden Kunden findet in der Regel aber erstnach mehreren Sprints statt, da sich einesinnvolle, vom Kunden nutzbare Funktio -nalität meist nicht in einem Sprint entwi -ckeln lässt. Diese Scrum-Releases entspre-chen also den äußeren Liefer-Iterationendes V-Modells. Innerhalb dieser Releaseskönnen wir zumindest für die Software -anteile kurze Sprints und damit auch kurzeFeedback-Schleifen nutzen. Dabei könnenwir den Auftraggeber einbeziehen und –wenn dieser, was leider häufig der Fall ist,nicht mitspielt – den Product Owner (PO)als Kundenvertreter nutzen. Bei sehr gro-ßen Entwicklungen kann der Auftraggebergar nicht für jedes Team in jeder IterationFeedback liefern. Wie in jeder agilenEntwicklung sollte der PO gezielt auswäh-len, welche Ergebnisse dem Kunden wannvorgestellt werden.

Wir können uns also Scrum als spezielle(Projekt-)Management-Vorgehensweise in -nerhalb des V-Modells vorstellen. ImFolgenden stellen wir die Integration derbeiden Ansätze vor, insbesondere bezüglichder Abläufe sowie der geforderten Ergeb -nisse und Rollen. Außerdem betrachten wirdie Themen Verträge und V-Modell-XT-Konformität.

AbläufeIm V-Modell XT gibt es Entscheidungs -punkte für die Fertigstellung vonDokumenten und Systemelementen. Dergenaue zeitliche Ablauf – wann und in wel-cher Reihenfolge diese Entscheidungs -

in Teilsysteme vor und gibt Unterstützungfür die einzelnen Disziplinen (Hardware,Software, Logistik, Systemsicherheit usw.)und deren Zusammenwirken.

Wie wir bereits erläutert haben, bereitetdie strenge Forderung nach kurzenIterationen mit gleicher Länge (kleiner als30 Tage) für Hardware- und Mechani k -entwicklung und damit für die System -ebene Schwierigkeiten. Abgesehen davonstellen wir aber fest, dass die übrigenScrum-Bestandteile – d. h. möglichst kurzeIterationen, Rollen, Artefakte und Mee -tings – sich mit dem V-Modell-Ansatz kombinieren lassen. Sie sind auf den unter-schiedlichen Ebenen der System ent wick -lung gewinnbringend an wend bar. Einesinnvolle Kombination der beiden Ansätzekann so aussehen:

■ Anwendung von Scrum auf den unter-schiedlichen Ebenen der Systement -wicklung des V-Modell XT

■ Aufnahme der V-Modell XT-Artefaktein die Done-Kriterien von Scrum

Eine wichtige Voraussetzung für dieKombination der Prozesse ist, dass beide

Vorgehensweise ja gerade ermöglichen soll,nicht mehr wirtschaftlich machbar.

Bei einer reinen Softwareentwicklungkann man das häufig durch eine gut wart-bare Architektur, permanente Refaktori -sierungen und automatische Regressions -tests erreichen. Auch bei Scrum sollte mansich Gedanken machen, welche Entschei -dungen frühzeitig getroffen werden müs-sen, da eine spätere Änderung sehr proble-matisch wäre (z. B. welches Frameworkverwendet wird oder welche Architekturdie Skalierbarkeitsanforderungen erfüllt).

Für Systementwicklungen mit Hard ware -anteilen lässt sich eine flache Entwicklungder Kostenkurve in vielen Fällen nicht errei-chen. Man versucht zwar in der Hardware –z. B. durch die intensive Nut zung vonSimulation und programmierbarer Logik –in kürzeren Zyklen und flexibel zu entwi -ckeln. Aber analoge Hardware und Mecha -nik lassen sich nicht immer in den Rhythmuskurzer Sprints von fester Länge pressen. Hierempfiehlt es sich keineswegs, auf kurze(Sprint-)Sicht mit Fokus auf spätere Änder-barkeit zu entwi ckeln. Daher ist es ist wich-tig, die Syn chronisation von Hardware- undSoftware anteilen mit den dazugehörigenInte grations- und System tests gut zu planen.

Integration von V-Modell XTund ScrumUnabhängig von der Methode muss mansich einen mehr oder weniger detailliertenÜberblick über die Systemarchitektur vonAnfang an verschaffen. Der Grad derDetaillierung ist abhängig vom System undden Kosten für spätere Änderungen (sieheoben).

Das V-Modell XT sieht ein hierarchi-sches Herunterbrechen des Gesamtsystems

fachartikel

3 www.objektspektrum.de

Abb. 1: Anwendung verschiedener Vorgehensweisen im Projekt.

Abb. 2: Einsatzmöglichkeiten von Scrum in Abhängigkeit von den zu erwartendenÄnderungskosten.

punkte durchlaufen werden – wird durcheinige vordefinierte Projektdurchführungs -stra tegien beschrieben. Diese erlaubenIterationen auf verschiedenen Ebenen: derGesamtsystem-, der System-, der Hard -ware- und der Softwareebene.

Wie bereits erwähnt, ist die Haupt -motivation für ein Scrum-Vorgehen dieFlexibilität und Anpassungsfähigkeit imUmgang mit Anforderungen bzw. nochunbekannten Technologien. Hierfür hältdas V-Modell XT die prototypische Pro -jektdurchführungsstrategie bereit, bei derdie Dokumentation erst nach derFertigstellung der zugehörigen System -elemente erstellt wird. Diese Strategie ver-wenden wir für die weitere Betrachtung.Alle anderen Projektdurchführungs -strategien gehen von stabilen Anfor -derungen aus und schränken damit dieEntfaltungsmöglichkeiten von Scrum ein.Natürlich bedeutet das nicht, dass wir mitdem Ergebnis nur Prototypen erzeugenkönnen: Es entstehen handfeste Produkte.In Abbildung 3 sind die verschiedenenEbenen der Systementwicklung, auf denenwir Scrum anwenden, farblich markiert.Die Iterationen auf den verschiedenenEbenen sind ineinander geschachtelt. Wirhaben für jeden dieser Bereiche folgendeElemente:

■ einen Product Backlog (PB) (was ist zutun)

■ einen Sprint Backlog (SB) (wie ist etwaszu tun)

■ Done-Kriterien

Der Inhalt der Done-Kriterien ergibt sichunter anderem aus den Entscheidungs -punkten des V-Modell XT, die in demScrum-Bereich zusammengefasst sind (z. B.„Systemelemente realisiert” und „Fein -entwurf abgeschlossen” auf der unterstenEbene). Die den jeweiligen Entschei -dungspunkten zugeordneten Ergebnisse(Systemelemente, Dokumente) müssen amEnde einer Iteration erstellt sein. Bei eineragilen Vorgehensweise würden z. B.„Feinent wurf” und „Realisierung” paralleldurchgeführt werden, sodass am Ende derIteration eine in sich konsistente Ergeb -nismenge inklusive Dokumente vorliegt.Das entspricht einem Zusammenlegen derEntscheidungspunkte des V-Modell XT aufder jeweiligen Ebene.

Im V-Modell XT kann ein Entschei -dungspunkt nur erreicht werden, wenn allebis zu diesem Zeitpunkt fertig gestelltenErgebnisse inklusive der Ergebnisse aus frü-heren Iterationen konsistent zueinander sind.Diese Forderung wird in Scrum nicht explizitgestellt und implizit nur durchRegressionstests bzw. Meetings zur Klärungvon Abhängigkeiten gewährleistet. Bei einemVorgehen nach „V-Modell XT mit Scruminside” muss die strengere Forderung, alsodie des V-Modells, berück sichtigt werden.Für die notwendigen Dokumente muss dieKonsistenz explizit im Rahmen der Done-Kriterien gefordert werden.

Damit stellt sich sofort die Frage, wieaufwändig diese Konsistenzerhaltung ist.Diesen Aufwand kann man folgenderma-ßen in Grenzen halten:

■ Der Umfang der vom V-Modell XTgeforderten Dokumentation kann inAbsprache mit dem Auftraggeber redu-ziert werden. Dies muss im Projekt -handbuch entsprechend dokumentiertund begründet werden.

■ Weiterhin kann man die Eigenschaftder prototypischen Projektdurchfüh -rungsstrategie nutzen, die eine Er -stellung der Dokumentation erst nachden zugehörigen Systemelementenerwartet und damit konform zu einerinkrementellen Dokumentenerstellungnach Scrum ist.

■ Im V-Modell gibt es das Konstrukt derinhaltlichen Produktabhängigkeiten.Durch diese wird definiert, welcheErgebnisse in einem inhaltlichen zuein-ander Zusammenhang stehen. Damiterhält man ein Tracing zwischen Er geb -nissen, ähnlich dem von An for -derungen, und kann sich damit bei derKonsistenzprüfung ganz gezielt auf dierelevanten Ergebnisse beschränken.

Ergebnisse und DokumentationWir wollen hier einem weit verbreitetenMissverständnis begegnen, dass in agilenEntwicklungen keine Dokumentationerzeugt wird und dass das Know-how aus-schließlich in den Köpfen der Entwicklersteckt. Dass dies bei Produkten mit langerLebensdauer, sicherheitskritischen Produk tenetc. nicht ausreichen kann, wird jeder einse-hen, der Erfahrung in diesen Bereichen hat.

Scrum verfolgt das Ziel, die projektinter-ne Dokumentation zu minimieren. Das ist

4Online-Themenspecial Agility 2011

Online-Themenspecial Agility 2011 fachartikel

Abb. 3: Scrum auf den verschiedenen Ebenen des V-Modell XT.

ersten Version eine Repräsentation desLastenhefts. Dazu kommen interne Anfor -derungen. Wie immer in Scrum, ist derProduct Backlog priorisiert. Nach undnach entwickelt er sich weiter und enthältin einem späteren Stadium auch diePflichtenheft-Informationen. Ob dieseWeiter entwicklung werkzeuggestützt ist,ob z. B. die Product Backlogs auf den unte-ren Ebenen nur Ausschnitte aus dem obe-ren Teil des Product Backlog sind oderkomplett separat gehandhabt werden, isteine Implementierungs- bzw. Tool-Ent -scheidung, die abhängig von der jeweiligenUmgebung getroffen werden muss (z. B.Größe und Verteiltheit der Entwicklung).

Rollen und Team-SetupDas Scrum-Rollenmodell besteht aus dendrei Rollen Product Owner (PO),Scrummaster (SM) und Team. Das Prinzipdes selbstorganisierenden Teams, das dievolle Verantwortung für seine Arbeits -ergebnisse trägt, ist von zentralerBedeutung. Dabei spielt es keine Rolle, obes sich um Tester, Entwickler, Daten -bankspezialisten usw. handelt – jeder istverantwortlich für das Teamergebnis.Natürlich muss darauf geachtet werden,dass die zur Erstellung des Produkt-

sollten in gemeinsamer Abstimmung mitdem Auftraggeber erfolgen und ebenfallsim Projekthandbuch festgehalten werden.

Die Templates des V-Modells könneneine Hilfestellung auch für Scrum-Projektesein, da Scrum nichts Derartiges anbietet.

Abbildung 4 zeigt die Scrum-ArtefakteProduct Backlog und Sprint Backlog sowiedie Inkremente auf den verschiedenenEbenen. Die unteren Ebenen liefern denoberen zu und müssen dort integriert wer-den. Es ist empfehlenswert, so weit wiemöglich mit festen, möglichst kurzenZeitfenstern zu arbeiten. Im einfachstenFall sind die Iterationen synchron (z. B. ineiner reinen Softwareentwicklung). Asyn -chrone Zulieferungen (z. B. Hardware)können jedoch auch berücksichtigt werden,indem sie in der nächsten regulär stattfin-dende Iteration der nächst höheren Ebeneberücksichtigt werden. Für jede Ebenemüssen entsprechende Done-Kriterienerstellt werden, die die Bedingungen defi-nieren, mit denen ein Inkrement von dernächst höheren Ebene übernommen wird.Eine konsequente Einhaltung der Done-Kriterien, wie beide Modelle sie fordern,kann für die Systemintegration nur hilf-reich sein.

Der Product Backlog auf der oberstenEbene (siehe Abbildung 5) enthält in seiner

oft möglich, weil alle Aktivitäten zurRealisierung von Anforderungen zeitnahaufeinander folgen und von cross-funktio-nalen Teams ausgeführt werden, die allezur Erstellung des Inkrements notwendigenDisziplinen in sich vereinen und ständigmiteinander kommunizieren. So könnenbeispielsweise Test-Skripts einen Teil derAnforderungsspezifikation oder SprintBacklogs bzw. Task-Boards einen fein-gra-nularen Projektplan ersetzen.

Die von außen gestellten Anforderungenan die Dokumentation lassen sich – ebensowie andere geschäftswirksame Anfor -derungen – in den Product Backlog bzw.die Done-Kriterien aufnehmen. Das giltsowohl für technische Dokumente als auchfür Projekt- bzw. Managementdokumente(z. B. das Projekthandbuch, in dem auchdas projektspezifische Tailoring dokumen-tiert ist). Dadurch lässt sich der Umfang derDokumentation flexibel an die jeweiligeProjektsituation anpassen. Es ist zumBeispiel denkbar, zu Beginn eines Projektsmit einem Minimum an Dokumenten zustarten und erst in späteren Iterationen mitder Ausarbeitung der vollständigen Doku -mentation zu beginnen. Mögliche Abwei -chungen der vom V-Modell XT geforder-ten Ergebnismenge mit dem Ziel einerMinimierung des Dokumentations anteils

fachartikel

5 www.objektspektrum.de

Abb. 4: Verschachtelte Iterationen.

Inkrements notwendigen Fähigkeiten undExpertise im Team vorhanden sind, da die-ses die Verantwortung sonst nicht überneh-men könnte. Man spricht daher auch voncross-funktionalen Teams. Scrum machtkeine weiteren Vorgaben für die Zu -sammen setzung des Teams.

Das V-Modell XT hingegen kennt eineVielzahl von Rollen mit zugehörigen Fähig -keitsprofilen. Dies kann wichtige Infor -mationen für die Zusammensetzung desProjektteams liefern. Wird beispielsweise indem zu entwickelnden System mit perso-nenbezogenen Daten umgegangen, sollteein Teammitglied Kenntnisse über die ein-schlägigen datenschutzrechtlichen Bestim -mun gen haben. Damit können die nichtenthaltenen Informationen über die imTeam benötigten Fähigkeiten auf einfacheWeise aus dem V-Modell XT abgeleitetwerden.

Im V-Modell XT gibt es folgende An -forderungen bezüglich der Rollenbeset zun -gen:

■ Bei unabhängigen Prüfungen darf derPrüfer nicht der Ersteller des Prüf -objekts sein. Da es aber erlaubt ist, dassder Prüfer Mitglied desselben Teams ist,kann die Prüfaufgabe problemlos voneinem Scrum-Team erfüllt werden.

■ Das V-Modell XT fordert eine Tren -nung zwischen Projektleiter und QS-Verantwortlichem. Dies wird bei Scrumdadurch gewährleistet, dass der PO dieRahmenbedingungen des Projekt -manage ments (Zeit, Termin, Kosten)verantwortet und der SM für den

Prozess und damit die Einhaltung vonRegeln zuständig ist und dafür sorgt,dass diese Regeln vom Team befolgtwerden. Darunter ist auch dieEinhaltung von Qualitätskriterien zuverstehen, wie sie in den Done-Kriterien festgeschrieben sind. Es wäredaher sinnvoll, dass der ScrumMasterdie Rolle des QS-Verantwortlichenübernimmt. Die Rolle kann aber prinzi-piell auch von einem anderen Team -mitglied, z. B. einem Tester, übernom-

men werden. Dabei darf es sich aller -dings nicht um den PO handeln.

■ Einer Integration von V-Modell XTund Scrum steht daher aus Sicht desRollenkonzepts nichts im Wege.

Für ein Vorgehen nach „V-Modell XT mitScrum inside” kann man sich folgendeBesetzung der in Scrum definierten Rollenfür die verschiedenen Ebenen vorstellen(siehe auch Abbildung 6): Auf der Gesamt -systemebene ist der PO die Schnittstellezum Kunden. Manchmal, wenn Auftrag -geber und Auftragnehmer sich über dieVorgehensweise verständigen, füllt sogareine Person auf der Kundenseite diese Rolleaus und benötigt dann einen entsprechen-den Gegenpart auf der Auftragnehmer-seite.

Beim Herunterbrechen der Aufgaben(vom Gesamtsystem über das System bishin zu Hardware und Software) stellt diehöhere Ebene den „Kunden” für die darun-ter liegenden Ebenen dar. So können wirauf jeder Ebene einen PO-Vertreter instal-lieren, der die Anforderungen der „Kun -den” gegenüber den Teams der darunterliegenden Ebene vertritt, mit dem„Kunden” offene Punkte klärt und dieErgebnisse abnimmt. Jedes Team hat alsoeinen PO-Vertreter als Ansprechpartnerund ein PO-Vertreter kann – je nachAuslastung – ein oder mehrere Teams

6Online-Themenspecial Agility 2011

Online-Themenspecial Agility 2011 fachartikel

Abb. 5: Entwicklung des Product-Backlog.

Abb. 6: Teams auf verschiedenen Ebenen.

die hier beschriebene Vorgehensweiseals konform zur Entwicklungsstrategie„Prototypische Systementwicklung”betrachtet wird.

Unter den genannten Randbedin gungensteht der V-Modell-XT-Konfor mi tät desVorgehens „V-Modell XT mit Scrum insi-de” nichts im Wege. Welche Möglichkeitenbestehen für „agile” Auftragnehmer, dasbeschriebene Vorgehen „V-Modell XT mitScrum inside” in V-Modell-XT-Projekteneinzusetzen? Dafür gibt es zwei verschiede-ne Wege:

■ Verfügt der agile Auftragnehmer übereine eigene Prozessbeschreibung, kanner den Weg der Konformitätsprüfunggehen. Als Ergebnis erhält sein Prozessdas Zertifikat „V-Modell XT Konf”und kann in Absprache mit demAuftraggeber in V-Modell-XT-Projek -ten eingesetzt werden.

■ Liegt keine Prozessbeschreibung vor,besteht die Möglichkeit, die Abwei -chungen vom V-Modell XT, die sichdurch ein Vorgehen nach „V-ModellXT mit Scrum inside” ergeben, imProjekthandbuch zu beschreiben. Die -ser Teil des Projekthandbuchs wird demAngebot beigelegt. Im Vertrag mussdann geregelt werden, dass diesesVorgehen vom Auftraggeber akzeptiertwird. Im Projektverlauf kann aufWunsch des Auftraggebers durch ein V-Modell-XT-Audit (vgl. [Rau09]) über-prüft werden, ob die vertraglichenRegelungen in diesem Projekt eingehal-ten wurden.

Bei beiden Ansätzen sind Anpassungen imProzess notwendig, zu denen man sich Ratvon Experten holen kann, die sich sowohlmit dem V-Modell XT als auch mit agilenVorgehensweisen auskennen.

FazitDie Integration von Scrum ins V-Modell XTist nicht trivial, aber möglich. Sie sollte wohl-überlegt angegangen werden, wenn sichdadurch für das Projekt Vorteile abzeichnen.Das ist unter folgenden Rand bedingungender Fall:

■ Zu Projektbeginn liegen die Anfor -derungen nicht vollständig vor, sieändern sich im Entwicklungsverlauf aufder Basis neuer Erkenntnisse oder eswerden erstmals neue Technologienerprobt.

V-Modell-XT-Konformitätund -AuditIm Rahmen der V-Modell-XT-Konformität(vgl. [Rau09]) wird überprüft,

■ ob die Prozessbeschreibung bestimmtenGütekriterien genügt.

■ ob die durch das V-Modell XT definier-ten Inhalte durch den betrachtetenProzess abgedeckt sind.

Ist das hier vorgeschlagene Vorgehen „V-Modell XT mit Scrum inside” V-Modell-XT-konform? Um diese Fragen zu beant-worten, betrachten wir eine fiktiveorganisationsspezifische Prozessbeschrei -bung, die auf den Ideen beruht, die wir indiesem Artikel beschrieben haben. DieseProzessbeschreibung soll den in der V-Modell-XT-Konformität definierten Güte -kriterien genügen. Untersucht werden da -her im Folgenden nur die Anforderungenan die Inhalte. Wir unterscheiden zwei gro-ße Themengebiete:

■ Überprüfung der im V-Modell XT defi-nierten Ergebnismenge: Hierbei wirdüberprüft, ob der betrachtete Prozessdie gleiche Ergebnismenge erstellt wiedas V-Modell XT. In der Prozess -beschreibung sollte daher festgelegtsein, dass die Erstellung der im V-Modell XT definierten Ergebnismengeals Anforderung in den ProductBacklog aufgenommen wird. DieseErgebnismenge wird für ein Projektdurch das projektspezifische Tailoringund durch die im V-Modell XT spezifi-zierten erzeugenden Produktabhängig -keiten festgelegt. Mögliche projektspe-zifische Abweichungen müssen imProjekthandbuch dokumentiert undmit dem Auftraggeber abgestimmt wer-den.

■ Überprüfung der Vorgaben an Abläufe:Das V-Modell XT enthält aktuell keineVorgaben an Abläufe, deren Einhaltungim Rahmen einer Konformitätsprüfungüberprüft werden kann. Diese Vor -gaben werden in Kürze durch den„Weit e.V.” (Verein zur Weiterent -wicklung des V-Modell XT) festgelegt.Die Vorgehensweise, die wir in diesemArtikel vorgeschlagen haben, entsprichtgenau der Intention der Ent wick -lungsstrategie „Prototypische System -entwicklung”. Wir werden daher beider Festlegung der Vorgaben anAbläufe den Vorschlag machen, dass

betreuen. Die PO-Vertreter ihrerseits müs-sen sich – basierend auf den Schätzungenihrer Teams – untereinander absprechen,damit die einzelnen Teile der Entwicklungzeitlich zusammenpassen. Um denInformationsfluss zu gewährleisten undfrühzeitig mögliche Probleme erkennenund beheben zu können, sollten auchVertreter der unteren Ebenen in den Teamsder darüber liegenden Ebene mitwirken.Beispielsweise sollten Vertreter aus denHardware- und Softwareteams in denSystementwurf und in die System inte -gration einbezogen sein.

Die Scrum-Meetings (Daily Scrum,Iteration Planning, Review, Retrospective)werden ebenfalls auf jeder Ebene abgehal-ten. Bei der Zusammensetzung der Teamsund ihrer Meetings sind die Abhängig -keiten zwischen den Teams zu beachten. Sokann es zum Beispiel sinnvoll sein, dass derVertreter eines Hardwareteams amIteration Planning eines Softwareteamsteilnimmt oder dass Vertreter aus Ent -wicklungsteams in die Aktivitäten vonIntegrationsteams einbezogen sind.

Die hierarchische Struktur und das Zu -sammenwirken mehrerer POs und Teamsführt zu längeren und komplizierterenEntscheidungswegen und beschränkt damitnatürlich auch die Reaktionsge schwin -digkeit. Das ist die Konsequenz einer gro-ßen Entwicklung. Wichtig ist, dass nicht eineinzelner PO zum Flaschenhals wird, son-dern dass er seine Teams rechtzeitig mit denInformationen versorgt, die sie brauchen,um sich auf ihre Aufgaben konzentrierenzu können. Viele der hier beschriebenenVorgehensweisen zur Ska lierung von Scrum(Scrum of Scrum) sind bereits in großenProduktentwicklungen – wenn auch bishermeist für reine Soft wareentwicklungen –erprobt (vgl. [Lar08]).

VerträgeIm V-Modell XT wird erwartet, dass dasLastenheft im Rahmen des Vertrags festge-schrieben wird und am Ende der An -gebotsphase bzw. zu Beginn derRealisierungsphase vorliegt. Ein Festpreis-vertrag, der auf einer detaillierten Spezifi -kation des Lastenheftes beruht, passt nichtgut zu einer agilen Vorgehensweise, derenHauptaugenmerk ja gerade auf dem flexi-blen Umgang mit Anforderungen liegt.Inzwischen gibt es unterschiedliche Ver -trags modelle, die dies berücksichtigen (vgl.z. B. [Ste09], [Coc06], [Sch09]).

fachartikel

7 www.objektspektrum.de

■ Ein Herunterbrechen des Gesamt -systems in Teilsysteme ist unbedingtnotwendig, um die Entwicklung in denGriff zu bekommen.

Die ideale Umgebung für Scrum – und auchfür andere Vorgehensweisen – ist das „oneroom team”, das eine optimale Kom -munikation und Flexibilität im Projekt -verlauf gewährleistet. In einer „System ofSystems”-Umgebung, d. h. in einem Ge -samt system, das in eine Reihe vonTeilsystemen zerfällt, gibt es viele hierar-chische Teams und viele Schnittstellen zwi-schen diesen – und damit zwangsläufigmehr Overhead und längere Feedback-Schleifen. Das V-Modell XT unterstützt beider sinnvollen Aufteilung des Gesamt -systems in Teilsysteme und bei derDefinition der Schnittstellen zwischen die-sen. Für die Entwicklung jedes dieserTeilsysteme können wiederum die Stärkenvon Scrum ausgespielt werden. Ganz wich-tig ist gerade in diesem Umfeld die richtigeZusammenstellung der cross-funktionalenTeams. Wesentliche Informa tionen über diebenötigten Kompetenzen liefert das V-Modell XT, da es das Zusammenspielverschiedener Spezial disziplinen, wie z. B.Logistik, Safety und Security , beschreibt.Unser Vorschlag, ein hierarchisches Scrum-of-Scrum-Modell auf die Ebenen des V-Modells XT anzuwenden, verkürzt dieInformationswege und ermöglicht auch ineinem komplexen Umfeld vertretbareFeedback-Zyklen.

Templates für die zu erstellende Doku -mentation können dem V-Modell XT ent-nommen werden, damit das Team das Radnicht jedes Mal neu erfinden muss und so

unnötige Arbeit vermieden wird. DerUmfang der Dokumentation wird wenigerdurch das V-Modell XT bestimmt als durchdie Anforderungen einer großen, langle -bigen Produktentwicklung. Die Integrationder beiden Vorgehensweisen ermöglichtdamit eine Anpassung des Prozesses an diejeweilige Projektsituation.

Unser Vorschlag zeigt, wie man V-Modell XT und Scrum sinnvoll mitein-

ander kombinieren kann. Damit Projekteproduktiv und erfolgreich damit arbeitenkönnen, ist eine enge und vertrauensvolleZusammenarbeit zwischen Auftraggeberund Auftragnehmer entscheidend – zumBeispiel bei der Definition einer denProjektzielen angepassten Menge vonDokumenten und bei der Nutzung vonFeedback sollte ein integriertes Vorgehenmit dem Auftraggeber abgestimmt sein. ■

8Online-Themenspecial Agility 2011

Online-Themenspecial Agility 2011 fachartikel

Literatur & Links

[Bra09] P. Braun, S. Canditt, Wenn der Kunde nicht weiß, was er will: Tipps für den agilen

Umgang mit Anforderungen, in: OBJEKT spektrum 5/2009

[Can09] S. Canditt, P. Braun, Scrum Coaching – Hilfe zur Selbsthilfe, in: OBJEKTspektrum

3/2009

[Coc06] A. Cockburn, Agile Contracts, siehe: http://alistair.cockburn.us/Agile+contracts

[Frie08] J. Friedrich, M.U. Hammerschall, M. Kuhrmann, M. Sihling, Das V-Modell XT,

Springer-Verlag 2008

[Höh08] R. Höhn, S. Höppner, Das V-Modell XT: Springer-Verlag 2008

[Kra09] W. Kranz, D. Rauh, flyXT: Das neue Vorgehensmodell der EADS DE, in: OBJEKT -

spektrum 2/2009

[Lar08] C. Larman, B. Vodde, Scaling Lean and Agile Development, Addison Wesley 2008

[Rau09] D. Rauh, M. Wittmann, V-Modell-XT-Konformität und -Assessment, in: OBJEKT -

spektrum 3/2009

[Sch09] D. Schreiber, Agile Vorgehensmodelle und öffentliche Beschaffungen nach VOL, in: Proc.

of V-Modell Anwenderkonferenz des ANSSTAND e.V., 2009

[Scrum] Scrum Guide, siehe: http://www.scrumalliance.org/resources/598

[Ste09] P. Stevens, 10 Contracts for your next agile project, 2009, siehe:

www.scrumalliance.org/resources/1119

[VMXT] Der Beauftragte der Bundesregierung für Informationstechnik (BFI), Das V-Model XT,

siehe: URL: www.v-modell-xt.de