Integration agiler Entwicklungszyklen in das V-Modell auf ... · SCRUM in ihren V-Modell-basierten...

Gottfried WilhelmLeibniz Universität Hannover

Fakultät für Elektrotechnik und InformatikInstitut für Praktische InformatikFachgebiet Software Engineering

Integration agiler Entwicklungszyklen indas V-Modell auf Basis von

Informationsflüssen

Masterarbeit

im Studiengang Informatik

von

Stephan Kiesling

Prüfer: Prof. Dr. Kurt SchneiderZweitprüfer: Dr.-Ing. Eric Knauss

Betreuer: M. Sc. Kai Stapel

Hannover, 27.10.2011

Zusammenfassung

Um die Vorteile sowohl dokumentenlastiger, als auch agiler Prozesse in einem einzi-gen Projekt nutzen zu können, wird in dieser Arbeit am Beispiel von SCRUM ein agilerEntwicklungsprozess in das V-Modell XT integriert.

Die Integration geschieht auf Basis von Informationsflüssen. Es werden zuerst Infor-mationsflüsse in beiden Prozessen ermittelt und analysiert. Anschließend werden dieInformationsflüsse an den Schnittstellen der Prozesse angepasst, so dass eine Inte-gration möglich wird.

Zum Schluss werden Integrationsvarianten beispielhaft angegeben, um unterschiedli-che Integrationsbereiche zu kennzeichnen. Diese können mit Hilfe eines Leitfadens andie Bedürfnisse von Unternehmen angepasst werden.

ii

Inhaltsverzeichnis

1 Einleitung 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Ziele der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Grundlagen 32.1 Vorgehensmodelle bei der Softwareentwicklung . . . . . . . . . . . . . . 3

2.1.1 Dokumentenlastige Prozesse . . . . . . . . . . . . . . . . . . . . 32.1.2 Agile Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 V-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.1 V-Modell XT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 FLOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4.1 FLOW-Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.2 FLOW-Methode . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4.3 Einordnung der Arbeit mit Hilfe der FLOW-Methode . . . . . . . 182.4.4 Informationen und Informationsflüsse . . . . . . . . . . . . . . . 19

3 Informationsflüsse in SCRUM und im V-Modell XT 233.1 Grundidee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2 Annahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3 Beschreibung von SCRUM auf Basis von Informationsflüssen . . . . . . 263.4 Beschreibung des V-Modells auf Basis von Informationsflüssen . . . . . 28

3.4.1 Produktabhängigkeiten . . . . . . . . . . . . . . . . . . . . . . . 293.4.2 Von den Produktabhängigkeiten zum Informationsfluss . . . . . 31

4 Anpassung von SCRUM an die Informationsflüsse des V-Modells 344.1 Grundlegende Schnittstellenvarianten . . . . . . . . . . . . . . . . . . . 34

4.1.1 Schnittstellenvariante 1: Elementarer Informationsfluss . . . . . 364.1.2 Schnittstellenvariante 2: Sequentieller Informationsfluss . . . . . 374.1.3 Schnittstellenvariante 3: Paralleler Informationsfluss . . . . . . . 374.1.4 Schnittstellenvariante 4: Informationsfluss mit mehreren Eingän-

gen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.1.5 Schnittstellenvariante 5: Informationsfluss mit mehreren Ausgän-

gen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2 Anpassung von SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.1 Kunde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.2 SCRUM Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.3 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

iii

Inhaltsverzeichnis

4.2.4 Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.5 SCRUM Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.6 Daily SCRUM Meetings . . . . . . . . . . . . . . . . . . . . . . . 464.2.7 Sprint Planning Meeting . . . . . . . . . . . . . . . . . . . . . . . 474.2.8 Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2.9 Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3 Vor- und Nachteile der Integration . . . . . . . . . . . . . . . . . . . . . 504.3.1 Vorteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.2 Nachteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.4 Probleme bei der Integration von SCRUM . . . . . . . . . . . . . . . . . 51

5 Integrationsvarianten von SCRUM in das V-Modell XT 545.1 Integrationsvarianten auf Basis von Entscheidungspunkten . . . . . . . 55

5.1.1 Variante 1: SCRUM für Systementwicklung . . . . . . . . . . . . 585.1.2 Variante 2: SCRUM für Komponentenentwicklung . . . . . . . . 615.1.3 Variante 3: SCRUM für Entwurf . . . . . . . . . . . . . . . . . . . 645.1.4 Variante 4: SCRUM für Realisierung, Integration und Test . . . . 65

5.2 Allgemeine Variationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.2.1 Anzahl der eingesetzten Teams . . . . . . . . . . . . . . . . . . . 685.2.2 Endpunkt der Integration von SCRUM für Entscheidungspunkte . 685.2.3 Integration von SCRUM ohne Entscheidungspunkte . . . . . . . 695.2.4 Integration von SCRUM für einzelne Informationsflüsse . . . . . 695.2.5 Nachdokumentation . . . . . . . . . . . . . . . . . . . . . . . . . 70

6 Implementierung 736.1 Prototypische Entwicklung zur Ermittlung und Darstellung von Produkt-

abhängigkeiten des V-Modells . . . . . . . . . . . . . . . . . . . . . . . . 736.1.1 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.1.2 Technische Realisierung . . . . . . . . . . . . . . . . . . . . . . . 77

6.2 Leitfaden zur Integration von SCRUM in das V-Modell XT . . . . . . . . 776.2.1 Gewichtung der Kriterien des Leitfadens . . . . . . . . . . . . . . 80

7 Fazit 827.1 Kritische Würdigung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

iv

1 Einleitung

1.1 Motivation

Dokumentenlastige Prozesse wie das V-Modell sind in der Regel, auf Grund des ho-hen Anteils zu erstellender Dokumente, sehr unflexibel. Späte Änderungen der Anfor-derungen verursachen einen hohen Zeit- und Kostenaufwand und sind in vielen Fällennur durch Nachverhandlung mit dem Kunden möglich. Zudem fließt ein hoher Anteilder Projektzeit in die Erstellung vieler Dokumente.

Diese Nachteile versuchen die agilen Methoden, ihnen voran SCRUM, zu beheben, in-dem funktionierende Software wichtiger als umfassende Dokumentation gesetzt wird.Kundenzufriedenheit wird als höchstes Gut betrachtet, Flexibilität als Grundvorausset-zung angesehen. Dadurch gehen allerdings einige Vorteile, welche die umfassendeErstellung von Dokumenten mit sich bringt, verloren.

Auf Grund der Unterschiede zwischen dokumentenlastigen und agilen Prozessenist es nicht offensichtlich, wie diese in einem Projekt zu vereinen sind. Gelingt diesaber, ist es vorstellbar, dass sowohl die Vorteile dokumentenlastiger Prozesse, alsauch die Vorteile agiler Methoden genutzt werden können.

1.2 Ziele der Arbeit

In dieser Arbeit soll SCRUM, als die häufigste, in Projekten verwendete agile Methode,in das V-Modell XT integriert werden, um die Vorteile beider Prozesse ausnutzen zukönnen und ihre Nachteile möglichst gering zu halten.

Die Integration selbst soll auf Basis von Informationsflüssen geschehen, da viele rele-vante Softwareentwicklungsphänomene mit Informationsflüssen beschrieben werdenkönnen.

Die Arbeit soll eine Vorgehensweise beschreiben, mit dessen Hilfe UnternehmenSCRUM in ihren V-Modell-basierten Entwicklungsprozess einbinden können. Dazu sollaufgezählt werden, welche Anpassungen vorgenommen werden müssen, damit eineIntegration von SCRUM durchgeführt werden kann. Zudem werden Varianten angege-ben, die sich für die Integration gut oder weniger gut eignen.

1

1 Einleitung

1.3 Aufbau der Arbeit

Die Arbeit gliedert sich in insgesamt sieben Kapitel. In gewisser Weise beschreibt die-se Gliederung, wie in Abbildung 1.1 dargestellt wird, ebenfalls eine Art „V“. Nach den indiesem Kapitel vorgenommenen, einleitenden Worten, werden in Kapitel 2 die Grund-lagen erklärt, die für diese Arbeit benötigt werden. Ausgehend von diesen Grundlagenwird in Kapitel 3 ein Abstraktionsschritt nach unten durchgeführt, der das V-Modell undSCRUM auf Basis von Informationsflüssen beschreibt. Basierend auf den Informati-onsflüssen werden in Kapitel 4 Anpassungen an SCRUM vorgenommen. Anschlie-ßend werden die so entstandenen Informationsflüsse von SCRUM am Beispiel vonIntegrationsvarianten in den gesamten Informationsfluss des V-Modells integriert, wasin Kapitel 5 geschieht. Zum Schluss gibt der in Kapitel 6 vorgestellte Leitfaden ei-ne grundlegende Übersicht über die Integration, wie auch der Prototyp zur Ermittlungund Darstellung von Produktabhängigkeiten des V-Modells eine Übersicht über die In-formationsflüsse des V-Modells vermittelt. Ein Fazit der vorherigen 6 Kapitel wird inKapitel 7 vorgenommen.

Abbildung 1.1: Graphische Visualisierung der Gliederung dieser Arbeit

2

2 Grundlagen

2.1 Vorgehensmodelle bei der Softwareentwicklung

Unter einem Vorgehensmodell oder auch Softwareentwicklungsprozess versteht maneine Vorgehensweise oder ein Modell, das ein genaues Vorgehen zur Herstellung vonSoftware spezifiziert [SCHNEIDER 2010]. Dabei werden die Ingenieursprinzipien

• Kostendenken

• Qualitätsbewusstsein

• Anwendung von Normen und Regeln

• Baugruppen und Wiederverwendung

• Probleme durch Zerlegung lösen

genau berücksichtigt, um eine schnelle, qualitativ hochwertige Erstellung von Softwarezu gewährleisten.

Ein derartiges Vorgehensmodell dient als Aufbau- und Ablaufplan, um Software ko-ordiniert zu erstellen. Dadurch wird der Vorgang der Softwareentwicklung verbessertund standardisiert. Die Entwicklung einzelner Teilstücke wird zeitlich und kontextuellbegrenzt. Für jeden Entwicklungsschritt kann der Plan angeben, welches Produkt ausdem jeweiligen Schritt entstehen soll. Dies können zum Beispiel fertige Teilstücke oderauch Dokumente sein, an die wiederum vom Entwicklungsprozess Qualitätsbedingun-gen gestellt werden können. Außerdem lässt sich das Projekt einfacher planen undder aktuelle Entwicklungsstand des Projekts besser einschätzen.

Im Laufe der Zeit haben sich zwei große, gegensätzliche Vorgehensmodelltypen ent-wickelt, die nachfolgend dargestellt werden sollen.

2.1.1 Dokumentenlastige Prozesse

Die folgenden Grundlagen basieren auf [SCHNEIDER 2010, vor].

Der Fortschritt eines dokumentenlastigen Prozesses wird an der Erstellung von Doku-menten gemessen, was wiederum durch das Verarbeiten von Dokumenten geschieht.Ob ein Prozess starten kann, hängt davon ab, ob die benötigten Dokumente vorliegen.Ebenso ist ein Prozess beendet, wenn die erzeugten Dokumente den geforderten Do-kumenten entsprechen. Es stehen also die Dokumente eines solchen Prozesses imVordergrund.

Zu Beginn eines jeden Projekts muss überlegt werden, welches Vorgehensmodell ein-

3

2 Grundlagen

gesetzt werden soll. Dies ist keine leichte Entscheidung und kann zusätzlich erheblicheKosten verursachen, wenn das falsche Vorgehensmodell gewählt wurde. Die Wahl desVorgehensmodells hängt von vielen Faktoren ab. Die wichtigsten sind:

• Akzeptanz im Unternehmen

• Vertrautheit mit Vorgehensmodellen und Tools

• Standardsoftware im Unternehmen

• Implementierungsfähigkeiten des Vorgehensmodells

• Nutzen, den dieses Vorgehensmodell bringt

• Kosten, die dieses Vorgehensmodell verursacht

• Betrachtung, ob V-Modell ein möglicher Kandidat ist

Dies sind nur einige der Fragen, die bei der Wahl des passenden Vorgehensmodells inBetracht gezogen werden müssen. Es ist empfehlenswert zu prüfen, ob das V-Modellgeeignet ist. Die Gesellschaft für Informatik [vor] empfiehlt auf jeden Fall zu prüfen,ob das V-Modell geeignet ist und hebt dieses namentlich hervor. Neben dem V-Modellgibt es allerdings noch weitere Modelle:

Wasserfallmodell Das Wasserfallmodell unterteilt den Prozess der Softwareentwick-lung in unterschiedliche Phasen. Jede Phase (bis auf die erste) benötigt alsEingabe die Ausgabe der vorherigen Phase. Alle Phasen werden nacheinanderabgearbeitet. Im erweiterten Wasserfallmodell sind Rücksprünge zu vorherigenPhasen möglich.

Spiralmodell Nach dem Wasserfallmodell folgte das Risiko-getriebene Spiralmodell.Im Projekt auftretende Risiken sollen dabei möglichst früh erkannt und entschärftwerden. Die Idee ist, alle Risiken zu suchen und jeweils das größte Risiko zu eli-minieren. Gibt es keine Risiken mehr, ist das Projekt erfolgreich abgeschlossen.Ist das größte Risiko nicht zu eliminieren, ist das Projekt gescheitert.

V-Modell / V-Modell XT Eine detaillierte Beschreibung des V-Modells wird in Kapitel2.2 gegeben.

Allerdings sind Änderungs- oder Anpassungswünsche am Konzept des Produkts oderder Software selbst – abhängig vom gewählten Vorgehensmodell – nicht immer leichtdurchzuführen. Oft werden späte Änderungen vom Kunden teuer bezahlt oder sindschlimmstenfalls nicht umsetzbar. Dies liegt in der Natur der Vorgehensmodelle, diemehr oder weniger starr ablaufen. Das Wasserfallmodell sieht beispielsweise ursprüng-lich nicht vor, dass Stufen, die bereits durchlaufen wurden, erneut aufgegriffen werdenkönnen.

2.1.2 Agile Methoden

Die in Kapitel 2.1.1 beschriebenen Prozesse verlangen viele Dokumente (Lastenheft,Pflichtenheft, Dokumentation der Anforderungen, Dokumentation des Grobentwurfs,

4

2 Grundlagen

Dokumentation des Feinentwurfs und viele mehr) und somit einen sehr hohen Zeitauf-wand für das Erstellen dieser Dokumente, was gleichzeitig eine geringere Zeitspannefür die eigentliche Implementierung nach sich zieht. Dies führte zu der Entwicklung derAgilen Methoden und dem „Manifesto for Agile Software Development“ [agi] und kannals Gegenbewegung zu den dokumentenlastigen Prozesse verstanden werden.

Das Agile Manifesto besagt Folgendes [agi]:

„We are uncovering better ways of developing software by doing it and helping othersdo it. Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the leftmore.“

[Wir enthüllen bessere Wege der Softwareentwicklung, indem wir Software entwickelnund anderen dabei helfen, Software zu entwickeln. Aufgrund dieser Tätigkeit sind wirzu dem Schluss gekommen, die folgende Wertung vorzunehmen:

• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge

• Funktionierende Software ist wichtiger als eine umfassende Dokumentation

• Kundenzusammenarbeit ist wichter als Vertragsaushandlungen

• Auf Änderungen zu reagieren ist wichtiger als einem Plan zu folgen

Obwohl die Aspekte auf der rechten Seite auch wichtig sind, gestehen wir den Aspek-ten auf der linken Seite ein höheres Gewicht zu.]

Basierend auf [SCHNEIDER 2011] zeichnen sich Agile Methoden durch einige Aspektebesonders aus. Sie liefern früh erste Ergebnisse, die dem Kunden präsentiert werdenkönnen. Dadurch kann der Kunde abschätzen, ob das Projekt in die richtige Richtunggeht. Unklar formulierte Anforderungen werden leicht als solche erkannt und könnengenauso leicht durch Zusammenarbeit mit dem Kunden geklärt werden. Späte Ände-rungen des Kunden können zeitnah durchgeführt werden und es wird eine hohe Qua-lität erreicht. Diese Aspekte sind umso wichtiger, da der Zeitdruck für aktuelle Projekteimmer größer wird. Deutlich wird auch, dass die Zusammenarbeit mit dem Kunden imVordergrund steht.

Eines der wichtigsten Ziele der Agilen Methoden ist, Software-Entwicklung flexibler zumachen. Dies wird versichert, indem sogenannte Grundwerte, Prinzipien und Prakti-ken definiert wurden.

Die Grundwerte (vergleiche Agile Manifesto oben) dienen als gemeinsame Basis. Vonihnen werden die Prinzipien abgeleitet. Aus den Prinzipien ergeben sich wiederum diePraktiken, die für jede Agile Methode (z.B. SCRUM, vergleiche Kapitel 2.3) anders

5

2 Grundlagen

formuliert sein können.

Zur Verdeutlichung sei das folgende Beispiel gegeben: Ein Grundwert ist gemäß demAgile Manifesto „Kundenzusammenarbeit ist wichtiger als Vertragsaushandlungen“.Dies wird zum Beispiel durch die Prinzipien „Höchste Priorität: Kundenzufriedenheit“,„Direkte Mensch-zu-Mensch Kommunikation“ und „Auch späte Änderungen werdenwillkommen geheißen“ genauer umgesetzt. Die konkrete Umsetzung der Prinzipiengeschieht unter anderem durch die Praktiken (in diesem Fall von Extreme Program-ming) „On-site Customer“, „Short Releases“ und „Planning Game“.

Hohe Flexibilität wird insbesondere durch die höchste Priorität für Kundenzufriedenheitund die daraus resultierende enge Zusammenarbeit mit dem Kunden gewährleistet.Ohne hohe Flexibilität ist eine hohe Kundenzufriedenheit nur sehr schwer zu erreichen.

2.2 V-Modell

Das V-Modell1 ist nach [LUDEWIG . LICHTER 2007, Seiten 178-190], [vmo] ein interna-tional anerkannter Entwicklungsstandard für IT-Systeme, der einheitlich und verbind-lich festlegt, was zu tun ist, wie die Aufgaben durchzuführen sind und womit dies zugeschehen hat. Es umfasst das Vorgehensmodell, die Methodenzuordnung und diefunktionalen Werkzeuganforderungen [vmo].

Dabei steht das „V“ nicht nur für „Vorgehen“, sondern auch für die Idee, die hinterdem V-Modell steckt. Die Aufgabenbereiche Spezifikation und Zerlegung auf der einenSeite stehen der Realisierung und Integration auf der anderen Seite gegenüber. Abbil-dung 2.1 zeigt einen möglichen Ablauf in der Systementwicklung, welche zwischen derProjektplanungs- und abschlussphase durchgeführt wird. Letztere laufen in der Regellinear ab, während das eigentliche „V“ nur in der Systementwicklung auftaucht.

Die Entwicklung des ersten V-Modells begann im Jahr 1986 und wurde vom deut-schen Bundesministerium für Verteidigung in Auftrag gegeben, worauf im Jahr 1993eine allgemeine Fassung für sämtliche Bundesbehörden folgte. Im Jahr 1997 wurdedas V-Modell überarbeitet, um es an gängige Entwicklungsstandards und -ansätze an-zupassen. Im Februar 2005 entstand aus dem V-Modell das V-Modell XT, welchesFirmen mehr Flexibilität in Bezug auf die Anpassung des V-Modells an die eigene Un-ternehmensstruktur bieten sollte (vergleiche Kapitel 2.2.1).

Da das V-Modell 1996 öffentlich zugänglich gemacht wurde, war es für Unternehmenmöglich, das V-Modell ohne das Risiko einer Fehlinvestition leicht auszuprobieren. Da-durch nahm die Verbreitung des V-Modells zu und es konnten Erfahrungen über dieBenutzung und den Umgang mit dem V-Modell gemacht werden. Diese Erfahrungenwurden dokumentiert und flossen in die Entwicklung des V-Modells ’97 ein.

Das V-Modell ist bei den Beauftragten der Bundesregierung für Informationstechnikerhältlich [vmo]. Es liegt aktuell in der Version 1.3 vor und beinhaltet Werkzeuge zurAnpassung der Prozesse an die Bedürfnisse des Unternehmens und zur Durchführung

1V-Modell R© ist eine geschützte Marke der Bundesrepublik Deutschland

6

2 Grundlagen

und Planung des Projekts, sowie eine umfassende Dokumentation, die sich selbst alsPflichtlektüre für jeden Entwickler bezeichnet, der mit dem V-Modell arbeitet.

Produktinformationen

SE 7-SW

SW-Integration SE 7.1-SW bis

SE 7.4-SW

SE 1

System-Anforderungs-

analyse SE 1.1 bis SE 1.8

SE 3

SW-/HW-Anforde-

rungsanalyse SE 3.1 bis SE 3.5

SE 4-SW

SW-Grobentwurf SE 4.1-SW bis SE 4.3-SW

SE 5-SW

SW-Feinentwurf SE 5.1-SW und SE 5.2-SW

SE 8

System-Integration SE 8.1 bis SE 8.3

System-

Ebene

SE 2

System-Entwurf SE 2.1 bis SE 2.6

HW-Einheit

Anwenderforderungen

SW-Architektur

Datenkatalog

Integrationsplan

Betriebsinformationen

Schnittstellenbeschreibung

SW-Einheits-/

HW-Einheits-

Ebene

Modul-/Datenbank-

Ebene

SW-Kompo-

nenten-

Ebene

Externe Vorgaben (AG)

Implementierungsdoku-

mente (SW-Komponente)

Datenbank

Rahmenbedingungen (für SE 1.7)

SWPÄ-Konzept



SW-Entwurf

SW-Modul

Implementierungsdokumente

(SW-Modul, Datenbank)

Implementierungsdokumente

(SW-Einheit)

SW-Komponente


System (installierbar)

Technische Anforderungen

Systemarchitektur

Technische Anforderungen

SE 6-SW

SW-Implementierung SE 6.1-SW bis SE 6.3-SW

System

(installiert und in Betrieb)

SE 9

Überleitung

in die Nutzung SE 9.1 bis 9.3


Legende:

Prüfaktivitäten

(siehe QS)

Schnittstellenübersicht

Schnittstellenbeschreibung

Kosten-/Nutzenanalyse

Angebotsbewertung

Schnittstellenübersicht

Nicht-IT-Anteile SW-Einheit

Protokoll

Abbildung 2.1: Systementwicklung im V-Modell ’97 [vmo, Dokumentation V-Modell,Kapitel 4: „Regelung Submodell Systemerstellung“]

Das V-Modell ist nach [LUDEWIG . LICHTER 2007, Seiten 197-180] durch die folgendenMerkmale charakterisiert:

• Das V-Modell ist ein aktivitätsorientiertes Modell, das Produkte, Aktivitäten undRollen miteinander verknüpft. Es ist in sogenannte Phasen, beziehungsweiseProjektabschnitte unterteilt, die durch Meilensteine oder auch Entscheidungs-punkte voneinander abgegrenzt werden. Die Meilensteine werden derart plat-

7

2 Grundlagen

ziert, dass eine deutliche Änderung eintritt, wenn ein Meilenstein erreicht undüberschritten wird. Wie genau die Meilensteine platziert werden müssen, ist zuBeginn des Projekts noch nicht bekannt und muss daher in der Projektplanunggeschätzt werden. Ein Meilenstein ist wie folgt definiert [WALLIN . 2002]:

„A milestone is defined as a scheduled event that marks the comple-tion of one or more important tasks and it is used to measure achie-vements and development progress. At a milestone, a predefined setof deliverables should have reached a predefined state to enable areview.“

• Das V-Modell ist für unterschiedliche Projektarten einsetzbar. Die ursprünglicheVersion beschäftigt sich nur mit der Erstellung von Software. In der Version von1997 wird zusätzlich die Hardware-Entwicklung unterstützt. Das V-Modell XT bie-tet sogar die Möglichkeit, Projekte durchzuführen, in denen andere Vorgehens-modelle mit Hilfe des V-Modells erstellt werden. Derartige Projekte heißen „Me-taprojekte“.

• Das V-Modell wird in erster Linie für die Erstellung des eigentlichen Produktsverwendet. Allerdings stehen auch Aspekte wie Qualitätssicherung, Konfigurati-onsverwaltung und Projektmanagement im Vordergrund und werden unterstützt.Hier unterscheidet sich das V-Modell von anderen Modellen, wie zum Beispieldem Wasserfallmodell, das diese zusätzlichen Aspekte nicht unterstützt.

• Das V-Modell lässt sich gut anpassen und erweitern. Dies wird noch einmal be-sonders durch die neue Version von 2005 unterstrichen (Stichwort: „extreme Tai-loring“).

Das V-Modell besitzt viele weitere Aspekte, die für diese Arbeit grundlegend sind. Al-lerdings muss im Folgenden zwischen V-Modell ’97 und V-Modell XT unterscheidenwerden. Da für diese Arbeit ausschließlich das V-Modell XT relevant ist, wird dieses inKapitel 2.2.1 weiter erklärt.

2.2.1 V-Modell XT

Das V-Modell XT ist eine Weiterentwicklung des V-Modells von 1997. „XT“ steht da-bei für „extreme Tailoring“. Ein Hauptgrund für die Entwicklung des V-Modells XT istdie mangelnde Flexibilität für Firmen. Nicht jede Firma möchte beziehungsweise kannden gesamten Prozess des V-Modells für jedes V-Modell-Projekt anwenden. Daherbietet das neue V-Modell XT die Möglichkeit, die Projektdurchführung flexibel an daseigene Unternehmen anzupassen. Dabei wird dennoch eine gewisse Qualität des Ent-wicklungsablaufes und auch des Produkts selbst bewahrt, da einige Schritte für jedesUnternehmen zwingend vorgeschrieben werden (Stichwort: V-Modell-Kern). Diese An-passung, auf englisch „Tailoring“, spiegelt sich im Namen des neuen V-Modells widerund kann somit als Hauptneuerung des V-Modells XT angesehen werden. In dieser Ar-beit wird im Folgenden der Begriff „V-Modell“ als Synonym für „V-Modell XT“ benutzt.

Es werden zwei zentrale Bezeichnungen eingeführt. Die sogenannten Vorgehensbau-

8

2 Grundlagen

steine sind das Konzept für die Prozesserarbeitung und -anpassung. Sie beinhaltenmiteinander verknüpfte Produkte und Aktivitäten und Rollen. Abbildung 2.2 zeigt dieallgemeine Struktur eines solchen Vorgehensbausteins. Vorgehensbausteine sind diezentrale Einheit des Tailorings und bietet alle Komponenten, die für die Bearbeitungeiner im V-Modell gestellten Aufgabenstellung notwendig sind. Jeder Vorgehensbau-stein kann einzeln verändert oder erweitert werden.

Abbildung 2.2: Vorgehensbaustein aus dem V-Modell [vmo, Dokumentation V-ModellXT, Seite 15]

Produkte sind die Ergebnisse oder Zwischenergebnisse, die erzeugt werden. Sie kön-nen in Disziplinen zusammengefasst werden, wobei die Produkte einer Disziplin in-haltlich eng zusammengehören müssen. Ein Produkt wiederum kann sich in Themenunterteilen lassen. Themen sind die wesentlichen Bestandteile eines Produkts undwerden in Arbeitsschritten bearbeitet. Produkte können voneinander abhängig sein.Die Abhängigkeit kann innerhalb eines Bausteins existieren, aber auch über Baustei-ne hinaus. Zudem lassen sich Produkte als initiales Produkt oder als externes Produktkennzeichnen. Ein initiales Produkt ist ein Produkt, das im gesamten Projekt immerund exakt einmal erstellt werden muss (z.B. die Bedienungsanleitung). Ein externesProdukt ist eine Eingabe an das V-Modell. Es wird also nicht während des V-Modell-Projekts erstellt, sondern kommt von anderer Stelle. Allerdings muss ein externes Pro-dukt die vom V-Modell angegebenen Bedingungen erfüllen. Produkte, die nicht initialsind, werden von anderen Produkten des V-Modells erstellt.

Im V-Modell XT werden sogenannte Produktabhängigkeiten vorgestellt, die eine Kon-sistenzbeziehung zwischen mehreren Produkten beschreibt. Das V-Modell definiertfünf unterschiedliche Produktabhängigkeiten.

Erzeugende Produktabhängigkeiten bestimmen Bedingungen oder Regeln an dieErstellung nicht initialer Produkte des V-Modells durch andere Produkte.

Inhaltliche Produktabhängigkeiten verknüpfen Produkte auf inhaltlicher Ebene. Än-dert sich ein Produkt, so können sich alle Produkte, die von diesem Produkt in-haltlich abhängen, ebenfalls ändern.

Relevante Produktabhängigkeiten kennzeichnen die Produktabhängigkeiten, wel-che sich nach Durchführung des Tailorings auf noch mindestens zwei Produktebeziehen.

9

2 Grundlagen

Strukturelle Produktabhängigkeiten beschreiben, welche Produkte in enger Bezie-hung zueinander stehen. So kann beispielsweise beschrieben werden, dass eineSW-Einheit aus mehreren SW-Komponenten bestehen, die wiederum aus meh-reren SW-Modulen zusammengesetzt sein können.

Tailoring Produktabhängigkeiten verdeutlichen die Beziehungen von Produkten zuVorgehensbausteinen und sind somit für das Tailoring relevant.

Produkte werden von Aktivitäten fertiggestellt. Dabei besitzt jedes Produkt genau ei-ne Aktivität, in der es fertiggestellt wird. Aktivitäten, die inhaltlich zusammengehören,werden – genau wie Produkte – in einer Disziplin zusammengefasst. Dabei werdendie zusammengehörigen Produkte und Aktivitäten in derselben Disziplin vereint. EineAktivität besteht aus Arbeitsschritten. Sie stellt genau ein Produkt fertig, während dieArbeitsschritte die Themen des Produkts bearbeiten. Arbeitsschritte beziehen sich al-so immer auf Themen, genauso wie sich Aktivitäten jeder Zeit auf Produkte beziehen.Dabei sind Arbeitsschritte mit einer Arbeitsanleitung vergleichbar. Eine Arbeitsanlei-tung kann sowohl ein einziges als auch mehrere Themen bearbeiten.

Zuletzt muss noch angegeben werden, wer die Aktivitäten durchführt und somit Pro-dukte fertigstellt. Dazu bietet das V-Modell die Rollen. Eine Rolle kann an einem Pro-dukt mitwirken oder auch verantwortlich für ein solches sein. Außerdem gibt eine Rolledie Fähigkeiten an, die für die Aufgaben benötigt werden. Jedem Produkt muss genaueine verantwortliche Rolle zugeteilt sein. Es können aber mehrere Rollen an einemProdukt mitwirken. Erst zu Beginn eines Projekts werden den Rollen konkrete Mitar-beiter zugeteilt. Vorher wird immer von der Rolle selbst gesprochen.

Ein V-Modell-Projekt wird in Projektabschnitte unterteilt, was mit Hilfe von Entschei-dungspunkten geschieht. Entscheidungspunkte sind das im V-Modell verwendeteKonzept zur Projektdurchführung beziehungsweise Projektfortschrittskontrolle. In ei-nem Entscheidungspunkt wird entschieden, ob das Projekt fortgesetzt und der nächs-te Projektabschnitt begonnen werden kann. Die Kriterien, die für die Entscheidungnotwendig sind, werden vom V-Modell XT durch die Produkte, die beim Erreichen desEntscheidungspunkts fertiggestellt sein müssen, definiert. Jeder Entscheidungspunktfordert Produkte, die zum Überschreiten des Entscheidungspunkts erforderlich sind.

Ein Entscheidungspunkt muss immer derart platziert werden, so dass beim Erreichenund Überschreiten des Entscheidungspunkts eine deutliche Änderung eintritt.

Die Reihenfolge der im Projekt zu durchlaufenden Entscheidungspunkte wird von derProjektdurchführungsstrategie festgelegt. Diese wird vom zuvor gewählten Projekt-typ und dem Anwendungsprofil bestimmt. Abbildung 2.3 zeigt alle im V-Modell XT vor-gesehenen Entscheidungspunkte.

Das Tailoring beginnt beim V-Modell XT bereits mit der Wahl des Projekttyps, welcherwiederum eine Auswahl von Projekttypvarianten nach sich zieht. Es gibt die folgendenProjekttypen (PT) und Projekttypvarianten (PTV):

PT: Systementwicklungsprojekt (AG) Entwicklungsprojekt aus Sicht des Auftragge-bers. Der Auftraggeber erstellt eine Ausschreibung und wählt einen Auftragneh-mer. Ist System fertiggestellt worden, nimmt der AG das System ab. Es gibt fol-

10

2 Grundlagen

Abbildung 2.3: Übersicht über alle im V-Modell XT vorgesehenen Entscheidungspunk-te [vmo]

gende Projekttypvarianten:

• PTV: AG-Projekt mit einem Auftragnehmer

• PTV: AG-Projekt mit mehreren Auftragnehmern

PT: Systementwicklungsprojekt (AN) Entwicklungsprojekt aus Sicht eines Auftrag-nehmers. Die Ausschreibung wurde bereits erstellt und der Auftrag erteilt. DerAuftragnehmer entwickelt das System und übergibt es nach Fertigstellung demAuftraggeber. Es gibt folgende Projekttypvarianten:

• PTV: AN-Projekt mit Entwicklung, Weiterentwicklung oder Migration

• PTV: AN-Projekt mit Wartung und Pflege

PT: Systementwicklungsprojekt (AG/AN) Keine separaten Projekte auf Auftragge-ber und Auftragnehmer Seite notwendig. Die Anforderungen werden vom Auf-traggeber ermittelt und anschließend durch den Auftragnehmer umgesetzt. Dasfertige Produkt wird anschließend vom Auftraggeber abgenommen. Es gibt fol-gende Projekttypvarianten:

• PTV: AG/AN-Projekt mit Entwicklung, Weiterentwicklung oder Migration

• PTV: AG/AN-Projekt mit Wartung und Pflege

PT: Einführung und Pflege eines organisatorischen Vorgehensmodells Dient zurErstellung eines Vorgehensmodells. Es gibt die folgende Projekttypvariante:

• PTV: Einführung und Pflege eines organisatorischen Vorgehensmodells

Auf Basis dieser Auswahl erstellt das V-Modell XT ein Anwendungsprofil, indem wei-tere Projektmerkmale, welche das Projekt näher charakterisieren, bewertet werdenkönnen. Eine Übersicht über alle Projektmerkmale gibt es in Kapitel ??. Durch daskomplette Anwendungsprofil werden die möglichen, verwendbaren Vorgehensbaustei-ne, sowie die Projektdurchführungsstrategie und somit die Reihenfolge der Entschei-dungspunkte definiert. Dieses Vorgehen wird als statisches Tailoring bezeichnet.

11

2 Grundlagen

Wenn nun während der Projektlaufzeit Vorgehensbausteine hinzugefügt oder entferntwerden sollen, wird von dynamischem Tailoring gesprochen. Für eine dynamische Än-derung definiert das V-Modell XT ebenfalls genaue Regeln und bietet Produktabhän-gigkeiten an, die vorgeben, welche Kombination von Vorgehensbausteinen eingesetztwerden müssen, sofern ein bestimmter Vorgehensbaustein eingesetzt wird.

In Abbildung 2.4 wird analog zur V-Modell ’97 Variante (Abbildung 2.1) der Ablauf derSystementwicklung im V-Modell XT dargestellt.

Abbildung 2.4: Systementwicklung im V-Modell XT [vmo, Dokumentation V-Modell XT,Seite 35]

2.3 SCRUM

SCRUM ist nach [LÜBKE, SCHNEIDER 2011] eine Management-Hülle und wurde 1996von Ken Schwaber [BEEDLE . SCHWABER 2002] vorgestellt. Die Grundidee ist, Anfor-derungen zu bündeln und schrittweise abzuarbeiten. Änderungen werden nur zwi-schen den Abarbeitungsphasen zugelassen. Dies gewährleistet unter anderem dersogenannte SCRUM Master. Das Entwicklerteam selbst besteht aus fünf bis neunEntwicklern.

Der Name SCRUM (aus dem Sport: Zusammenraufen im Team) spiegelt die Idee derMethode wider. Ein Projekt ist aufgeteilt in mehrere Abschnitte. Das Entwicklerteamtrifft sich zu Beginn eines solchen Abschnitts und berät über das weitere Vorgehenfür die nächste Abarbeitungsphase, den sogenannten Sprint. In jedem Sprint wird ver-sucht, eine neue Teilfunktionalität des Produkts fertigzustellen. Jeden Tag findet ein15-minütiges Meeting statt, der „Daily SCRUM“, in dem das Vorgehen bis zum nächs-ten Meeting besprochen wird und berichtet werden soll, was seit dem letzten Meetingerreicht wurde.

12

2 Grundlagen

Dieses Vorgehen stellt zum einen hohe Anforderungen an die Entwickler und das Ma-nagement in Bezug auf Selbstdisziplin, Eigenverantwortung und Vertrauen. Zudemmüssen die Praktiken von SCRUM klar definiert und durchdacht sein. Es muss sichergestellt sein, dass diese Praktiken reibungslos funktionieren und von Anfang bis Endedurchgesetzt werden, damit SCRUM funktioniert.

Abbildung 2.5 bietet einen groben Überblick über die wichtigsten Praktiken von SCRUM.Im Folgenden werden die Praktiken von SCRUM vorgestellt.

Abbildung 2.5: Übersicht über SCRUM [SCHNEIDER 2011]

Der sogenannte SCRUM Master ist eine Managementrolle, die dafür sorgt, dass diePraktiken von SCRUM jederzeit eingehalten werden und das Team unter allen Umstän-den unbeschwert arbeiten kann. Er ist verantwortlich für die Sprints und die Meetingsund achtet darauf, dass diese reibungslos durchgeführt werden können. Er ist ver-antwortlich für das Voranschreiten des Projekts und muss den erwarteten Fortschrittmit dem aktuellen Fortschritt vergleichen. Hat das Team Schwierigkeiten bei der Ent-wicklung, muss sich der SCRUM Master diese Probleme anhören und versuchen, siezusammen mit dem Team zu lösen. Der SCRUM Master muss jederzeit in der Lagesein, Entscheidungen schnell zu treffen. Dabei können die Entscheidungen durchausfalsch sein, wobei sie schnellstmöglich rückgängig gemacht werden müssen. Dadurchsorgt er dafür, dass das Team jederzeit mit höchster Produktivität arbeitet.

13

2 Grundlagen

Im Product Backlog werden die Anforderungen festgehalten, die an das System oderProdukt gestellt werden. Diese Anforderungen können technische Aufgaben sein, wiebeispielsweise „Klasse A muss refactored werden“ oder benutzerzentrierterer Natur,wie zum Beispiel „Text muss markiert und kopiert werden können“. Außerdem könnensogenannte User Stories enthalten sein. User Stories sind natürlichsprachige Anfor-derungen aus Sicht eines Nutzers. Sie sind kurz gehalten und umfassen nur wenigeSätze. Das Product Backlog wird durch eine Zusammenarbeit zwischen SCRUM Mas-ter und Product Owner (dazu unten mehr) gefüllt. Außerdem kann jeder, der Ideenoder Anregungen hat, die das Produkt betreffen, diese im Product Backlog festhalten.Das Product Backlog ist zu Beginn unvollständig und wird im Verlauf der Entwicklungvervollständigt. Um einen ersten Sprint zu starten, muss das Product Backlog ledig-lich genug Informationen besitzen, um diesen Sprint 30 Tage lang durchzuführen. Esentwickelt sich zusammen mit dem Verständnis des Kunden und der Entwickler weiter.Alle Einträge des Product Backlogs sind priorisiert. Die Inhalte mit der höchsten Prio-rität werden für einen Sprint übernommen. Der Aufwand für die Erstellung der Inhaltedes Product Backlogs werden vom Product Owner geschätzt, indem dieser Entwicklerund Verantwortliche befragt, die mit dem Produkt zu tun haben.

Der Product Owner kontrolliert und managt das Product Backlog. Er wird durch denSCRUM Master in Zusammenarbeit mit dem Kunden bestimmt und muss dafür sor-gen, dass das Product Backlog zu jeder Zeit für jeden zugänglich und einsehbar istund dass jeder über den aktuellen Stand des Product Backlogs informiert ist. Damitder Product Owner erfolgreich seine Arbeit ausführen kann, muss jeder seine Ent-scheidungen respektieren.

Das SCRUM Team ist verantwortlich dafür, die durch das Product Backlog geforderteFunktionalität für einen Sprint in einem Sprint herzustellen. Es wird vom SCRUM Mas-ter in Zusammenarbeit mit dem Management zusammengestellt und besitzt währendeines Sprints völlige Autorität um alles zu tun, damit das geforderte Ziel des Sprintserreicht werden kann. Die einzigen Einschränkungen und Bedingungen werden durchdie Standards der Organisation vorgeschrieben. Die Größe des SCRUM Teams solltezwischen 5 und 9 Personen betragen. Kleinere Teams können auch ihr Ziel erreichen,allerdings fällt die Produktivität in kleinen Teams geringer aus. Größere Teams besit-zen das Problem, dass die Kontrollmechanismen von SCRUM nicht mehr ausreichendgut greifen und die Produktivität ebenfalls sinkt. Sind mehr als 9 Personen verfügbar,können die Personen in mehrere Teams aufgeteilt werden, die alle für sich arbeiten.Bei mehreren Teams können sich die SCRUM Master treffen, um ein sogenanntesSCRUM of SCRUMs durchzuführen.

Jedes Team trifft sich täglich zu einem 15-minütigen Daily SCRUM Meeting. Wäh-rend des Meetings hat jeder Teilnehmer zwei bis drei Minuten Zeit zu erklären, waser seit dem letzten Treffen geschafft hat, was er bis zum nächsten Treffen schaffenmöchte und welche Schwierigkeiten aufgetreten sin. Die Daily SCRUM Meetings sindfür alle anderen Personen, die ein Interesse am Fortschritt haben, offen zugänglich.Allerdings darf niemand das Meeting durch Zwischenfragen unterbrechen oder stö-ren. Der SCRUM Master ist verantwortlich für die Organisation der Räumlichkeitenund das Planen und Durchführen des SCRUM Meetings. Wichtig ist, dass während

14

2 Grundlagen

des Daily SCRUM Meetings keine Designentscheidungen getroffen und keine Fragengeklärt werden sollen. Es sollen lediglich alle Teammitglieder auf den aktuellen Standder Dinge gebracht werden. Allerdings kann jedes Mitglied seinen Wunsch äußern, zueinem Thema mehr hören zu wollen. In diesem Fall wird ein anschließendes Meetingdurchgeführt, in dem diesem Wunsch Folge geleistet wird.

Während eines Sprint Planning Meetings planen Entwickler, Kunden, Managementund Product Owner die nächsten Schritte. Das Team legt fest, wie das Ziel des Sprintsaussehen soll und welche Funktionalitäten umgesetzt werden sollen. Das Sprint Plan-ning Meeting besteht aus zwei separaten Meetings. Zuerst versucht das Team zu-sammen mit allen Beteiligten herauszufinden, welche Funktionalität umgesetzt werdensoll. Danach beratschlagt das Team in einem zweiten Meeting, wie diese Funktionali-tät konkret umgesetzt werden kann. Ist bekannt, welche Funktionalität erstellt werdensoll, werden die Aufgaben festgelegt, um diese Funktionalität bereit zu stellen. DieseAufgaben werden in das sogenannte Sprint Backlog geschrieben. Nur das Team kanndas Sprint Backlog während eines Sprints verändern.

Während des anschließenden Sprints versucht das Team, die geforderte Funktionali-tät, so gut es geht, umzusetzen. Dabei stellt SCRUM keine Bedingungen, wie genaudies geschehen soll. Das Team muss selbst entscheiden, was auf welche Art undWeise zu tun ist. Zu jeder Zeit steht das Team somit in der Eigenverantwortung, so gutwie möglich zu arbeiten. Ein Sprint sollte in der Regel 30 Tage dauern. Dies ist eineangemessene Zeit, um dem Team die Möglichkeit zu geben, sich in die Problematikund Aufgabenstellung einzuarbeiten und ein gutes Ergebnis abzuliefern. Zugleich istim Falle des Scheiterns des Teams die Dauer des Sprints derart kurz gewählt, so dasskein erheblicher Schaden entsteht, zumal die Zeit nicht komplett verschwendet wurde,da das Team Wissen und Erfahrung gewonnen hat. Während des gesamten Sprintsdarf das Team nicht von außen beeinflusst oder unterbrochen werden. Zudem dürfenkeine zusätzlichen Aufgaben nachträglich hinzugefügt werden. Das Team selbst darfdie Funktionalität des Sprints ändern, solange dadurch das Ziel des Sprints unverän-dert bleibt. Unter besonderen Umständen darf ein Sprint abgebrochen werden.

Das vierstündige Sprint Review Meeting ist ein informelles Meeting, in dem das Teamdem Kunden, dem Management, den Benutzern und dem Product Owner erklärt, waswährend des Sprints bewerkstelligt wurde. Basierend auf diesen Ergebnissen könnenbearbeitete und unbearbeitete Aufgaben neu bewertet werden und somit bestimmtwerden, welche Richtung für die noch anstehende Entwicklungszeit eingeschlagenwird. Dieses Meeting ist ebenfalls für alle Interessierten offen zugänglich. Dadurch,dass das Team allen Beteiligten das Inkrement vorstellt und erklärt, können Schwach-stellen erläutert oder aufgedeckt werden. Die Anwesenden bekommen dadurch einbesseres Verständnis von dem Produkt und dem Projekt selbst.

2.4 FLOW

In diesem Kapitel werden die für diese Arbeit relevanten Konzepte von FLOW, ba-sierend auf [STAPEL . SCHNEIDER 2012], detailliert dargestellt. Zum einen wird durch

15

2 Grundlagen

FLOW eine Notation vorgestellt, mit deren Hilfe Informationsflüsse grafisch dargestelltwerden können. Diese Notation kommt in dieser Arbeit zum Einsatz, da die Integrationvon SCRUM in das V-Modell XT auf Basis von Informationsflüssen geschehen soll unddiese Informationsflüsse ermittelt und auch grafisch dargestellt werden müssen.

Zum anderen bietet FLOW eine Methode, bestehende Informationsflüsse zu verbes-sern, um somit die Softwareentwicklung effizienter zu gestalten. Die nachfolgende Ar-beit ist eine Technik innerhalb dieser FLOW-Methode und soll daher in Kapitel 2.4.3kurz in diese eingeordnet werden.

Der Erfolg eines Softwareprojekts hängt in hohem Maße von den Informationsflüssenin diesem Projekt ab. Sei es durch die Anforderungen, die in das Projekt einfließenoder den Informationen, die von Projektabschnitt zu Projektabschnitt fließen, um Fort-schritte zu erzielen. Um diese Flüsse verstehen zu können, müssen sie zuerst visuali-siert werden.

Informationen können entweder in fester oder in flüssiger Form vorliegen. Informatio-nen, die in fester Form vorliegen, sind Informationen, die langfristig und wiederholt ab-rufbar und für Dritte verständlich sind. Alle anderen Informationen, die nicht auf dieseBeschreibung zutreffen, sind flüssig. Feste Informationen sind beispielsweise in Doku-menten enthalten, während Informationen, die im Gedächtnis einer Person vorliegen,flüssig sind.

2.4.1 FLOW-Notation

Die FLOW-Notation ist eine Möglichkeit, Informationsflüsse visuell darzustellen. Siewurde speziell für Informationsflüsse konstruiert, um alle Besonderheiten dieser Flüs-se abbilden zu können.

Die FLOW-Notation soll dabei einige Anforderungen erfüllen. Einige dieser Anforde-rungen werden im Folgenden genannt. Die FLOW-Notation soll:

• Leicht verständlich sein

• Unterscheiden zwischen festen und flüssigen Informationsflüssen

• Nahe an bekannte Notation angelehnt sein

• Komplexität mit hierarchischen Modellen begegnen

In Abbildung 2.6 werden die Symbole der FLOW-Notation dargestellt. Das Dokumen-tensymbol steht für die festen Informationsspeicher, während dessen das Smileysym-bol für die flüssigen Informationsspeicher verwendet wird. Die festen Informations-flüsse werden durch einen durchgehenden Pfeil und die flüssigen Informationsflüssendurch einen gestrichelten Pfeil gekennzeichnet. Die Informationsflussaktivität kann so-wohl normale, als auch Kontrollinformationsflüsse als Ein- oder Ausgang besitzen.

In dieser Arbeit werden auf Grund von technischen Grenzen und Übersichtlichkeit derAbbildungen einige Einschränkungen dieser Notation gemacht. Die Bezeichnungender Dokumente werden in der Regel in das Dokument selbst geschrieben. In einigen

16

2 Grundlagen

Abbildung 2.6: Symbole der FLOW-Notation [STAPEL . SCHNEIDER 2012]

Abbildungen werden die flüssigen Informationsspeicher nicht mit einem Smiley ge-kennzeichnet, da die Tools, die diese Abbildungen erstellt haben, diese Möglichkeitnicht unterstützten. Stattdessen werden die flüssigen Speicher als Ovale eingezeich-net, die ebenfalls den Namen im Oval beinhalten. Des weiteren werden Kontrollin-formationsflüsse in dieser Arbeit nicht betrachtet. Aus Gründen der Übersichtlichkeitwerden Informationsflüsse, die von oben oder unten in oder aus Aktivitäten fließen,immer als normale Informationsflüsse dargestellt.

2.4.2 FLOW-Methode

Informationen sind die wichtigste Ressource in der Softwareentwicklung. Mit FLOWwird eine Methode angeboten, die zur Analyse und Verbesserung dieser Informations-flüsse genutzt werden kann.

Die Flow-Methode besteht, wie Abbildung 2.7 zeigt, aus einer Vorbereitungsphase undeinem Verbesserungszyklus, der aus Erhebung, Analyse und Verbesserung besteht.

Abbildung 2.7: Der iterative FLOW-Verbesserungsprozess[STAPEL . SCHNEIDER 2012]

In der Vorbereitungsphase wird das Ziel des Verbesserungsschritts und die gewünsch-

17

2 Grundlagen

ten Techniken, um dieses Ziel zu erreichen, bestimmt. Jede Phase des anschließen-den Verbesserungszykluses erzeugt eine Ausgabe, die von der jeweils nächsten Pha-se benötigt und verwendet wird. Alle drei Phasen beziehen sich auf Informationsflüssein einem Softwareprojekt, welche erhoben, analysiert und verbessert werden sollen.Das Erheben der Informationsflüsse schafft eine Basis für spätere Phasen. Das Ana-lysieren der Informationsflüsse trägt zum Verständnis dieser Flüsse bei, indem sievisualisiert werden. Verbessert werden die Informationsflüsse durch das Ausräumenerkannter Informationsflussprobleme.

2.4.3 Einordnung der Arbeit mit Hilfe der FLOW-Methode

In diesem Kapitel wird die vorliegende Arbeit, die als Technik innerhalb der FLOW-Methode angesehen werden kann, in FLOW eingeordnet. Tabelle 2.1 zeigt diese Ein-ordnung. Es wird beschrieben, welche Aufgaben mit welchem Ziel zu welchem Zeit-punkt durchgeführt werden und welche Eigenschaften die Informationsflüsse der Soft-wareprojekte besitzen.

Name der Technik Integration von SCRUM in das V-Modell XT

Ziel1 Absicht

Zeit

Umfang

2 Verstehen2� Verbessern

2� vorher 2� während dessen 2 nachher

2 Aktivität 2� Projekt 2 Organisation

Phase2 2� Erheben 2� Analysieren 2� Verbessern

Projektparameter

Projektgröße 2 Teamgröße:2 Budget:2 Benötigte Ressourcen:

Domäne 2 Anwendungsdomäne:2 Softwaredomäne:

Vorgehensmodell 2� Prozess:2� Agil:2 Andere:

Verteiltheit 2� Lokal 2 Verteilt (Art: )

Sonstiges1 FLOW-Ziel-Aspekte, die mit dieser FLOW-Technik verfolgt werden können2 Diese Technik bietet Unterstützung in diesen Phasen des FLOW-Verbesserungsprozesses

Tabelle 2.1: Klassifikation dieser Arbeit als FLOW-Technik

Das Ziel dieser Arbeit besteht in der Verbesserung der durch das V-Modell und SCRUMgegebenen Informationsflüsse. Sowohl das V-Modell, als auch SCRUM, werden in Pro-jekten eingesetzt. Also werden Informationsflüsse in diesen Projekten verbessert. Dieskann vor und während eines solchen Projekts geschehen.

18

2 Grundlagen

Dabei werden alle drei Phasen durchlaufen. Kapitel 3 beschreibt das Erheben der In-formationsflüsse. Mit Hilfe des Prototypen (siehe Kapitel 6.1) werden die Informations-flüsse des V-Modells visualisiert. In Kapitel 3 werden die Informationsflüsse in SCRUMhinein und aus SCRUM heraus beschrieben. In Kapitel 4 werden Formen des Informa-tionsflusses im V-Modell dargestellt. Einige konkrete Beispiele für Informationsflüsseim V-Model und an den Schnittstellen von SCRUM werden in Kapitel 5 gegeben. InKapitel 4 werden Anpassungen von SCRUM durchgeführt, um Informationsflüsse zuverbessern und somit die Integration von SCRUM in das V-Modell XT zu ermöglichen.

Da sowohl Informationsflüsse im V-Modell, als auch in SCRUM betrachtet werden, sindsomit sowohl agile, als auch dokumentenlastige Prozesse betroffen. Allerdings wirddurch SCRUM vorausgesetzt, dass die Projekte lokal und nicht verteilt durchgeführtwerden, da verteilte Projekte mit SCRUM nur sehr schwer durchzuführen sind. DiesesProblem ist nicht Bestandteil dieser Arbeit.

2.4.4 Informationen und Informationsflüsse

Da Information und Informationsflüsse in dieser Arbeit eine zentrale Rolle spielen, sollhier kurz mit Hilfe der Informationsflusstheorie [STAPEL 2012] erläutert werden, wasgenau im Rahmen dieser Arbeit mit Information gemeint ist und was ein Informations-fluss ist.

Nach [STAPEL 2012] können viele relevante Softwareentwicklungsphänomene mit In-formationsflüssen beschrieben werden. Informationen liegen entweder in Form vonWissen im Gedächtnis von Personen oder in Form von Daten, beispielsweise in Doku-menten, vor. Ein Softwareprojekt schreitet durch Weitergabe von Wissen, also durchKommunikation, sowie durch Konkretisierung von Daten voran. Diese Kommunikationund Konkretisierung sind Informationsflüsse. Daher können die wesentlichen Vorgän-ge der Softwareentwicklung mit Hilfe von Informationsflüssen dargestellt werden.

Die Informationsflusstheorie der Softwareentwicklung definiert Kommunikation als Wis-sensaustausch zwischen Menschen. Dieser Wissensaustausch kann direkt oder überDokumente erfolgen. Eine Kommunikation kann als Untermenge von Informationsflüs-sen aufgefasst werden. Mit Hilfe der Informationen können nun zentrale Aspekte derSoftwareentwicklung, wie zum Beispiel Kommunikation und Dokumentation, einheit-lich beschreiben werden. In Abbildung 2.8 wird eine solche Information beschrieben.Dabei besteht eine Information aus einer Nachricht und einem Kontext. Ein Kontextist wiederum eine Information, die aber nicht gespeichert wird, sondern als Vorwissenzum Verstehen der Information vorausgesetzt wird.

Jede Information muss auf eine bestimmte Art und Weise codiert werden. Die Codie-rung kann entweder durch Wissen oder durch Daten geschehen. Beide sind jederzeitin einem Informationsspeicher abgelegt. Wissen wird in einem Gedächtnis gespei-chert, Daten hingegen in einem Dokument. Informationen lassen sich typisieren. JedeInformation besitzt einen der folgenden Typen:

Fact Atomare Aussage über einen konkreten Sachverhalt. Beispiel: Die Farbe der

19

2 Grundlagen

Abbildung 2.8: Beschreibung einer Information [STAPEL 2012]

Tapete ist weiß.

Concept Aussage über einen abstrakten Sachverhalt. Fakten und Konzepte habeneine ähnliche Beziehung wie Klassen und Objekte aus Programmiersprachen.Beispiel: Ein Hund ist ein Säugetier. Hierbei wäre das Säugetier das Konzept.

Rule Aussage, die an eine Bedingung geknüpft ist. Beispiel: Wenn wir für unser Pro-dukt einen Treiber schreiben müssen, werden wir dies in C++ tun.

Procedure Beschreibung von Arbeitsschritten mit Reihenfolge. Beispiel: Zuerst wirdein Grobentwurf erstellt, dann ein Feinentwurf.

Zusätzlich lassen sich Informationen in Domänen einordnen. Es gibt eine Domänefür das generelle Lösen von Problemen und als Teil dieser eine Software-Domäne.Diese lässt sich in die Bereiche Anforderung, Architektur, Code und Test unterteilen.Das zu lösende Problem befindet sich in der Problemdomäne, die beispielsweise ausden Domänen Automotive, Financial oder Medical kommen kann. Es gibt also eineDomäne, in der die Lösung eines Problems mit Softwaremethoden angestrebt wirdund eine Domäne, in der das Problem liegt.

20

2 Grundlagen

Eine Information besteht aus einer Nachricht und einem Kontext. Die Nachricht ist dieAussage, die getroffen wird. Der Kontext ist der Hintergrund, der benötigt wird, um dieNachricht verstehen zu können. In der Regel ist der Kontext nicht leer, da eine Kom-munikation viel zu ineffizient wäre, wenn immer versucht wird, viel in der Nachrichtauszudrücken und wenig im Kontext vorauszusetzen. Ein Beispiel für eine Nachrichtwäre: „Das Wetter bei uns war gestern sonnig“. Eine Möglichkeit für einen passendenKontext wäre: „Die Person hat sich gestern in Hannover aufgehalten.“ Zusammen er-gibt es die Information, dass das Wetter in Hannover gestern sehr schön war. Ist derKontext anders, beispielsweise: „Die Person hat sich gestern in Paris aufgehalten“,wäre die Information eine andere. Die Größe der Nachricht kann je nach vorausge-setztem Vorwissen variieren. Abhängig vom Kontext kann eine kleine Nachricht diegleiche Information bieten, wie eine große Nachricht.

Dies bedeutet, dass bei einer Kommunikation der nicht übermittelte Kontext entschei-dend für das richtige Verständnis und den Erfolg der Kommunikation ist. Große Nach-richten und eine daraus resultierende, größere Wahrscheinlichkeit, dass die Informa-tion richtig verstanden wird, stehen einer kleinen Nachricht gegenüber, die wiederumdie Effizienz der Kommunikation steigert. Effizienz ist hierbei die benötigte Zeit, in dereine Information vermittelt werden kann. In Abbildung 2.9 wird dies genauer dargestelltund der Kommunikationsprozess erläutert. Wissen kann nur dann richtig übertragenwerden, wenn es einen gemeinsamen Kontext gibt. Will ein Sender Wissen vermitteln,trennt er zuerst Nachricht und Kontext voneinander. Dies geschieht bewusst oder auchunbewusst. Die Nachricht wird in geeigneter Form übermittelt und vom Empfängerwahrgenommen. Dieser muss die Nachricht in einen gemeinsamen Kontext bringenund kann die Information nur so korrekt erhalten. Die Information wird anschließendinterpretiert und wieder in Wissen umgewandelt. Unterscheidet sich der gemeinsameKontext von Sender und Empfänger, schlägt die Kommunikation fehl.

Abbildung 2.9: Kommunikationsablauf zwischen Sender und Empfänger[STAPEL 2012]

Wenn Informationen von einer Quelle zu einem Ziel fließen, wird von Informations-fluss gesprochen. Sowohl Quelle, als auch Ziel eines Flusses sind Informationsspei-

21

2 Grundlagen

cher. Wird die Tatsache berücksichtigt, dass es zwei unterschiedliche Informationsspei-cher gibt, die auf zwei mögliche Arten angeordnet werden können, ergeben sich vierKombinationsmöglichkeiten für die Art der Übertragung. Diese Kombinationsmöglich-keiten werden Basisinformationsflüsse genannt, die wie folgt bezeichnet werden:

Externalisation/Documentation Es werden Informationen von einem Gedächtnis inein Dokument übertragen (dokumentiert).

Combination/Transformation Es werden Informationen von einem Dokument in einanderes übertragen oder in das gleiche kopiert.

Internalisation/Learning Es werden Informationen von einem Dokument in ein Ge-dächtnis übertragen (erlernt).

Socialisation/Communication Es werden Informationen von einem Gedächtnis inein anderes übertragen (kommuniziert).

Zuletzt wird die Softwareentwicklung in Abbildung 2.10 aus Informationsflusssicht dar-gestellt. Auf der einen Achse wird die Domäne dargestellt, auf der anderen die Ab-straktheit. Es gibt die beiden Domänen „Problem“ und „Problemlösung“. Die Problem-definition wird in der Problemdomäne vorgenommen. Durch einen Lösungsvorschlagwird in die Problemlösungsdomäne gewechselt. Dort wird mit Hilfe von Softwareent-wicklungsaktivitäten Software zum Lösen des Problems erstellt. Das Testen der Soft-ware, also die Prüfung der Lösung, führt wieder in die Problemdomäne zurück.

Abbildung 2.10: Softwareentwicklung aus Informationsflusssicht [STAPEL 2012]

22

3 Informationsflüsse in SCRUM und im V-ModellXT

3.1 Grundidee

Das Ziel dieser Arbeit ist, Informationsflüsse im V-Modell und in SCRUM zu identifi-zieren, um mit deren Hilfe eine Integration von SCRUM in das V-Modell XT leichterdurchführen zu können.

Die Informationsflüsse in SCRUM lassen sich, wie in Kapitel 3.3 beschrieben wird,ableiten, indem die Praktiken und Methoden von SCRUM und die damit verbundenenArbeitsabläufe analysiert werden. Somit kann ein Informationsfluss in SCRUM ermitteltwerden.

Der Informationsfluss im V-Modell kann auf den ersten Blick über mehrere Möglichkei-ten gewonnen werden. In Kapitel 3.4 werden die Produktabhängigkeiten des V-Modellsanalysiert, um Informationsflüsse aus ihnen abzuleiten.

Sind die Informationsflüsse sowohl im V-Modell, als auch in SCRUM bekannt, kannSCRUM auf Basis dieser Informationsflüsse in das V-Modell integriert werden. Wiegenau die Integration aussieht und welche Anpassungen vorgenommen werden müs-sen, wird in den nachfolgenden Kapiteln 4 und 5 ausführlich beschrieben.

Es gibt allerdings prinzipielle Ideen, die auf die Analyse des Informationsflusses Aus-wirkungen haben und somit bereits in diesem Kapitel berücksichtigt werden müssen.Da sich SCRUM an jeder sinnvollen Stelle des V-Modells integrieren lassen sollte,müssen die Informationsflüsse im gesamten V-Modell betrachtet werden. Dies ist zumeinen wichtig, da somit analysiert werden kann, welche Stelle sinnvoll ist. Auf der an-deren Seite muss aber auch an jeder dieser Stellen die Analyse des Informations-flusses vorliegen, um SCRUM tatsächlich an dieser Stelle integrieren zu können, dadie Integration, wie schon beschrieben, auf Basis dieser Informationsflüsse stattfindensoll. Da nun SCRUM integriert werden soll, reicht es aus, den Informationsfluss vonSCRUM an dessen Schnittstellen nach außen zu betrachten. Ist der Informationsflussan diesen Schnittstellen analysiert, kann die Integration durchgeführt werden.

Als Schnittstellen von SCRUM sollen in diesem Kapitel alle ein- und ausgehendenInformationsflüsse, die in SCRUM hinein und aus SCRUM heraus gehen, gelten. Derinnere oder interne Ablauf von SCRUM bezeichnet die Arbeitsabläufe und -schritte,die mit SCRUM durchgeführt werden, um ein gefordertes Ziel zu erreichen. Ein Sprintwäre beispielsweise Bestandteil des inneren Ablaufs. Ebenso ist das SCRUM Teamausschließlich in den inneren Ablauf integriert und hat auf die Außenwelt aus Informa-tionsflusssicht keine Auswirkungen. Der innere Ablauf von SCRUM kann also als eine

23

3 Informationsflüsse in SCRUM und im V-Modell XT

Black Box angesehen werden. Es werden Eingaben benötigt, damit SCRUM ablaufenkann. Nach einer gewissen Zeitspanne produziert SCRUM auf zunächst unbekannteArt und Weise Ausgaben, die wiederum vom V-Modell weiterverwendet werden kön-nen und sollen.

Der innere Ablauf von SCRUM ist natürlich genauso wichtig, wie die Schnittstellen vonSCRUM nach außen. Daher wird dieser ausführlich in Kapitel 4 erläutert.

3.2 Annahmen

Um nun die oben genannten Ideen einheitlich umzusetzen, muss eine Basis von In-formationen und Tatsachen definiert werden, damit jeder einzelne Schritt plausibelerklärt werden kann. Die Basis oder auch der Rahmen diese Arbeit, wird zum Teil vomV-Modell selbst, als auch von den Gegebenheiten von SCRUM definiert. Da allerdingsnicht jede Einzelheit im V-Modell oder in SCRUM erklärt wird und oft Spielraum fürInterpretationen offen bleibt, werden an dieser Stelle einige Annahmen getroffen, dienotwendig sind, um eben diese gemeinsame Basis zu schaffen, damit die Integrationvon SCRUM später erfolgreich durchgeführt werden kann.

Die hier gemachten Annahmen sollen durchaus realistisch gehalten werden. Sie sindso formuliert, dass eine Anwendung in der Praxis Sinn ergibt. Da sie aber nirgendsexplizit erwähnt sind, müssen sie an dieser Stelle festgehalten werden.

Annahme 3.1

Die Ersetzung durch SCRUM wird immer so gewählt, dass mindestens ein Sprintdurchgeführt werden kann.

Diese Annahme ist wichtig, da es in der Regel nicht gut ist, einen Sprint abzubrechen.Die Ersetzung durch SCRUM sollte niemals derart gewählt werden, dass schon imVorfeld eine Durchführung eines ganzen Sprints unmöglich wird.

Annahme 3.2

Das SCRUM Team besteht aus Entwicklern des V-Modell-basierten Entwicklungs-prozesses.

In der Regel soll davon ausgegangen werden, dass die Entwickler, die zuvor imV-Modell-basierten Entwicklungsprozess mitgewirkt haben, danach auch Teil desSCRUM-Teams sind. Dadurch kann die Projekterfahrung der Mitarbeiter in denSCRUM-Prozess einfließen. Würde andernfalls ein Team für den SCRUM-Prozess ein-gesetzt werden, dass mit dem Projekt zuvor noch nichts zu tun hatte, so muss mit einerhohen Einarbeitungszeit gerechnet werden. Außerdem würden sich die Arbeitsmecha-nismen und Abläufe deutlich verlangsamen, da immer wieder Fragen auftauchen, dieim Zweifelsfall mit dem vorherigen Team abgesprochen werden müssen. Die Vorteilevon SCRUM würden durch die hohen Abstimmungsaufwände relativiert werden. Den-noch kann es gewünscht sein, dass ein externes SCRUM Team, welches mit dem

24


Projekt zuvor nichts zu tun hatte, die Aufgaben übernimmt. In diesem Fall werden inKapitel 4.2.5 gesonderte Betrachtungen durchgeführt.

Annahme 3.3

Alle Aktivitäten im V-Modell, die Produkte erzeugen und füllen, dauern länger als30 Tage.

Im V-Modell wird nicht definiert, wie lange ein Arbeitsschritt zur Erzeugung eines Pro-dukts dauert. Um eine Basis für spätere Argumentationen zu schaffen, soll hier davonausgegangen werden, dass ein solcher Schritt mindestens 30 Tage dauert. Die Zahlergibt sich aus der impliziten Annahme, dass im V-Modell ausschließlich sinnvolle Pro-dukte erzeugt werden, die einen späteren Nutzen für das Projekt besitzen. Somit müs-sen diese Produkte umsichtig und in vollem inhaltlichen - und Qualitätsumfang erzeugtwerden.Annahme 3.4

Erzeugende Produktabhängigkeiten beschreiben Informationsflüsse.

Durch eine erzeugende Produktabhängigkeit werden Produkte nicht nur erzeugt, son-dern auch gefüllt. In welcher Form sie gefüllt werden, hängt von dem Produkt ab.Produkte, die erzeugt wurden, besitzen somit immer einen Inhalt und sind keine leereHülle.Annahme 3.5

Inhaltliche Produktabhängigkeiten beschreiben nicht zwingend Informationsflüsse.

Durch eine inhaltliche Produktabhängigkeit wird eine Konsistenzabhängigkeit zwischenProdukten beschrieben. Ändert sich ein Produkt, müssen sich möglicherweise alle vondiesem Produkt inhaltlich abhängenden Produkte ebenfalls ändern. Anders als bei dererzeugenden Produktabhängigkeit, stellt die inhaltliche Produktabhängigkeit keine Be-dingungen bezüglich der Erzeugung von Inhalten von Produkten. Inhaltliche Produkt-abhängigkeiten werden daher nicht zur Herleitung der Informationsflüsse genutzt.

Annahme 3.6

Relevante Produktabhängigkeiten, strukturelle Produktabhängigkeiten, sowie Tai-loring-Produktabhängigkeiten tragen nicht zum Informationsfluss bei.

Die Annahmen 3.4, 3.5 und 3.6 sind wichtig für die Herleitung eines Informationsflus-ses. Sie müssen getroffen werden, da sie im V-Modell nicht explizit genannt werdenund werden in Kapitel 3.4.1 genau begründet.

Annahme 3.7

Teilaufgaben des Projekts werden nicht an Lieferanten vergeben.

Diese Annahme wird getroffen, da Teile des V-Modells mit SCRUM durchgeführt wer-den sollen und SCRUM selbst in der ursprünglichen Idee keine Auslagerung von Tei-laufgaben vorsieht.

25


3.3 Beschreibung von SCRUM auf Basis vonInformationsflüssen

In diesem Kapitel werden Informationsflüsse von SCRUM mit Hilfe seiner Praktikenund Abläufe identifiziert. Da SCRUM an jeder Stelle integriert werden soll, an der ei-ne Integration sinnvoll erscheint, muss das gesamte V-Modell auf Informationsflüsseuntersucht werden, um bewerten zu können, an welchen möglichen Stellen eine In-tegration tatsächlich sinnvoll ist. Hingegen reicht es, nur den Informationsfluss an denSchnittstelen von SCRUM zu betrachten, da lediglich diese Bereiche für die Integrationvon Interesse sind. Dies liegt daran dass für die Integration entscheidend ist, dass dieInformationsflüsse aus dem V-Modell heraus korrekt in den SCRUM Prozess hineinfließen. Dieser Fluss muss korrekt vollzogen werden, um eine reibungslose Arbeit mitSCRUM aufnehmen zu können. Welche Informationsflüsse in SCRUM selbst fließen,spielt für die Integration aus Sicht der Schnittstellen keine Rolle. Der eigentliche Ablaufvon SCRUM soll so weit es geht nach Schwaber [BEEDLE . SCHWABER 2002] durch-geführt werden, um die Vorteile von SCRUM durch die Integration so gut wie möglichnutzen zu können. Natürlich ist es notwendig, die Abläufe von SCRUM zu untersuchenund zu beschreiben, ob oder wie sie geändert werden müssen, falls dies notwendigist. Zudem ist es wichtig, die Schnittstellen genau zu beschreiben und eventuell anzu-passen. Dies wird in Kapitel 4.2 genauer ausgeführt.

Nun werden, wie schon erwähnt, die Praktiken von SCRUM untersucht, um analysie-ren zu können, wie Informationen in SCRUM hinein und aus SCRUM heraus fließen.In Kapitel 2.3 werden die Praktiken von SCRUM genau erklärt. An dieser Stelle wer-den die relevanten Aspekte für den Informationsfluss zusammenfassend erklärt um zubeschreiben, wie der Informationsfluss in SCRUM aussieht.

Der SCRUM Master stellt sicher, dass die Interna von SCRUM korrekt ablaufen. Au-ßerdem dient er als Grenze zwischen Außenwelt und Team. Er ist von außen stetssicht- und ansprechbar. Allerdings ist seine Funktion in erster Linie abblockender Na-tur. Die Informationen, die er erhält, werden selten direkt an das Team weitergegeben.SCRUM besitzt andere Mechanismen für einen produktbezogenen Informationsfluss.Der SCRUM Master ist zwar sehr wichtig für SCRUM, indem er die Arbeitsbedingun-gen auf höchstem Niveau hält, für stets hohe Produktivität des Teams sorgt und Pro-bleme von außen abfängt, was aber eher die interne Arbeit, als die Schnittstellen vonSCRUM betrifft. Seine Aufgabe ist es, die Informationsflüsse an den Schnittstellen zusteuern.

Im Product Backlog werden alle Anforderungen und Ideen gespeichert, die sowohlvon innen, als auch von außen kommen. Für die Schnittstelle nach außen ist das Pro-duct Backlog also sehr wichtig. Die Anforderungen von außen können auf viele Wegein das Product Backlog einfließen. Im Falle des V-Modells liegen fertige Produkte inder Regel bereits vor. Informationen aus diesen Produkten können somit direkt in dasProduct Backlog einfließen. Eine Rolle, zum Beispiel der Product Owner, muss dafürsorgen, dass die Informationen in das Product Backlog übernommen werden. Somitkann sichergestellt werden, dass benötigte Informationen für SCRUM zur Verfügungstehen. Die Übernahme der Informationen in das Product Backlog zieht zudem mit

26


sich, dass dem Team bekannt gegeben werden muss, welche Informationen sich imProduct Backlog befinden. Das Team muss also konkret wissen, mit welchen Infor-mationen es arbeiten soll und kann. In Kapitel 4.2 wird genau erklärt, was bei derBenutzung des Product Backlogs zu berücksichtigen ist.

Soll SCRUM bereits zu Beginn eines Projekts angewendet werden, also genau dann,wenn noch keine Schritte im V-Modell durchgeführt worden sind, liegen noch keineProdukte vor. In diesem Fall startet SCRUM mit leerem Product Backlog. Das ProductBacklog muss somit zuerst ausreichend gefüllt werden, um einen Sprint zu starten.Dies kann geschehen, indem Anforderungen oder Informationen aus einem informel-len Anforderungsdokuments (feste Informationen) oder aus Gedanken oder Überle-gungen von Kunden oder Benutzern (flüssige Informationen) gewonnen werden.

In Abbildung 3.1 wird ein vorläufiger Informationsfluss gemäß den obigen Überle-gungen dargestellt. Die mit SCRUM bezeichnete Aktivität stellt die Entwicklung mitSCRUM dar. Unter der Entwicklung mit SCRUM sind sämtliche Arbeitsschritte undPraktiken, die in SCRUM durchgeführt werden, gemeint, inklusive mehrerer Sprints.Die Aktivität stellt nicht nur einen einzigen Sprint dar. Von außen sichtbar ist dasProdukt Backlog, in das Informationen aus dem Eingangsprodukt PE übernommenwerden. In der Abbildung und in allen weiteren Abbildungen dieses Kapitels wird dieFlow-Notation [STAPEL . SCHNEIDER 2012] verwendet.

Abbildung 3.1: SCRUM aus Informationsflusssicht inklusive Product Backlog

Da das Product Backlog nach außen hin sichtbar ist, ist leicht einzusehen, dass dieRolle des Product Owners, der für das Managen und Kontrollieren des Product Back-logs zuständig ist, ebenfalls Bestandteil des Informationsflusses ist. Der Product Ow-ner ist allerdings nicht nur für das Product Backlog verantwortlich, sondern muss auchSorge tragen, dass das gesamte Team stets über das Product Backlog bescheid weiß.Der Product Owner trifft zudem Entscheidungen, die vom Team respektiert werdenmüssen und Auswirkungen auf den gesamten Arbeitsablauf von SCRUM haben. Ernimmt am Sprint Planning Meeting, sowie am Sprint Review teil. Um das Product Back-log verwalten zu können, muss er ebenfalls über die Produkte, deren Informationen indas Product fließen, bescheid wissen. Abbildung 3.2 beschreibt diese Funktionen desProduct Owners. Er hat sowohl Einfluss auf das Product Backlog, als auch auf Aktivi-täten, die die SCRUM Interna beeinflussen.

Die Daily SCRUM Meetings, das Sprint Planning Meeting, die Sprints selbst, sowiedas abschließende Sprint Review spielen für die Integration keine Rolle, da sie nur dieinterne Arbeit von SCRUM beeinflussen. Diese Arbeit wird durch die SCRUM Aktivität

27


Abbildung 3.2: SCRUM aus Informationsflusssicht inklusive Product Owner

komplett dargestellt und ist somit als Black Box in gewisser Hinsicht Bestandteil desInformationsflusses. Jedoch ist der interne Informationsfluss der SCRUM Aktivität ausInformationsflusssicht an den Schnittstellen nicht weiter von Bedeutung. In Kapitel 4.2werden die Anpassungen der internen Mechanismen von SCRUM, wie schon erwähnt,detailliert beschrieben.

Abbildung 3.3 zeigt nun den gesamten Informationsfluss in SCRUM hinein und ausSCRUM heraus. Informationen aus Produkten, die benötigt werden, werden in dasProduct Backlog übernommen, welches vom Product Owner verwaltet wird. Dieserhat ebenfalls Aufgaben, die innerhalb von SCRUM eine Rolle spielen und kennt dieProdukte. Informationen des Product Backlogs dienen als Eingang für SCRUM undwerden innerhalb von SCRUM verwendet. In der SCRUM Aktivität werden die Arbeits-schritte von SCRUM durchgeführt. Am Ende der Durchführung von SCRUM werdenschließlich Produkte erzeugt, die für das V-Modell weiter verwendet werden können.Zusätzlich sind hier die Informationsflüsse der Schnittstellen verdeutlicht, die in dieAktivität „SCRUM-Integration“ hinein und aus ihr heraus fließen.

3.4 Beschreibung des V-Modells auf Basis vonInformationsflüssen

In diesem Kapitel wird beschrieben, auf welche Weise Informationsflüsse im V-Modellerkannt werden können, um später SCRUM in das V-Modell integrieren zu können.Dazu werden die Bestandteile des V-Modells, die dazu beitragen könnten, analysiert.

Prinzipiell stehen die drei Komponentenarten „Vorgehensbaustein“, „Entscheidungs-punkt“ und „Produkt“ zur Verfügung, sowie die Bestandteile eines Vorgehensbausteins„Rolle“ und „Aktivität“. Aus diesen Komponentenarten soll nun versucht werden, einInformationsfluss herzuleiten, was nicht bei allen Komponenten problemlos möglichist.

Vorgehensbausteine werden im V-Modell für die Planung und die Anpassung der durch-

28


Abbildung 3.3: Gesamter Informationsfluss in SCRUM hinein und aus SCRUM heraus

zuführenden Prozesse verwendet und spielen für die eigentliche Projektdurchführungspäter keine Rolle mehr. Für die Durchführung sind die Entscheidungspunkte von Be-deutung. Daher scheiden die Vorgehensbausteine als Lieferant für Informationsflüsse,die während des Projekts fließen, aus.

Die Entscheidungspunkte werden schrittweise nacheinander ausgeführt und bildensomit einen fortschreitenden Ablauf. Allerdings definieren sie nicht, wie die Produkteerzeugt werden oder wann dies geschieht. Sie legen lediglich fest, dass zu einemgegebenen Zeitpunkt eine definierte Menge von Produkten vorhanden sein muss. Aufoberster Abstraktionsebene geben sie zwar eine grobe Richtung vor, allerdings muss,um einen konkreten Informationsfluss zu erkennen, noch näher ins Detail gegangenwerden.

Daher lohnt es sich, die Komponenten „Rolle“, „Aktivität“ und „Produkte“ des V-Modellszu betrachten. Diese sind, wie in Kapitel 2.2.1 beschrieben, miteinander verknüpft. Daein Produkt von einer Rolle mittels einer Aktivität erstellt wird, erscheint es logisch, dieAbhängigkeiten zwischen den jeweiligen Produkten zu suchen, da diese die Mengeder finalen Produkte darstellen und in handfester Form vorliegen. Diese Wahl wirddurch die Tatsache unterstützt, dass das V-Modell XT bereits Abhängigkeiten zwischenProdukten identifiziert hat.

3.4.1 Produktabhängigkeiten

Das V-Modell gibt insgesamt fünf unterschiedliche Typen von Produktabhängigkei-ten an. Es gibt „erzeugende Produktabhängigkeiten“, „inhaltliche Produktabhängigkei-ten“, „relevante Produktabhängigkeiten“, „strukturelle Produktabhängigkeiten“, sowie„Tailoring-Produktabhängigkeiten“. Nicht alle davon tragen zum Informationsfluss bei.Daher soll an dieser Stelle untersucht werden, welche Produktabhängigkeiten zum In-formationsfluss beitragen und welche nicht weiter betrachtet werden müssen. Diese

29


fünf Produktabhängigkeiten werden laut V-Modell [vmo] wie folgt definiert und erklärt.

Erzeugende Produktabhängigkeiten legen Bedingungen oder Regeln zum Erzeu-gen von Produkten fest. Sie beschreiben auf unterer Abstraktionsebene, wie die einzel-nen Produkte erzeugt werden. Für genau diesen Schritt der Erzeugung von Produktenmüssen Informationen fließen. Es werden also Informationen aus Produkten gezogen,die von Entwicklern benutzt werden, um andere Produkte zu erzeugen. Daher be-schreiben, wie in Annahme 3.4 erklärt wird, die erzeugenden Produktabhängigkeiteneinen Informationsfluss.

Inhaltliche Produktabhängigkeiten sind gegeben, wenn die Änderung eines Pro-dukts eine Änderung anderer Produkte nach sich zieht. Für die Änderungen der Pro-dukte muss natürlich auch ein Informationsfluss vorliegen. Dieser Informationsflusssoll aber nicht betrachtet werden, da ein allgemeiner, immer gegebener Informations-fluss identifiziert werden soll (siehe Annahme 3.5). Würden alle Informationsflüsseberücksichtigt werden, die zu Änderungen beitragen, wäre der Graph, der diese Infor-mationsflüsse beinhaltet, ein nahezu vollständiger Graph. Ein Beispiel ist in Abbildung3.4 dargestellt. Daher sind inhaltliche Produktabhängigkeiten in diesem Kontext nichtvon Bedeutung.

Abbildung 3.4: Beispiel für inhaltliche Produktabhängigkeiten des V-Modells

Relevante Produktabhängigkeiten sind gegeben, wenn sie nach Durchführung desTailorings noch mindestens zwei verbliebene Produkte enthalten. Diese Eigenschaftmacht keine Aussage darüber, wie Produkte konkret voneinander abhängen, sondernist viel mehr ein Maß dafür, ob eine vordefinierte Produktabhängigkeit nach dem Tai-loring immer noch Bestand hat. Für den Informationsfluss ist daher von Bedeutung,dass jede Abhängigkeit, die zum Informationsfluss beiträgt, eine relevante Produktab-hängigkeit sein muss.

Strukturelle Produktabhängigkeiten sind hierarchische Anordnungen von Produk-ten. Da sie nur Angaben darüber machen, wie das fertige Produkt aufgebaut ist, nichtaber, wie der Ablauf der Entwicklung aussieht, tragen sie nichts zum Informationsflussbei.

Tailoring-Produktabhängigkeiten sind Produktabhängigkeiten, die wichtig in Bezugauf das Tailoring sind. Sie werden bei der Prozesserarbeitung, nicht jedoch bei der

30


Prozessdurchführung benötigt und tragen daher auch nicht zum Informationsfluss bei.

Alles in allem sind alle erzeugenden Produktabhängigkeiten für den Informationsflusswichtig, sofern sie relevante Produktabhängigkeiten sind. Die erzeugenden Produktab-hängigkeiten werden genau im V-Modell definiert. Aus diesen Produktabhängigkeitenkann nun nachfolgend ein Informationsfluss gewonnen werden.

3.4.2 Von den Produktabhängigkeiten zum Informationsfluss

Ausgehend von den Produktabhängigkeiten im V-Modell kann nun ein Informations-fluss bestimmt werden. Da der Informationsfluss allerdings nicht direkt aus den Ab-hängigkeiten hervorgeht, wird hier beschrieben, wie der Informationsfluss bestimmtwerden kann.

Die Abhängigkeiten im V-Modell bestehen zwischen Produkten. Abbildung 3.5 zeigt einBeispiel für mehrere Produktabhängigkeiten. Es muss beachtet werden, dass sowohlEingangs-, als auch Ausgangspunkt einer Abhängigkeit ein Produkt ist. Außerdem sinddie Abhängigkeiten gerichtet. Es kann also immer ein Ein- und Ausgangspunkt einerAbhängigkeit eindeutig identifiziert werden. In Abbildung 3.5 erzeugt das Produkt „SW-Architektur“ die Produkte „SW-Komponente“, „SW-Spezifikation“ und „SW-Modul“.

Abbildung 3.5: Beispiel für Produktabhängigkeiten des V-Modells

Zuerst müssen alle Produkte und ihre Abhängigkeiten, sowie die dazugehörigen Rol-len identifiziert werden. Die Produkte werden, wie schon erwähnt, über die Produktab-hängigkeiten richtungsweisend zu einem ersten Informationsflussansatz zusammen-gefasst. Der eigentliche Informationsfluss wird über die Aktivitäten und Rollen konstru-iert, die bereits den Produkten zugeordnet sind.

Nun wird jeweils zwischen zwei Produkten eine FLOW-Aktivität geschaltet. Diese Flow-Aktivität steht symbolisch als Beschreibung für die durchzuführenden Aktivitäten, diebenötigt werden, um ein Produkt zu erstellen oder zu verändern. Die Flow-Aktivitätbekommt denselben Namen, wie die Aktivität, die im V-Modell dem Ausgangsproduktzugeordnet wird. Da jedem Produkt im V-Modell auch genau eine Aktivität zugeordnetwird, bekommt jede FLOW-Aktivität exakt einen Namen.

Abbildung 3.6 zeigt eine solche Zuordnung. Hier erzeugt das Produkt „SW-Architektur“das Produkt „SW-Modul“. Dies geschieht durch die Aktivität „SW-Modul realisieren“.

Somit steht zwischen jedem Produkt eine FLOW-Aktivität. Der bisherige Informati-onsfluss ist so zu verstehen, dass Dokumente (Produkte) durch FLOW-Aktivitäten

31


Abbildung 3.6: Beispiel für Produktabhängigkeiten und Aktivitäten des V-Modells

(Aktivitäten) erzeugt werden. Die Weitergabe von Informationen geschieht somit inden Schritten zwischen den Produkten, also genau in den FLOW-Aktivitäten. In die-sen FLOW-Aktivitäten werden Informationen weitergegeben, neue Dokumente erzeugtoder bestehende Dokumente verändert. Letztendlich wird im V-Modell keine Aussagegetroffen, was genau dort getan wird oder wie es geschieht. Sie stehen lediglich alsPlatzhalter für die Tatsache, dass etwas passiert. Somit wird das Projekt voran getrie-ben, indem neue Dokumente durch FLOW-Aktivitäten erzeugt werden.

Zuletzt werden die Rollen, die den Produkten und Aktivitäten zugeordnet sind, in denInformationsfluss aufgenommen. Mitwirkende Rollen sind Rollen, die zwar an der Fer-tigstellung eines Produkts mitwirken, an der Erzeugung allerdings nicht direkt beteiligtsind. Beispielsweise schreibt eine Person, die einer mitwirkenden Rolle zugewiesenwurde, keinen Code. Der Code selbst wird durch Personen geschrieben, die einerverantwortliche Rolle zugeteilt wurden. Verantwortliche Rollen sind also direkt für dieErzeugung von Produkten zuständig, daran beteiligt und dafür verantwortlich, dassdas Produkt fertiggestellt und weitergegeben wird. Da die Informationen, die die Rol-len besitzen, zum Erstellen eines Produkts benutzt werden und die Erstellung in denAktivitäten geschieht, fließen die Informationen der Rollen direkt in die Aktivitäten undsomit indirekt in das Produkt. Dabei muss beachtet werden, dass die Informationeneiner Rolle, die verantwortlich für ein Produkt B ist, in die Aktivität fließen, in der dasProdukt B erstellt wird.

Die Produkte sind in FLOW feste Informationsspeicher und werden als Dokument-Symbol dargestellt. Die Rollen hingegen sind flüssige Informationsspeicher. In derFLOW-Notation würden sie mit dem Smiley-Symbol dargestellt werden. Aus Platzgrün-den werden sie allerdings im Folgenden als Oval dargestellt.

Abbildung 3.7 zeigt ein Beispiel für einen derart erarbeiteten Informationsfluss auseinem Ausschnitt des V-Modells aus einem AG/AN-Projekt mit Entwicklung, Weiter-entwicklung oder Migration. Verantwortliche Rollen werden durch rote, ausgehendePfeile und mitwirkende Rollen durch schwarze, ausgehende Pfeile dargestellt.

32


Abbildung 3.7: Beispiel eines Informationsflusses aus einem Ausschnitt des V-Modells

33

4 Anpassung von SCRUM an dieInformationsflüsse des V-Modells

In Kapitel 3 wurden Informationsflüsse im V-Modell und in SCRUM identifiziert. UmSCRUM in das V-Modell integrieren zu können, müssen die Informationsflüsse desV-Modells zuerst allgemein betrachtet werden, um herauszufinden, bei welchen In-formationsflussabläufen und -verzweigungen Schwierigkeiten auftreten und wie dieseSchwierigkeiten zu lösen sind. Kapitel 4.1 stellt insgesamt 5 unterschiedliche Informa-tionsflussabläufe vor und geht auf eventuelle Schwierigkeiten ein.

Anschließend wird in Kapitel 4.2 beschrieben, welche Apsekte von SCRUM angepasstwerden müssen, damit eine Integration von SCRUM in das V-Modell möglich ist, daeine Integration ganz ohne Anpassungen spätestens an den Schnittstellen zwischendem V-Modell und SCRUM scheitern würde.

4.1 Grundlegende Schnittstellenvarianten

In Kapitel 3 wurde ein Informationsfluss im V-Modell identifiziert. Nun muss im Hin-blick auf eine spätere Integration von SCRUM betrachtet werden, welche Integrations-möglichkeiten existieren und an welchen Stellen im Informationsfluss eine Integrationallgemein möglich ist.

Die Betrachtung ist wichtig, da auf diese Weise die Schnittstellen von SCRUM und demV-Modell im Informationsfluss analysiert werden können. Die Analyse der Schnittstel-len und des Informationsflusses zeigt, in welchen Bereichen eine Integration problem-los durchgeführt werden kann und in welchen Bereichen Einschränkungen in Kauf ge-nommen oder weiterführende Konzepte erläutert werden müssen, um eine reibungs-lose Integration von SCRUM gewährleisten zu können.

FLOW bietet sogenannte Informationsflussaktivitäten an (siehe Kapitel 2.4). Die Ideefür die spätere Integration von SCRUM ist nun, ein oder mehrere Informationsflüsse(und somit auch die zugehörigen Produkte) als Informationsflussaktivität darzustel-len. Anschließend werden alle Arbeitsschritte, die in dieser Informationsflussaktivitätliegen, durch SCRUM ersetzt. Die Herausforderung hierbei ist, den im V-Modell vor-handenen Informationsfluss an der richtigen Stelle zu schneiden, so dass er zu demInformationsfluss in SCRUM passt und somit ein Übergang möglich ist.

In Abbildung 4.1 wird die Grundidee dieses Verfahrens dargestellt. Der gesamte Infor-mationsfluss des V-Modells (links) besteht in diesem Beispiel aus zwei Informations-flüssen zwischen dem Produkt PE und dem Produkt PA. Anschließend werden einigeInformationsflüsse im V-Modell ausgewählt (Mitte) und durch Informationsflüsse von

34

4 Anpassung von SCRUM an die Informationsflüsse des V-Modells

SCRUM ersetzt (rechts).

Abbildung 4.1: Grundidee der Integration von SCRUM auf Basis vonInformationsflüssen

Definition 4.1

Die mit SCRUM durchzuführende Informationsflussaktivität wird im Folgenden alsSCRUM-Aktivität bezeichnet.

Definition 4.2

Die durch SCRUM zu ersetzende Informationsflussaktivität wird im Folgenden alsZu-ersetzende-Aktivität bezeichnet.

Wie genau die SCRUM-Aktivität (in Abbildung 4.1 mit „SCRUM-Integration“ gekenn-zeichnet) auf Basis von Informationsflüssen aussieht, wird in Kapitel 3.3 im Detail er-läutert. An dieser Stelle sind nun die Schnittstellen der SCRUM-Aktivität nach außenvon Bedeutung, um die SCRUM-Aktivität in den Informationsfluss sinnvoll einzubin-den. Die Schnittstellen werden in Kapitel 3.3 erklärt und in Abbildung 3.3 dargestellt.In diesem Beispiel gibt es genau ein Eingangsprodukt PE und ein AusgangsproduktPA. Informationen des Eingangsprodukts werden in das Product Backlog von SCRUMübernommen und sind somit Eingabe für die SCRUM-Aktivität (mit SCRUM-Integrationgekennzeichnete Aktivität) und den späteren SCRUM-Prozess (mit SCRUM gekenn-zeichnete Aktivität). Da der Product Owner in SCRUM auch für das Product Back-log zuständig ist und das Product Backlog von außen sichtbar ist, ist der ProductOwner auf dieser Ebene ebenfalls sichtbar. Die SCRUM-Aktivität liefert als Ausga-be das Ausgangsprodukt PA, welches mit SCRUM und den entsprechenden SCRUM-Mechanismen erzeugt wird.

Konkreter existieren zwei Schnittstellen. Die erste Schnittstelle sind die eingehendenInformationsflüsse (hier zwischen PE und Product Backlog beziehungsweise ProductOwner). Die Informationen aus den Eingangsprodukten müssen in das Product Back-log übernommen werden, was in Kapitel 4.2.3 erklärt wird. Die zweite Schnittstellesind die ausgehenden Informationsflüsse, welche zum Erzeugen der ausgehendenProdukte beitragen, welche später für das V-Modell weiter verwendet werden können.

35


Somit lässt sich aus dem identifizierten Informationsfluss des V-Modells eine Mengevon Informationsflüssen auswählen, um diese als zu-ersetzende-Aktivität darzustellen.

Es gibt insgesamt fünf grundlegende Schnittstellenvarianten für die Auswahl der Infor-mationsflüsse, die in der SCRUM-Aktivität enthalten sein sollen. Bei diesen Schnittstel-lenvarianten stellt sich die Frage, ob und wie SCRUM derart integriert werden kann,so dass eine Durchführung von SCRUM möglich ist. Hier werden nun die unterschied-lichen Schnittstellenvarianten erklärt und diese Frage für jede Schnittstellenvariantebeantwortet.

4.1.1 Schnittstellenvariante 1: Elementarer Informationsfluss

Die erste Schnittstellenvariante eines Informationsflusses wird in Abbildung 4.2 dar-gestellt. Hierbei handelt es sich um einen elementaren Informationsfluss ohne Verbin-dungen zu anderen Informationsflüssen. Dabei wird auf der linken Seite der Informati-onsfluss im V-Modell dargestellt. Der schwarze Rahmen symbolisiert dabei die Mengeder Informationsflüsse, die für die SCRUM-Aktivität ausgewählt wurde. Auf der rech-ten Seite wird dargestellt, wie der Informationsfluss nach einer Integration von SCRUMaussieht.

In diesem noch sehr einfachen Fall werden Informationen aus dem (Eingangs-)ProduktPE in das Product Backlog übernommen und das (Ausgangs-)Produkt PA ist das Er-gebnis der Abläufe, die innerhalb der SCRUM-Aktivität durchgeführt werden.

Abbildung 4.2: Elementarer Informationsfluss

Würde tatsächlich eine derartige Ersetzung in einem Projekt durchführt werden, würdedies bedeuten, dass sich die Art und Weise des Informationsflusses ändern würde.Eingangs- und Ausgangsprodukte würden nicht mehr mittels der im V-Modell gängigenMethoden erstellt werden, sondern über die mit SCRUM gängigen Mechanismen.

Die Integration von SCRUM bereitet bei dieser Schnittstellenvariante keine Proble-me, wenn ausschließlich Informationsflüsse betrachtet werden. Informationen aus demEingangsprodukt werden an das Product Backlog übergeben und das Ausgangspro-dukt wird nach der Durchführung von SCRUM weiter benutzt.

36


4.1.2 Schnittstellenvariante 2: Sequentieller Informationsfluss

Die zweite, in Abbildung 4.3 gezeigte, Schnittstellenvariante ähnelt der ersten Schnitt-stellenvariante. Der einzige Unterschied besteht darin, dass nun mehrere sequentielleInformationsflüsse ausgewählt werden. Für die Ersetzung der ausgewählten Informati-onsflüsse durch SCRUM hat dies nun den Vorteil, dass diese sequentiellen Zwischen-produkte weggelassen werden können.

Abbildung 4.3: Sequentieller Informationsfluss

Für die Integration von SCRUM auf Basis von Informationsflüssen bedeutet dies imVergleich zur ersten Schnittstellenvariante jedoch keine Unterschiede. Nach wie vorgibt es keine Probleme, da Informationen des Eingangsprodukts wiederum an dasProduct Backlog überreicht werden und das Ausgangsprodukt nach der Durchführungvon SCRUM weiter benutzt werden kann.

4.1.3 Schnittstellenvariante 3: Paralleler Informationsfluss

Auch bei der dritten Schnittstellenvariante, dargestellt in Abbildung 4.4, gibt es keineweiteren auftretenden Probleme im Vergleich zu den ersten beiden Schnittstellenvari-anten. Nun liegen parallele Informationsflüsse vor. Vom Eingangsprodukt fließen Infor-mationen parallel in n weitere Produkte. Ausgehend von diesen Produkten fließen dieInformationen anschließend in das Ausgangsprodukt.

Wiederum ergeben sich aus Informationsflusssicht keine expliziten Probleme. Genauwie bei der sequentiellen Schnittstellenvariante (Kapitel 4.1.2) können Informationendes Eingangsprodukts dem Product Backlog übergeben werden und das Ausgangs-produkt als Ergebnis von SCRUM für die Weiterarbeit übernommen werden.

37


Abbildung 4.4: Paralleler Informationsfluss

4.1.4 Schnittstellenvariante 4: Informationsfluss mit mehrerenEingängen

Bei der vierten Schnittstellenvariante in Abbildung 4.5 ändert sich nun erstmals etwasbei Informationsflüssen, die nicht Bestandteil der Menge von Informationsflüssen fürdie Auswahl für die SCRUM-Aktivität sind. In diesem Beispiel gibt es n Eingangspro-dukte, von denen Informationen in ein weiteres Produkt PV fließen. Somit besitzt dieSCRUM-Aktivität n eingehende Informationsflüsse.

Abbildung 4.5: Informationsfluss mit mehreren Eingängen

Anders als bei den ersten drei Schnittstellenvarianten müssen hier alle Informationender Eingangsprodukte in das Produkt Backlog übernommen werden. Dies muss fürjedes Produkt nacheinander oder parallel geschehen. Wie genau diese Übernahmefunktioniert, wird in Kapitel 4.2.3 beschrieben. Es werden also alle Informationen ein-gehender Produkte dem Backlog überreicht und das ausgehende Produkt wieder alsErgebnis der SCRUM-Aktivität entnommen.

38


4.1.5 Schnittstellenvariante 5: Informationsfluss mit mehrerenAusgängen

Die in Abbildung 4.6 gezeigte, fünfte Schnittstellenvariante ähnelt von der Idee herder vorherigen. Nun gibt es nicht mehrere eingehende Informationsflüsse, sondernmehrere ausgehende Informationsflüsse, also mehrere Ausgangsprodukte.

Abbildung 4.6: Informationsfluss mit mehreren Ausgängen

Soll SCRUM in das V-Modell integriert werden und sehen die zu ersetzenden Infor-mationsflüsse wie in dieser Schnittstellenvariante aus, so müssen zwei Situationenunterschieden werden.

In der ersten Situation sollen alle m Produkte PA1bis PAm

mit SCRUM erzeugt werden.Dies ist uneingeschränkt mit SCRUM möglich, da das Team entscheiden kann, wannwelche Produkte erzeugt werden sollen.

In der zweiten Situation sollen weniger Produkte von SCRUM erzeugt werden, alsin der Abbildung auf der rechten Seite aufgelistet sind (j viele Produkte sollen erzeugtwerden, j < m). Da das Produkt PV aber eingespart werden soll, fehlt die Grundlage fürdie Erzeugung der Produkte auf V-Modell-basierte Art, sobald SCRUM abgeschlossenwurde. Das V-Modell würde die Erzeugung der übrigen m � j Produkte auf Basis vonInformationen des Produkts PV verlangen. Das Produkt PV wurde aber nicht erzeugt.

Um dieses Problem zu lösen und gleichzeitig von der Einsparung des Produkts PVzu profitieren, müssen die m � j Produkte, die ursprünglich nicht mit SCRUM erzeugtwerden sollten, zusätzlich mit SCRUM erzeugt werden. Somit fehlen in der V-Modell-basierten Entwicklung keine Produkte für die Erzeugung weiterer Produkte.

Dies hat zur Folge, dass alle Abhängigkeiten bekannt sein müssen, damit eine Inte-gration von SCRUM erfolgreich durchgeführt werden kann. In Kapitel 6.1 wird eineAnwendung vorgestellt, welche diese Abhängigkeiten ermittelt und somit sicherstellt,dass die Integration nicht durch fehlendes Wissen über die Abhängigkeiten fehlerhaftdurchgeführt wird oder scheitert.

39


In der Praxis werden Kombinationen dieser fünf Schnittstellenvarianten vorzufindensein, was in Kapitel 5.1 deutlich wird. Da es für jede Schnittstellenvariante eine Lö-sung gibt, wie SCRUM integriert werden kann, ist die Integration von SCRUM folglichim gesamten Informationsfluss möglich, sofern die Lösungsvorschläge befolgt werdenund die Praktiken von SCRUM, wie im Nachfolgenden Kapitel 4.2 beschrieben, ange-passt werden. Wichtig dabei ist grundlegend immer, dass die Ausgangsprodukte aufjeden Fall erzeugt werden, da das V-Modell mit diesen Produkten weiterarbeiten wird.

4.2 Anpassung von SCRUM

Um möglichst viele Vorteile von SCRUM nutzen zu können, soll bei der IntegrationSCRUM so weit wie möglich nach Schwaber [BEEDLE . SCHWABER 2002] durchge-führt werden. Durch die Einbettung in das V-Modell ergeben sich allerdings einigeEinschränkungen, für die SCRUM angepasst werden muss.

Der gesamte Informationsfluss des Projekts nach der Integration von SCRUM funktio-niert wie folgt. Zuerst werden Arbeitsschritte im V-Modell durchgeführt und Produkteerzeugt. Ist der Zeitpunkt erreicht, an dem SCRUM starten soll, so dienen einige dererzeugten Produkte als Eingabe für SCRUM. Die benötigten Informationen werdenaus diesen Produkten hergeleitet und in das Product Backlog von SCRUM geschrie-ben. Anschließend wird SCRUM mit diesen Informationen durchgeführt. Dabei werdenwiederum Produkte mit SCRUM erzeugt, die nach der agilen Entwicklung mit SCRUMfür die Entwicklung gemäß V-Modell weiter verwendet werden.

Damit dieser Ablauf funktioniert, müssen die Praktiken von SCRUM an einigen Stellenangepasst werden, was im Folgenden beschrieben werden soll.

4.2.1 Kunde

In einem normalen SCRUM Projekt kommen die Anforderungen von einem Kunden,der seine Wünsche und Ziele vertritt und ein Unternehmen beauftragt, ein Produkt zuerstellen. Dieser Kunde muss nicht zwangsweise mit der Softwareentwicklung oderSoftware im Allgemeinen vertraut sein.

Nun wird SCRUM aber in das V-Modell XT integriert. Es ist somit kein Projekt im ur-sprünglichen Sinne mehr, sondern Teil eines Projekts. Dabei lässt sich nicht einmalallgemein entscheiden, welche Ergebnisse durch den Einsatz von SCRUM erzielt wer-den sollen. Die Ergebnisse sind abhängig davon, an welcher Stelle SCRUM integriertwerden soll. Folglich ist es möglich, dass ein Produkt erzeugt wird, welches für denKunden nicht von Interesse ist oder in welches der Kunde keine Einblicke erhaltensoll.

In diesem Fall ist der Kunde, der ein Interesse am Endprodukt hat, nicht der Kunde,der in SCRUM zum Einsatz kommt, da die internen Produkte vom V-Modell und somitvom Unternehmen gefordert werden und nicht vom Kunden selbst. Somit werden die

40


Personen zum Kunden, die ein Interesse am zu erstellenden Zwischenprodukt zeigen.In der Regel ist es das Team selbst oder das Management. Das Team möchte dasProdukt erzeugen, um später auf Basis des Produkts mit dem V-Modell-basierten Pro-zess weiterarbeiten zu können. Das Management möchte das Produkt erstellen, damitder V-Modell-basierte Prozess reibungsfrei fortgesetzt werden kann.

Wird ein Kunde tatsächlich benötigt, kann ein Teammitglied oder eine Person des Ma-nagements die Rolle des Kunden übernehmen und somit den Kunden für SCRUMsimulieren. Dieser Kunde müsste sich gut mit den bisherigen Fortschritten auskennenoder das geforderte Produkt gut kennen. Alternativ kann das gesamte Team in spezi-ellen Situationen die Rolle des Kunden übernehmen, was die Verantwortung auf dasgesamte Team verteilt. Welche Situation dafür geeignet sind und welche Situationenauf gar keinen Fall dafür in Frage kommen, wird in Kapitel 4.2.7 erklärt.

In allen Fällen, in denen das Endprodukt oder Teile davon mit SCRUM entwickelt wer-den, ist es sinnvoll, den eigentlichen Kunden in diesen Prozess mit einzubeziehen,sollte er verfügbar sein und sich dazu bereit erklären. In diesem Fall kann SCRUM dieagilen Prinzipien verfolgen, indem die Kundenzufriedenheit das höchste Ziel ist.

Natürlich ist es möglich, dass es für Kunden, die die Entwicklung gemäß V-Modellgewohnt sind, schwer verständlich ist, warum sie nun während der Entwicklung anwe-send sein sollen, insbesondere wenn die Integration von SCRUM intern geschieht undnach außen hin gar nicht sichtbar ist. Es soll also nicht verpflichtend sein, dass derKunde im SCRUM Prozess anwesend ist, wäre aber von Vorteil.

4.2.2 SCRUM Master

Der SCRUM Master muss zusätzlich zu seinen Aufgaben, die er von SCRUM vor-geschrieben bekommt, ein gutes Wissen über die Integration von SCRUM in das V-Modell XT besitzen, da er die erste Anlaufstelle bei Fragen und Problemen bezüglichder Integration ist. Zudem muss er die geänderten Mechanismen kennen, um seinerAufgabe, das Team zu jeder Zeit so effizient es geht arbeiten zu lassen, gerecht zuwerden.

Der SCRUM Master muss einen Überblick über den gesamten, im V-Modell stattfin-denden Informationsfluss besitzen, um dem Team vermitteln zu können, welche Pro-dukte für SCRUM eine Rolle spielen und welche Produkte das Ziel von SCRUM sind.Er muss also Klarheit über Ausgangssituation und Ziel von SCRUM schaffen.

Um diese Eigenschaften gut ausfüllen zu können, wäre es von Vorteil, wenn derSCRUM Master sowohl im Umgang mit dem V-Modell, als auch im Umgang mit SCRUMbereits Erfahrungen sammeln konnte. Sollte das Team eher unerfahren sein, sei esim Umgang mit dem V-Modell, als auch im Umgang mit SCRUM, kann der SCRUMMaster seine Erfahrungen weitergeben und das Team leiten. Im Optimalfall sind dieErfahrungen des Teams allerdings zu gleichen Anteilen verteilt. Dies wird in Kapitel4.2.5 genauer beschrieben.

41


4.2.3 Product Backlog

Das Product Backlog soll die Informationen, die aus dem V-Modell nach SCRUM flie-ßen, aufnehmen und für das Team zugänglich machen. Daher ist es sehr wichtig,genau zu betrachten, wie dies funktionieren soll.

Die Informationen des Product Backlogs müssen für das Team zugänglich gemachtwerden. Dabei muss zum einen darauf geachtet werden, dass das Team auf das Pro-duct Backlog zugreifen kann. Zum anderen muss der Product Owner darauf achten,dass das Team zu jeder Zeit weiß, welche Informationen und Produkte im ProductBacklog enthalten sind. Dies würde sich beispielsweise dadurch bewerkstelligen las-sen, dass der Informationsfluss in SCRUM hinein dem Team präsentiert wird und somitanschaulich dargestellt wird, welche Informationen welcher Produkte im Product Back-log verfügbar sind.

Das SCRUM Team muss diese Informationen später verwenden können, um Aufga-ben festzulegen und somit weitere Produkte zu erzeugen. Die Informationen aus denProdukten werden in das Product Backlog übernommen und liegen dort in einer Formvor, die für eine weitere Verarbeitung mit SCRUM geeignet ist. Im Folgenden wirdbeschrieben, wie genau das Übernehmen der Informationen ablaufen kann, wie dieInformationen aus den Produkten gewonnen werden können und was eine gute Formder Informationen ist, um diese später in SCRUM problemlos zu verwenden.

Als erste Idee bietet sich an, die Produkte als Ganzes direkt in das Product Backlogzu kopieren oder zu verschieben. Somit würden alle Informationen unverfälscht in dasProduct Backlog übernommen werden und es müsste keine gesonderte Arbeit auf-gewendet werden. Allerdings können die Produkte des V-Modells sehr groß und um-fangreich sein. In derart großen Dokumenten ist es schwierig, Informationen gezielt zufinden. Außerdem bleibt die Frage offen, wie Produkte priorisiert werden sollen. Solljeder Satz einzeln priorisiert werden oder das Produkt als Ganzes? Falls es nur einProdukt gibt, würde es in letzterem Fall nur eine einzige Priorität geben. Zudem würdedies bedeuten, dass alle Informationen des Produkts die gewählte Priorität bekom-men. In der Regel sollten die Anforderungen deutlich feiner priorisiert werden. DieseIdee scheidet also bereits im Vorfeld aus.

Daher müssen die Informationen der Produkte separat in das Product Backlog über-nommen werden. Somit können sie priorisiert und schrittweise bearbeitet werden. Nunenthält das Product Backlog, wie in Kapitel 2.3 beschrieben, Anforderungen in Formvon allgemeinsprachlichen Aussagen oder User Stories. Nicht alle Informationen, diein den Produkten des V-Modells stehen, sind Anforderungen. Folglich müssen die In-formationen analysiert und umgewandelt werden, so dass Anforderungen entstehen,die in das Product Backlog übernommen und dort priorisiert werden können.

Um die Informationen analysieren und umwandeln zu können, müssen die Produkteschrittweise abgearbeitet werden. Jedes Produkt muss erneut gelesen werden. Zudemmuss für jede Information, die in dem Produkt enthalten ist, bewertet werden, ob dieseInformation in eine Anforderung überführt werden soll. Einleitender Text eines Pro-dukts ist beispielsweise eine Information, die im Product Backlog in der Regel nicht als

42


Anforderung wiedergefunden wird. Dabei werden in einigen Produkten des V-Modellsbereits Anforderungen aufgelistet. Diese Anforderungen lassen sich leicht überneh-men, sofern sie zum Erstellen des Produkts, welches mit SCRUM erstellt werden soll,beitragen. Soll zum Beispiel die Systemarchitektur erstellt werden, sind Informationendes Pflichtenhefts, die für den Datenbankentwurf, aber nicht für die Systemarchitekturwichtig sind, vernachlässigbar.

Schwieriger wird es, wenn Anforderungen nicht konkret genannt werden. In diesemFall müssen die Anforderungen aus den Informationen hergeleitet werden. Um zuentscheiden, welche Informationen für das Herleiten von Anforderungen wichtig sind,muss zuerst das Produkt betrachtet werden, welches erstellt werden soll. Ist die Auf-gabe, Software zu erstellen, so sehen die Anforderungen, wie in SCRUM üblich, soft-warebezogen aus. Es können die bereits erwähnten Anforderungen gestellt werden.Sollte das gewünschte Produkt allerdings nicht Bestandteil der Software sein, müssendie Anforderungen anders formuliert werden. Anforderungen, die auf das Verhaltendes Systems abzielen, spielen für die Erstellung der Systemarchitektur keine direkteRolle, sondern kommen erst bei der Erstellung der SW-Komponenten und SW-Modulezum Tragen. In diesem Fall müssen die Anforderungen derart formuliert werden, dasssie auf die Erstellung des Produkts hinarbeiten. Es muss also möglich sein, Aufgabenaus den Anforderungen herzuleiten. Diese Herleitung geschieht gemäß SCRUM imSprint Planning Meeting.

Die Herleitung der Anforderungen für ein Produkt muss durch Experten geschehen.Soll ein Produkt mit SCRUM erzeugt werden, dann gelingt dies in der Regel nur, wenndas Team mindestens ein Mitglied besitzt, welches sich mit dem Zielprodukt auskennt.Soll die Systemarchitektur erstellt werden, muss folglich mindestens ein Systemarchi-tekten im Team sein. Da das Team nach Annahme 3.2 aus Entwicklern des V-Modellsbesteht und das V-Modell in diesem Beispiel die Rolle des Systemarchitekten fordert,befindet sich ein solcher ebenfalls im SCRUM Team. Es gilt also nur darauf zu achten,dass eben diese Rolle auch an der Erstellung der Anforderungen mitwirkt.

Wird im V-Modell XT in einem AG/AN-Projekt mit Entwicklung, Weiterentwicklung oderMigration der Graph betrachtet, der die erzeugenden Produktabhängigkeiten darstellt,also die Produktabhängigkeiten, die zum Informationsfluss beitragen, so fällt auf, dassder Graph azyklisch ist und die maximale Länge eines Pfades des Graphen vier be-trägt. Das bedeutet, dass der Pfad von einem Produkt P1 zu einem anderen ProduktP4 über maximal zwei weitere Produkte P2 und P3 gehen kann. Die Kette der Produk-tabhängigkeiten ist also nicht beliebig lang. In diesem Projekt ist das Produkt P1 ineinem Pfad der Länge vier immer das Pflichtenheft. Es gibt kein anderes Produkt P1,welches Bestandteil eines Pfades der Länge vier ist.

Geht man nun davon aus, dass ein Produkt P1 in das Produkt Backlog übernommenwerden soll, um ein Produkt P4 zu erzeugen, so können dabei maximal die ProdukteP2 und P3 auf diesem Pfad übersprungen werden. In diesem Fall können maximal zweiProdukte auf diesem Pfad eingespart werden. Die Aufgabe an die Entwickler, Anforde-rungen aus einem beliebigen Produkt P1 zu gewinnen, um ein beliebiges Produkt Pi ,i 2 f2; 3; 4g, zu erstellen, ist also nicht beliebig schwer. Es sollte also immer möglichsein, eindeutige Anforderungen aus dem Produkt P1 für das Produkt Pi zu gewinnen,

43


da das Produkt Pi „inhaltlich nahe“ am Produkt P1 liegt. Das soll heißen, dass die In-formationen, die im Produkt P1 enthalten sind, immer ausreichen, um Anforderungenfür die Erstellung des Produkts Pi herzuleiten, sofern das Produkt P1 ausreichend gutgeschrieben wurde. Es müssen also keine Zwischenprodukte erstellt werden, um dieAufgabe der Erstellung des Produkts Pi zu erleichtern.

Die Anfangsprodukte P1 eines Pfades sind im obigen Projekt immer Produkte, die In-formationen für die Weiterverarbeitung bereitstellen. Im Falle der Pfadlänge vier ist dasProdukt P1, wie schon erwähnt, das Pflichtenheft. Im Falle der Pfadlänge drei, ist dasProdukt P1 entweder das Pflichtenheft, oder eines der Produkte „Implementierungs-,Integrations- und Prüfkonzept System, die Systemarchitektur“ und „Unterstützungs-systemarchitektur“. Es handelt sich also immer um Produkte, aus denen eindeutighervorgeht, welche Aufgaben zu erledigen sind und welche Anforderungen an das zuerstellende Produkt gestellt werden.

Das Herleiten von Anforderungen aus Produkten kann unter Umständen sehr langedauern. Dieses Problem wird in Kapitel 4.4 genauer betrachtet. Die Erstellung vonUser Stories kann, beispielsweise wie in [COHN 2004] beschrieben, durchgeführt wer-den.

In SCRUM wird besonders darauf geachtet, dass das Team möglichst ohne Komplika-tionen und Probleme arbeiten kann. Dadurch ist es wichtig, dass das Team auf sämt-liche Produkte zugreifen kann, die es benötigt, insbesondere, wenn Sachlagen unklarsind. Die Arbeit von SCRUM sollte nicht eingeschränkt werden, indem Informationenaus Produkten nicht in das Product Backlog übernommen wurden.

Existieren für das Product Backlog und SCRUM selbst mehr als ein Eingangsprodukt,so werden alle relevanten Informationen aus diesen Produkten gleichermaßen in dasProduct Backlog übernommen. Sind die Informationen im Product Backlog, könnensie gemäß ihrer Relevanz priorisiert werden, sofern dies sinnvoll ist.

4.2.4 Product Owner

Der Product Owner ist in gewisser Weise verantwortlich für das Product Backlog. Dadas Product Backlog für eine Integration angepasst werden muss, muss sich auch dieRolle des Product Owners anpassen.

Zusätzlich zu den bereits oben genannten, angepassten Aufgaben des Product Ow-ners muss der Product Owner den Überblick behalten, welche Produkte für die Ent-wicklung mit SCRUM benötigt werden. Dies kann beispielsweise mit Hilfe des in dieserArbeit zusätzlich erstellten Prototyps, welches in Kapitel 6.1 beschrieben wird, gesche-hen. Um zu entscheiden, welche Produkte entscheidend für eine Übernahme in dasProduct Backlog sind, muss der Product Owner die Informationsflüsse des V-Modellskennen und wissen, welche Produkte in einem Ersetzungsschritt mittels SCRUM be-nötigt werden.

Zudem muss der Product Owner unpopuläre Entscheidungen treffen und diese auchgegen seine Mitarbeiter durchsetzen können. Dies wird dadurch schwierig, dass der

44


Product Owner im V-Modell Prozess möglicherweise auf gleicher Ebene steht, wie sei-ne Mitarbeiter. Durch die Rolle des Product Owners bekommt er jedoch eine gehobeneRolle, die ihm ermöglicht, eigenständig Entscheidungen zu treffen und durchzusetzen.Daher sollte die Rolle des Product Owners durch eine Person besetzt werden, diein der Lage ist, eigene Entscheidungen zu vertreten und durchzusetzen, sowie keineScheu davor hat, unpopuläre Entscheidungen durchzuführen. Im Optimalfall sollte eseine Person sein, die bereits im V-Modell Prozess gezeigt hat, dass sie Verantwortungübernehmen kann und will und ein einigermaßen hohes Ansehen bei ihren Mitarbei-tern hat und auch von ihnen respektiert wird. In diesem Fall fällt es den Mitarbeiternleichter, Entscheidungen von dieser Person als gut anzusehen oder zu respektieren.

Die Rolle des Product Owners kann durch die Person besetzt werden, die der ver-antwortlichen Rolle bezüglich der Eingangsprodukte im V-Modell zugewiesen war. Aufdiese Weise wird sichergestellt, dass der Product Owner die benötigte fachliche Kom-petenz bezüglich der Produkte besitzt und sich somit auch mit den Informationen derProdukte auskennt.

Sind mehrere Produkte Informationsquellen für das Product Backlog, deren verant-wortliche Rollen durch unterschiedliche Personen übernommen wurden, so bietet essich an, die Person auszuwählen, die sich am besten mit den mit SCRUM zu erstel-lenden Produkten auskennt. Im Optimalfall wäre diese Person im V-Modell der verant-wortlichen Rolle des zu erzeugenden Produkts zugewiesen gewesen.

4.2.5 SCRUM Team

Das SCRUM Team besteht, wie in Annahme 3.2 getroffen, aus Entwicklern des V-Modell-basierten Prozesses. Dies hat den Vorteil, dass sich die Entwickler zum einenbereits in ihrem Arbeitsgebiet auskennen und keine Einarbeitungszeit mehr benötigen.Zum anderen haben sie die Produkte, die als Eingabe für SCRUM existieren, selbstgeschrieben und wissen somit sehr gut, welches Dokument Informationen an welcherStelle beinhaltet. Dadurch fällt es leichter, sich in großen Dokumenten zu Recht zufinden. Außerdem bewirkt das Stolpern des Teams über ein eigenes Produkt, welchesnicht ausreichend gut geschrieben wurde und der Informationsgewinn aus diesem Pro-dukt somit sehr schwer fällt, einen hohen Lerneffekt. Das Team würde in diesem Fallselbst die Erfahrung machen, dass es wichtig ist, Produkte nach bestem Wissen undGewissen so gut es geht zu erstellen. Diese Erfahrung ist deutlich einfacher aufzu-nehmen, als wenn ein anderes Team Anmerkungen über mangelnde Qualität einesProdukts machen würde.

Allerdings kann es ebenfalls sein, dass die Entwickler des V-Modell-basierten Prozes-ses noch keine Erfahrungen mit SCRUM gesammelt haben. Das neu zusammenge-stellte Team muss sich also zuerst an die Arbeitsweise und die Konzepte von SCRUMgewöhnen. Einarbeitung und Eingewöhnung kosten in der Regel Zeit und erfordernSpielraum für Fehler und Fehleinschätzungen. In einem derartigen Fall kann es vongroßer Bedeutung sein, zumindest eine Person im Team zu haben, die bereits Erfah-rungen mit SCRUM sammeln konnte. Im Optimalfall bekleidet diese Person die Rolle

45


des SCRUM Masters, wie oben beschrieben.

Die Alternative, von Annahme 3.2 abzuweichen, kann, abhängig von der entsprechen-den Firmenpolitik, dazu führen, dass lieber ein SCRUM erfahrenes Team zum Einsatzkommt, welches mit dem Projekt als solches noch keine Erfahrung gesammelt hat. DerVorteil dieser Entscheidung ist, dass sich das Team mit den SCRUM Mechanismenauskennt und somit direkt und gezielt arbeiten kann, zumindest was die Arbeitsabläu-fe angeht. Ein Nachteil entsteht dadurch, dass das Team bezüglich der Informationenprinzipiell von Grund auf neu anfangen muss. Nach [STAPEL 2012] ist es für Softwa-reentwickler grundsätzlich schwieriger, Wissen aus einer neuen Domäne zu erlernen,als sich neue Methoden der Softwareentwicklung anzueignen. Daher ist es sinnvoller,das domänenerfahrene Team an SCRUM heranzuführen. Sollte dennoch die ande-re Möglichkeit bevorzugt werden, ist es in diesem Fall eine gute Idee, den Einsatzvon SCRUM „klassisch“ ablaufen zu lassen. Das bedeutet, dass ein Entwickler des V-Modell-basierten Prozesses die Rolle des Kunden übernimmt und dem Team beratendzur Seite steht und es in die bisher bearbeiteten Aufgaben und Entwicklungsschritteeinführt. Das Team interpretiert seine Aufgaben so, dass es für einen externen Kundenein Produkt erzeugen und die Wünsche des „Kunden“ respektieren und befolgen soll.

Ein Mittelweg zwischen den beiden Varianten bietet eine etwas weichere Lösung. Wer-den sowohl einige Entwickler des V-Modell-basierten Prozesses, als auch einige Ent-wickler, die sich bereits mit SCRUM auskennen, zusammen zu einem SCRUM Teamgeformt, so kann ein gegenseitiges Lernen stattfinden, wie es auch in SCRUM er-wünscht ist. Die eine Partei kann den Umgang mit SCRUM erlernen, während dieandere Partei leichteren Einstieg in die Struktur der bisherigen Arbeit des V-Modell-Prozesses findet. Über diesen Weg ist es möglich, ein relativ SCRUM-unerfahrenesTeam in die Entwicklung mit SCRUM einzuführen. Diese Lösung lässt sich konsequentweiterdenken, indem auch zu gegebener Zeit die andere Hälfte des ursprünglichenTeams in die Mechanismen von SCRUM eingeführt wird. Dies kann beispielsweisedurch die erste Hälfte des Teams geschehen. Dies muss zeitlich nicht zwangsweise imaktuellen Projekt geschehen, sondern kann auch langfristiger geplant und angesetztwerden. Dadurch ist es möglich, alle Mitarbeiter schrittweise an SCRUM heranzufüh-ren, sofern es bereits Mitarbeiter gibt, die mit SCRUM Erfahrungen gemacht haben.

4.2.6 Daily SCRUM Meetings

Das erste der beiden Daily SCRUM Meetings, in dem jedes Teammitglied zwei bis dreiMinuten Zeit zu sprechen hat, sollte auch im Falle einer Integration von SCRUM indas V-Modell XT unangetastet bleiben. Es ist wichtig, dass dieses Meeting seine klareStruktur beibehält, um die Prinzipien die seitens SCRUM dahinter stehen, gleicherma-ßen fortzuführen.

Sollten durch die Integration von SCRUM Fragen auftauchen, die besprochen werdenmüssten, so wäre es gut, diese Fragen im Anschluss stellen zu können. Das zweiteMeeting wird also nicht nur dafür benötigt, Aspekte der Entwicklung weiter zu erörtern,sondern auch Aspekte der Entwicklung mit SCRUM zu klären.

46


Im Folgenden werden einige Beispiele für Fragen genannt, die durch die Integrationvon SCRUM aufgeworfen werden können.

• Wie formulieren wir Aufgaben an Hand der in den Produkten gegebenen Infor-mationen?

• Wie entscheiden wir, welche Informationen des Produkts für SCRUM wichtigsind?

• Wie funktioniert das Prinzip „XY“ von SCRUM?

Sollten sich die Fragen, die sich auf SCRUM beziehen, häufen, so kann es sinnvollsein, ein eigenes, drittes Meeting anzusetzen, in dem ausschließlich Fragen erör-tert werden, die sich auf Grund der Integration ergeben. Diese Fragen müssen nichtzwangsläufig die Mechaniken von SCRUM hinterfragen, sondern können sich auch aufdie Schnittstellen zwischen dem V-Modell und SCRUM beziehen. In diesem Meetingsollten alle Fragen erlaubt sein, die sich auf die neu verursachten Probleme, Abläufeund Praktiken beziehen. Es sollten dabei, wie beim ersten Meeting, keine Architektur-oder Implementierungsdetails besprochen werden. Zudem ist es sinnvoll, das geson-derte Meeting bezüglich SCRUM noch vor dem eigentlich zweiten Meeting durchzu-führen. Insbesondere, wenn das Team noch keine großen Erfahrungen mit der Integra-tion von SCRUM gemacht hat, können mehr Teammitglieder Interesse daran haben,Integrationsmechanismen zu hinterfragen, als genauer auf einige Architektur- oder Im-plementierungsdetails einzugehen. Sie müssten im Falle des vorgezogenen Meetingsnicht lange warten, wenn sie am dritten Meeting nicht teilnehmen wollen.

Dieser Aspekt muss von Unternehmen zu Unternehmen eigenständig entschiedenwerden. Unternehmen, die sehr erfahrene Mitarbeiter im Umgang mit SCRUM haben,können ebenso überlegen, das SCRUM Meeting an das Ende der Reihenfolge zu ver-schieben, da für diese Entwickler andere Fragen wichtiger sein könnten. Es wäre auchdenkbar, dass nach jedem ersten Meeting geschaut wird, in welchem Bereich mehrFragen gestellt werden. Gemessen an der Anzahl der Fragen werden die Meetingszeitlich eingeteilt. Probleme gibt es dabei, wenn der Anteil der Zuhörer des Raums,also Kunden, Benutzer und Management, sehr hoch ist und sich die Zuhörer auf einenzuvor geplanten Zeitplan verlassen müssen. In dem Fall sollte eine klare, zuvor ge-plante Zeiteinteilung eingehalten werden. Sollte ein drittes Meeting eingeführt werden,würde diese Entscheidung auch allen Zuhörern zu Gute kommen, die Interesse daranhaben, mehr über SCRUM und die Integrationsprobleme zu lernen. Sie würden somitdie Möglichkeit bekommen, gezielt zu diesem Thema Informationen zu erhalten undsich bereits zu diesem Zeitpunkt einiges Wissen aneignen können. Außerdem bekämedas Management einen klaren Eindruck, ob die Integration von SCRUM reibungslosoder problembehaftet verläuft und ob es sich lohnt, SCRUM weiterhin integriert imV-Modell durchführen zu lassen.

4.2.7 Sprint Planning Meeting

Im Sprint Planning Meeting sind zwei separate Meetings vorgesehen. Im ersten Mee-ting trifft sich das Team mit Kunden, Management, Nutzern und dem Product Owner

47


und bespricht das weitere Vorgehen.

Nun kann es sein, dass, wie oben besprochen, kein Kunde klar definiert ist oder einKunde durch ein Teammitglied oder das Team nicht repräsentiert wird. In diesem Fallsollten die Aufgaben des Kunde während des Meetings in jeder Hinsicht auf alle Betei-ligten verteilt werden. Der SCRUM Master übernimmt an dieser Stelle die Moderationder Kundenwünsche- und Ideen, damit dieser Mechanismus beibehalten wird. Er musssomit oft Fragen stellen, was sich das Team vom anstehenden Sprint erwünscht, wasin jedem Fall erarbeitet werden soll und was vorerst vernachlässigt werden kann. Ermuss darauf achten, dass dieser Aspekt nicht zu kurz kommt. Endet das Meeting,muss sich jeder Entwickler bewusst sein, dass er für den Sprint nicht mehr die Rolledes Kunden inne hat. Andernfalls könnten die Entwickler in einen Rhythmus verfal-len, in dem sie ausschließlich das programmieren, was sie selbst für richtig und guterachten. Zwischen diesen Funktionen gedanklich umzuschalten erfordert sehr vielDisziplin.

Zum einen wird somit mehr Verantwortung auf die Schultern des Teams gelegt, da dasTeam die zusätzlichen Aufgaben als Kunde hinreichend gut ausführen muss. Dies istaber nicht unbedingt ein schlechter Aspekt, da es im eigenen Interesse des Teams ist,später ein gutes Produkt zu erzeugen, mit dem möglicherweise gut weitergearbeitetwerden soll. Zudem weiß zu einem Zeitpunkt in mitten des Projekts das Team vermut-lich am besten darüber Bescheid, was zu tun ist, wo es Schwierigkeiten geben kannund was benötigt wird, um weiter zu arbeiten.

In den meisten Fällen kann die Rolle des Nutzers ebenfalls durch das Team abgedecktwerden. Ist das Ziel des SCRUM Sprints beispielsweise die Erstellung des Grobent-wurfs, so sind die Nutzer des Grobentwurfs das Team selbst. Wird in dem Sprint al-lerdings ein Stück Software erzeugt, das später auch von anderen Personen benutztwird, als von den Entwicklern selbst, so kann es ratsam sein, spätere Nutzer bei die-sem Gespräch, ganz so, wie es SCRUM vorschlägt, dabei zu haben. In einigen Fällenist dies nicht möglich. Dennoch gibt es Mittel und Wege an dieser Stelle Feedback vonBenutzern einfließen zu lassen, indem beispielsweise Bewertungen älterer Produkteberücksichtigt werden. Dies sollte allerdings ohnehin durch das Management bereitszu früheren Zeitpunkten vorgeschlagen worden sein.

An dieser Stelle sei noch einmal erwähnt, dass das Team die Rolle des Kunden nuraus der Not heraus übernimmt und nur solange, wie das Meeting andauert. JederEntwickler muss sich bewusst sein, keine eigenmächtigen Entscheidungen zu treffen.Jede Entscheidung muss durch den Kunden getroffen werden, was somit nur im Teamgemeinsam möglich ist. Auf gar keinen Fall darf jeder Entwickler zum Kunden werden.

Im zweiten Meeting beratschlagt das Team, wie die Umsetzung des Vorgenomme-nen aussehen kann. Dies kann wie in SCRUM gewohnt funktionieren. Auch in diesemMeeting kann es ratsam sein, den Ablauf von SCRUM bezüglich der Besonderheitenvor jedem Sprint anzusprechen. Wie bei den Daily SCRUM Meetings ist dies entwederdirekt im zweiten Meeting möglich oder aber in einem dritten Meeting im Anschluss.

48


4.2.8 Sprint

Die Dauer eines Sprints beträgt in SCRUM in der Regel 30 Tage. Nach Annahme 3.3ergibt sich, dass für die Erstellung eines Produkts und somit Durchführung einer Akti-vität ein Sprint immer vollständig durchgeführt werden kann, sofern genauso viel Zeitmit SCRUM benötigt wird. Da die 30 Tage in SCRUM nicht verpflichtend angegebenwerden, soll dies an dieser Stelle auch nicht getan werden. SCRUM rät davon ab, beimerstmaligen Einsatz von SCRUM die Dauer eines Sprints zu ändern. Sollte ein Unter-nehmen Erfahrungen mit SCRUM gesammelt haben, darf allerdings auch die Dauerangepasst werden. Diese Faustregel soll hier auch zum Tragen kommen.

An den Zielen eines Sprints im integrierten SCRUM ändert sich nichts im Vergleichzu einem Sprint im ursprünglichen Sinne von SCRUM. Das wichtigste ist immer noch,die Ziele am Ende eines Sprints zu erreichen. Auch müssen die Aufgaben genausoverteilt sein, wie SCRUM dies vorgibt.

Die Anzahl der Sprints kann, abhängig von der Dauer der Erzeugung der Ausgangs-produkte, variieren. Es müssen so viele Sprints durchgeführt werden, bis alle zu er-zeugenden Produkte fertiggestellt worden sind. Dies kann sequentiell durch ein Teamoder parallel durch mehrere Teams geschehen. Dazu sollten sogenannte SCRUM ofSCRUMs benutzt werden, die in Kapitel 5.2.1 genauer diskutiert werden.

4.2.9 Sprint Review

Ebenso wie der Sprint kann das Sprint Review ebenfalls unangetastet bleiben. DasErgebnis eines Sprints kann hierbei fertige oder unfertige Teile eines Produkts oder einProdukt als Ganzes sein. Außerdem können auch Zwischenergebnisse das Ergebniseines Sprints sein, die einen weiteren Sprint nach sich ziehen würden, um ein Produktfertig zu stellen.

Durch die Präsentation des Produkts dem Kunden gegenüber können Schwachstel-len des Produkts besser identifiziert werden. Wenn das Team allerdings selber dieWünsche des Kunden vertritt, ist es schwer, diese Schwachstellen durch die Präsen-tation untereinander zu erkennen. In diesem Fall ist es wichtig, die Eigenschaften desProdukts besonders kritisch zu hinterfragen. Ebenso müssen die Teammitglieder ankniffligen Situationen, die während des Sprints entstanden sind, einhaken, um dortmögliche Schwachstellen zu identifizieren. Dieses Vorgehen erfordert ein hohes Maßan Selbstdisziplin, da das Team möglicherweise Probleme, die während des Sprintsentstanden sind, nicht mehr aufgreifen möchte, um schnell zum nächsten Schritt vor-anzuschreiten. Außerdem ist es nicht selbstverständlich, dass jede Person mit der Kri-tik an seiner eigenen Leistung gut umgehen kann, insbesondere, wenn die Kritik vomeigenen Kollegen kommt. Kritik, die vom Kunden geäußert wird, kann in der Regelleichter akzeptiert werden. Auf diese negative Dynamik muss Acht gegeben werden.Im Zweifelsfall steht der SCRUM Master in der Verantwortung, kritische Punkte selbstanzusprechen, falls das Team diese nicht von alleine anspricht, um so eine Diskussionzu starten.

49


Das Sprint Review kann dafür genutzt werden, Vor- und Nachteile, die durch die Inte-gration von SCRUM entstanden sind, aufzugreifen. Dadurch kann ersichtlich werden,welche Aspekte verbessert und welche fortgesetzt oder abgeschafft werden müssen.Auch hier gilt wieder, dass ein Unternehmen, welches bereits viele Erfahrungen mit derIntegration von SCRUM in das V-Modell gemacht hat, auch hier auf eine gesonderteBetrachtung der Integration verzichten kann.

4.3 Vor- und Nachteile der Integration

Durch die Tatsache, dass SCRUM in das V-Modell integriert werden soll, entsteheneinige Vor- und Nachteile im Vergleich zu anderen, „normalen“ SCRUM Projekten oderV-Modell-Projekten. Einige dieser Vor- und Nachteile sollen hier aufgezählt werden.

4.3.1 Vorteile

Die allgemeine Bedingung, dass alle nach dem Tailoring übrig gebliebenen Produkteerzeugt werden müssen, wird in einem Projekt mit V-Modell und integriertem SCRUMaußer Kraft gesetzt. Wird ein Bereich mit SCRUM durchgeführt, müssen nicht alleProdukte, die vom V-Modell in diesem Bereich gefordert werden, erzeugt werden. Jenach Einsatz von SCRUM können Produkte und somit Zeit eingespart werden. Durchdie Reduktion der Anzahl der Produkte steigt auch die Flexibilität. Späte Änderungenkönnen leichter eingearbeitet werden, da weniger Produkte geändert werden müssen.

In der Regel hat sich das Team bereits vorher mit dem Projekt und den Aufgabenwährend des V-Modell-basierten Prozesses beschäftigt. Startet nun SCRUM, so sindeinige Vorkenntnisse und Vorwissen bereits vorhanden. Das Team muss nicht mehrvon Grund auf neu anfangen, sondern startet mit SCRUM in ein bekanntes Projekt.Dies bietet den Vorteil, dass sich insbesondere SCRUM-unerfahrene Entwickler leich-ter mit den Praktiken und Mechanismen von SCRUM vertraut machen können, da siebereits Zeit hatten, sich mit der Domäne oder neuen Technologien vertraut zu machen.

4.3.2 Nachteile

In besonders kritischen Projekten kann es möglich sein, dass die Einsparung vonProdukten in manchen Fällen zu rechtlichen Problemen führen kann. Entsteht einSchaden, steht das Unternehmen, welches das Endprodukt angefertigt hat, unter demZwang nachzuweisen, dass die Entwicklung korrekt abgelaufen und das Produkt sogut wie möglich fertiggestellt worden ist. In diesem Fall kann es sein, dass die Produk-te, die durch den Einsatz von SCRUM eingespart werden konnten, nachdokumentiertwerden müssen, um diese Sicherheit zu bieten.

Je nach Startpunkt von SCRUM kann die Anzahl der Produkte, deren Informationenin das Product Backlog übernommen werden müssen, sehr groß sein. Somit wird vor

50


dem Start von SCRUM sehr viel Zeit benötigt, diese Informationen in das ProductBacklog zu übernehmen.

Tabelle 4.1 gibt eine grobe Übersicht über die Vor- und Nachteile der Integration vonSCRUM in das V-Modell XT.

Vorteile Nachteile

Zeitersparnis Geringere Sicherheit

Flexibilitätsgewinn Erhöhter Aufbereitungsaufwand

Tabelle 4.1: Grobe Übersicht über Vor- und Nachteile der Integration von SCRUM indas V-Modell XT

4.4 Probleme bei der Integration von SCRUM

Probleme bei der Gewinnung von Informationen aus den Produkten können in der Grö-ße des Produkts liegen. Es ist sehr schwierig, gezielt Informationen in großen Produk-ten zu finden. Dies ist ein allgemeines Problem, mit dem sich das V-Modell prinzipiellauseinander setzen muss. Da die Produkte des V-Modells als Eingabe für SCRUMdienen, wird dieses Problem auch zu einem Problem für SCRUM. Hier entsteht einVorteil, wenn das Team aus Entwicklern besteht, die die Produkte des V-Modells zuvorselbst geschrieben haben. Zum einen wissen diese Entwickler selbst am Besten, anwelcher Stelle welche Information im Produkt zu finden ist. Zum anderen können sieschon im Vorfeld die Verantwortung übernehmen, eine klare und übersichtliche Struk-tur für das Dokument zu schaffen. Gegebenenfalls kann bereits in den Schritten desV-Modells darauf geachtet werden, Informationen zu klassifizieren um somit ein leich-teres Wiederfinden zu ermöglichen. Zum einen kann dies direkt im Dokument gesche-hen, indem Stellen, die für eine Weiterverarbeitung in Frage kommen, gekennzeichnetwerden. Zum anderen könnte ein zweites Dokument geführt werden, welches dieseStellen festhält. In diesem Fall könnte es möglich sein, die Mitführung dieses Doku-ments zu automatisieren, um Zeit zu sparen. Die Klassifizierung könnte zum Beispielim Falle von Anforderungen zwischen funktionalen und nicht funktionalen Anforderun-gen unterscheiden und festhalten, an welcher Stelle welche Anforderungen aufgelistetwerden, sofern diese Unterscheidung nicht schon im Produkt selbst vollzogen wird.Wird sich an die Vorlagen des V-Modells gehalten, wird diese Unterscheidung bereitsdurchgeführt.

Die Übernahme von Informationen aus Produkten zu User Stories kann im Falle vongroßen Produkten sehr zeitintensiv sein. Dabei kann es möglich sein, dass die erhoffteZeitersparnis durchaus geringer ausfällt. Auf der anderen Seite muss auch das V-Modell die Informationen aus Produkten filtern, um neue Produkte zu erstellen.

Für die Übernahme der Informationen kann es mehrere Möglichkeiten geben (verglei-che Abbildung 4.7). Die erste Möglichkeit besteht darin, das gesamte Team zu Beginn

51


von SCRUM an der Übernahme arbeiten zu lassen, bis alle Eingangsprodukte bear-beitet wurden und alle nötigen Anforderungen in das Product Backlog übernommenwurden. Dadurch verzögert sich der Start des ersten Sprints. Allerdings liegen danachalle Anforderungen vor und der oder die Sprints können normal durchgeführt werden,ohne dass vor jedem Sprint Anforderungen aus dem Produkt gewonnen werden müs-sen. Dadurch ist es prinzipiell ausgeschlossen, dass Überraschungen während derÜbernahme von Anforderungen auftreten können, weil das Produkt nicht vollständiggelesen wurde. Alle Anforderungen sind klar verarbeitet und das Gesamtbild der An-forderungen ist bekannt.

Abbildung 4.7: Möglichkeiten zur Übernahme von Informationen in das ProductBacklog

Denkbar ist auch, dass das Team solange Anforderungen aus den Produkten her-leitet, bis ausreichend viele Anforderungen für den ersten Sprint vorliegen. Dadurchkann das Team früh erste Ergebnisse erzielen und bereits Erfahrungen in der Erstel-lung des zu erzeugenden Produkts sammeln. Das Bild wird für das Team klarer unddie Erstellung weiterer Anforderungen kann leichter fallen. Möglicherweise fließen Ver-besserungsideen bereits in der späteren Erstellung von Anforderungen ein. Allerdingsist es auch möglich, dass wichtige Anforderungen zu spät zum Vorschein kommen undbereits erledigte Arbeit rückgängig gemacht werden muss.

Bei dieser Möglichkeit gibt es für die weitere Herleitung der Anforderungen wiederum

52


zwei Möglichkeiten. Zum einen kann das Team nach Abschluss eines Sprints an derHerleitung weiterer Anforderungen mitwirken. Damit würde der Ablauf von SCRUM ineinem Wechsel zwischen Herleitung von Anforderungen und Sprint vollzogen werden.Hier würde sich die Zeitspanne zwischen zwei Sprints vergrößern, allerdings ist dasTeam über die selbst hergeleiteten Anforderungen gut informiert.

Die zweite Möglichkeit besteht darin, eine eigene Rolle für die Herleitung von Anfor-derungen zu definieren. Die Person, die der Rolle zugewiesen wird, nutzt die Zeit derSprints, um die restlichen Anforderungen aus den Produkten zu gewinnen. Da diePerson, wie schon erwähnt, ein Experte für das zu erzeugende Produkt sein muss,muss genau dieser Experte der Rolle zugewiesen werden. Gibt es nur einen Expertenim Team, ist der Experte somit erst nach der kompletten Herleitung der Anforderun-gen an der Erstellung des Produkts beteiligt. Somit geht seine Erfahrung in Bezug aufdie Erstellung vorerst verloren. Außerdem können die weiteren Anforderungen für dasTeam unklar sein, wenn sie diese zum ersten Mal sehen, wodurch Klärungsbedarf be-stehen kann. Die neu definierte Rolle muss also weiterhin die Aufgabe erfüllen, beiFragen bezüglich der Anforderungen beratend zur Seite zu stehen, um diese Fragenzu klären.

Sofern noch nicht genügend Anforderungen vorliegen, um den ersten Sprint zu star-ten, sollte das gesamte Team an der Herleitung der Anforderungen arbeiten, um Leer-zyklen einzelner Mitarbeiter zu vermeiden. Außerdem bekommt so das gesamte Teamein Gefühl für die Aufgaben, die zu erledigen sind. Auf jeden Fall sollte aber der Ex-perte an der Herleitung der Anforderungen mitwirken. Ist nur ein einziger Sprint ange-dacht, muss das Team alle Anforderungen vor diesem Sprint herleiten, um auch alleAnforderungen in diesem Sprint umzusetzen.

53

5 Integrationsvarianten von SCRUM in dasV-Modell XT

In Kapitel 3 wurden die Informationsflüsse im V-Modell und die Informationsfluss-Schnittstellen von SCRUM beschrieben, um mögliche Integrationspunkte zu finden.In Kapitel 4 wurde beschrieben, wie die Integration von SCRUM genau aussehen sollund welche Anpassungen vorgenommen werden müssen. In diesem Kapitel wird nundie Frage geklärt, an welchen Stellen im Informationsfluss eine Integration möglichund sinnvoll ist.

Die Integration von SCRUM ist nicht an allen Stellen sinnvoll, auch wenn es prinzipiellmöglich ist, jedes beliebige Produkt, wie in Kapitel 4.2 beschrieben, in das ProductBacklog zu überführen und SCRUM so anzupassen, dass mit diesem Produkt als Ein-gabe gearbeitet werden kann. Allerdings wird SCRUM in der Regel in Bereichen derSystementwicklung eingesetzt. Daher wäre es unüblich, SCRUM für die Projektpla-nungsphase im V-Modell einzusetzen, um ausschließlich Dokumente mit SCRUM zuerzeugen, nur um die Systementwicklung anschließend ohne SCRUM durchzuführen.

Um dies konkret zu benennen, wird Abbildung 5.1 herangezogen, welche die Entschei-dungspunkte des V-Modells darstellt. Üblicherweise soll die Integration von SCRUMbei den Entscheidungspunkten geschehen, die ganz oder teilweise Bestandteil des„V“s sind. Die Integration von SCRUM wird in der Regel nicht ausschließlich zwischendem ersten und dem letzten Entscheidungspunkt des „V“s stattfinden, sondern ist auchzwischen anderen Entscheidungspunkten innerhalb der Systementwicklung denkbar.Einig sinnvolle Varianten werden in Kapitel 5.1 vorgestellt.

Abbildung 5.1: Übersicht über alle im V-Modell XT vorgesehenen Entscheidungspunk-te [vmo]

In Kapitel 4.1 wurde erklärt, wie SCRUM in einen Informationsfluss des V-Modells inte-

54

5 Integrationsvarianten von SCRUM in das V-Modell XT

griert werden kann und was, abhängig von der vorliegenden Situation, zu berücksichti-gen ist. Diese Integration berücksichtigt ausschließlich die Informationsflüsse, also dieProduktabhängigkeiten des V-Modells. In Kapitel 5.1 soll nun geklärt werden, welcheAspekte zusätzlich zu beachten sind, um SCRUM konkret in den Gesamtablauf des V-Modells möglichst reibungslos einzubinden. In Kapitel 5.2 werden anschließend einigeallgemeine Variationen angegeben, die sich auf die Integration von SCRUM beziehenund nicht auf Entscheidungspunkten basieren.

5.1 Integrationsvarianten auf Basis vonEntscheidungspunkten

In diesem Kapitel werden unterschiedliche Integrationsvarianten vorgestellt, in denenmögliche Bereiche beschrieben werden, die für die Integration von SCRUM in dasV-Modell XT sinnvoll sind. Diese Bereiche müssen gewisse Kriterien erfüllen, um alsgeeignet angesehen werden zu können. Ein Bereich, der sich für die Integration vonSCRUM eignet, muss sowohl zeitlich, als auch inhaltlich sinnvoll abgegrenzt sein, umeine konsistente Zusammenfassung einzelner Teile zu bieten und somit eine sinnvolleIntegration zu ermöglichen.

Definition 5.1

Ein Bereich ist zeitlich sinnvoll abgegrenzt, wenn alle Aufgaben, die in diesemBereich anfallen, in angemessener Zeit abgeschlossen werden können.

Definition 5.2

Ein Bereich ist inhaltlich sinnvoll abgegrenzt, wenn alle Aufgaben, die in diesemBereich anfallen, auf das gleiche, übergeordnete Ziel zuarbeiten.

Beide Definitionen lassen absichtlich viel Spielraum, da die Frage, ob eine Zeitspanneangemessen ist, von Unternehmen zu Unternehmen unterschiedlich ist. Die Entwick-lung der Software für ein Flugzeug kann beispielsweise deutlich länger dauern, als dieEntwicklung einer neuen Jahresversion eines Antivirenprogramms. Bereiche, die imersten Fall angemessen sind, können unter Umständen die gesamte Projektdauer desAntivirenprogramms überschreiten.

Dennoch bietet das V-Modell XT ein Mittel der Projektfortschrittskontrolle an, wel-ches die Forderung erfüllt: die Entscheidungspunkte. Die Entscheidungspunkte wur-den durch das V-Modell so definiert, dass sie zeitlich und auch inhaltlich sinnvoll abge-grenzt sind. Alle Aufgaben, die zwischen zwei Entscheidungspunkten anfallen, dienendazu, in möglichst kurzer Zeit ein vorgegebenes Ziel zu erreichen und die Weiterarbeitnach Erreichen dieses Ziel zu ermöglichen. Entscheidungspunkte müssen so gewähltwerden, dass die Zeit bis zum Erreichen und Überschreiten des Entscheidungspunktsangemessen ist. Die Aufgaben, die zwischen zwei Entscheidungspunkten anfallen,dienen dazu, das Ziel des Entscheidungspunkts zu erreichen. Somit bieten sich dieEntscheidungspunkte als Abgrenzung für die Bereiche des V-Modells an.

55


Nun wird der Informationsfluss des V-Modells, dessen Herleitung in Kapitel 3.4 be-schrieben wird, zusammen mit den Entscheidungspunkten des V-Modells betrachtet.In Abbildung 5.2 werden die Entscheidungspunkte für ein AG/AN-Projekt mit Entwick-lung, Weiterentwicklung oder Migration, die für die Systementwicklung eine Rolle spie-len, in Kombination mit den Informationsflüssen der Produkte dargestellt. Zur Verein-fachung werden nur die Produkte, Entscheidungspunkte und Informationsflüsse ein-gezeichnet und die Aktivitäten und Rollen an dieser Stelle nicht betrachtet. Zum einenwerden die Produkte von anderen Produkten erzeugt, zum anderen werden die Pro-dukte von Entscheidungspunkten gefordert. Die Abbildung beschränkt sich vereinfa-chend auf die reine Entwicklung von Software ohne Hardware und ohne Unterstüt-zungssystem oder Externe Produkte.

Abbildung 5.2: Entscheidungspunkte für ein AG/AN-Projekt mit Entwicklung, Weiter-entwicklung oder Migration, sowie die von ihnen geforderten Produkteinklusive vereinfachtem Informationsfluss

Produkte, die in der Abbildung blau umrandet sind, sind Produkte, die von Entschei-dungspunkten explizit gefordert werden. Produkte, die in der Abbildung schwarz um-randet sind, sind Produkte, die von keinen Entscheidungspunkten gefordert werden,aber dennoch von geforderten Produkten erzeugt werden.

Die Produkte „System“, „Segment“, „SW-Einheit“, „SW-Komponente“ und „SW-Modul“hängen hierarchisch voneinander ab. Ein System besteht aus einem oder mehre-

56


ren Segmenten, welche wiederum aus einem oder mehreren SW-Einheiten bestehen.Dies geht bis zum SW-Modul, welches das hierarchisch tiefste Stück Software dar-stellt. Aus V-Modell-Sicht fließen Informationen in die SW-Module und SW-Komponen-ten. Somit fließen indirekt auch Informationen in die SW-Einheit, Segmente und dasSystem. Um diese Tatsache zu visualisieren, wird in der Abbildung die hierarchischeBeziehung der Produkte mit UML dargestellt.

Das Produkt „Prüfspezifikation Systemelement“ ist auf der linken Seite eingezeichnet.Dies soll symbolisieren, dass es gleichermaßen von den drei Entscheidungspunkten„System spezifiziert“, „System entworfen“ und „Feinentwurf abgeschlossen“ gefordertwird. Analog ist das Produkt „Prüfprotokoll Systemelement“ auf der rechten Seite ein-gezeichnet, da es von den Entscheidungspunkten „Lieferung durchgeführt“, „Systemintegriert“ und „Systemelemente realisiert‘“ gefordert wird.

Die Produkte „Projektfortschrittsentscheidung“, „Projektplan“, „Projektstatusbericht“und „QS-Bericht“ werden in ausnahmslos allen in dieser Abbildung abgebildeten Ent-scheidungspunkten gefordert. Mit Ausnahme des Projektplans, welcher keine in derAbbildung aufgelisteten Produkte erzeugt, erzeugen sie keine weiteren Produkte desV-Modells. Zudem werden sie von Entscheidungspunkten gefordert, die vor den in derAbbildung dargestellten Entscheidungspunkten liegen und müssen somit schon zu ei-ner früheren Phase des Projekts erstellt werden. Daher können sie in dieser Abbildungvernachlässigt werden.

In der Abbildung wurden zwei Namen von Produkten auf Grund ihrer Länge abgekürzt.Die Abkürzung „IIPS“ steht für das Produkt „Implementierungs-, Integrations- und Prüf-konzept System“ und die Abkürzung „IIPSW“ steht für das Produkt „Implementierungs-, Integrations- und Prüfkonzept SW“.

Des weiteren ist zu beachten, dass die Produkte “QS-Handbuch“ und „Projekthand-buch“ schon von einem früheren Entscheidungspunkt gefordert werden und daherschon zuvor erstellt worden sind. Deswegen werden in der Abbildung nur Produktebetrachtet, die von den abgebildeten Entscheidungspunkten gefordert werden.

Bevor nun konkret angegeben werden kann, welche Bereiche mit SCRUM durchge-führt werden, wird zuerst die folgende Annahme getroffen.

Annahme 5.1

Die Durchführung von SCRUM soll immer zwischen ganzen Entscheidungspunktendurchgeführt werden.

Endet SCRUM zwischen zwei Entscheidungspunkten, ohne alle Produkte des nach-folgenden Entscheidungspunktes zu erstellen, so müssen die restlichen Produkte überdie V-Modell-basierte Methode erstellt werden, damit der nachfolgende Entscheidungs-punkt passiert werden kann. Werden diese Produkte nicht erzeugt, kann auch der Ent-scheidungspunkt laut V-Modell nicht passiert werden. Werden allerdings alle Produkteerzeugt, die von dem nachfolgenden Entscheidungspunkt gefordert würden, soferndie Entwicklung V-Modell-basiert ablaufen würde, so könnte der Entscheidungspunktpassiert werden. Daher ist es sinnvoll, SCRUM immer bei beziehungsweise kurz nachoder vor einem Entscheidungspunkt enden zu lassen. Dies wird in Kapitel 5.2.2 aus-

57


führlicher diskutiert.

Beginnt SCRUM zwischen zwei Entscheidungspunkten, so ist es möglich, dass Pro-dukte bereits auf V-Modell-basierte Art erstellt worden sind. Diese Vorgehensweise istprinzipiell möglich, da diese Produkte als Eingabe für SCRUM dienen können, soferndies gefordert wird. Der Nachteil in dieser Methode besteht darin, dass durch das V-Modell Einschränkungen an die Reihenfolge der Erstellung von Produkten gestellt wer-den. So könnte beispielsweise die Systemspezifikation nicht erstellt werden, solangees keine Systemarchitektur gibt. In SCRUM wäre es denkbar, die Systemarchitekturnicht als Dokument fertigzustellen und direkt zur Systemspezifikation überzugehen.Daher ist es sinnvoll, SCRUM direkt nach Entscheidungspunkten beginnen zu lassen.Genauere Überlegungen in diese Richtung werden in Kapitel 5.2.4 angestellt.

Aus Abbildung 5.2 lassen sich nun einzelne Integrationsvarianten für die Integrati-on von SCRUM gewinnen, welche unterschiedliche Bereiche beschreiben, die mitSCRUM durchgeführt werden sollen. Dabei wird in den Kapiteln 5.1.1 bis 5.1.4 fürjede Variante angegeben, wann sie eingesetzt werden sollte und welche Konsequen-zen dies hat.

Der Bereich, der mit SCRUM durchgeführt werden soll, wird dabei mit einem rotenRahmen gekennzeichnet. Abbildung 5.3 zeigt ein Beispiel für einen solchen Rahmen.Jede Variante beginnt direkt nach einem Entscheidungspunkt und endet unmittelbarvor oder nach einem der folgenden Entscheidungspunkte. In der Abbildung 5.3 istEntscheidungspunkt „B“ der erste Entscheidungspunkt des Bereichs. Somit beginntSCRUM direkt nachdem Entscheidungspunkt „A“ überschritten wurde. SCRUM endetkurz vor oder nach Entscheidungspunkt „C“ (vergleiche Kapitel 5.2.2). Das bedeutet,dass alle Produkte, die in Entscheidungspunkt „C“ gefordert werden, mit SCRUM er-stellt werden müssen.

Abbildung 5.3: Kennzeichnung des mit SCRUM durchzuführenden Bereichs

5.1.1 Variante 1: SCRUM für Systementwicklung

Die erste Variante für die Integration von SCRUM besteht darin, SCRUM für die Sys-tementwicklung einzusetzen. Es soll also das gesamte System mit SCRUM entwickeltwerden. Dies umfasst den Entwurf, die Realisierung und die Integration des Systems.

In Abbildung 5.4 sind die Entscheidungspunkte und Produkte rot markiert, dessen Auf-

58


gaben mit SCRUM durchgeführt werden sollen. Die Produkte „SW-Komponente“ und„SW-Modul“ werden nicht von Entscheidungspunkten gefordert, sind aber dennoch imroten Bereich enthalten. Dies liegt daran, die Erstellung der SW-Einheiten und somitder Segmente und des Systems ohne die beiden Produkte wenig sinnvoll wäre.

SCRUM startet direkt nach dem Entscheidungspunkt „System spezifiziert“. Es sindalso bereits das Pflichtenheft, sowie die Produkte „Prüfspezifikation Dokument“ und„Prüfspezifikation Systemelement“ vorhanden. Alle eingehenden Flüsse in die SCRUM-Integrations-Aktivität, kommen vom Pflichtenheft. Daher werden die Informationen desPflichtenhefts in das Product Backlog übernommen. Weitere Informationen von ande-ren Produkten müssen nicht in das Product Backlog übernommen werden.

Abbildung 5.4: Durch die erste Variante markierter Bereich in einem AG/AN-Projektmit Entwicklung, Weiterentwicklung oder Migration

Mit SCRUM sollen die Produkte System und Segment erstellt werden. Daher sind die-se das Ergebnis von SCRUM. Allerdings müssen nach Kapitel 4.1 alle Produkte erstelltwerden, die nach V-Modell von Produkten erzeugt worden wären, welche innerhalbdes Bereichs liegen, welcher nun mit SCRUM durchgeführt wird. Dies betrifft die Pro-dukte „Prüfspezifikation Systemelement“, „Make-or-Buy Entscheidung“, „PrüfprozedurSystemelement“ und „Prüfprotokoll Systemelement“.

Das Ziel ist es, das gesamte System mit SCRUM zu erzeugen, wozu auch die Durch-führung der Tests gehört. Aus diesem Grund sollte die Auswahl des Bereichs erweitert

59


werden. Die rote, gestrichelte Linie in Abbildung 5.4 markiert die erweiterte Auswahl.Die Produkte „Prüfspezifikation Systemelement“ und „Prüfprozedur Systemelement“wurden in den erweiterten Bereich aufgenommen. Dadurch müssen Informationen ausdem Produkt „Projekthandbuch“ ebenfalls in das Product Backlog fließen. Die Make-or-Buy Entscheidung muss in dieser Variante erzeugt werden. Allerdings wäre es auchdenkbar, diese in den Bereich mit aufzunehmen, da sie keine weiteren Produkte er-zeugt und auch von keinem Entscheidungspunkt gefordert wird.

Das Produkt „Prüfprotokoll Systemelement“ wird in folgenden Entscheidungspunktengefordert und muss daher auf jeden Fall erzeugt werden, auch wenn es in den erwei-terten Bereich mit aufgenommen werden würde.

Abbildung 5.5 zeigt die Informationsflüsse nach der Integration von SCRUM. Dieschwarz dargestellten Produkte sind die Produkte, die als Ziel erstellt werden müs-sen. Die blau dargestellten Produkte müssen zusätzlich auf Grund der Charakteristikdes V-Modells erstellt werden.

Abbildung 5.5: Aus Abbildung 5.4 resultierende Informationsflüsse nach der Integrati-on von SCRUM

Durch den Vergleich der Abbildungen 5.4 und 5.5 wird ersichtlich, dass die Produk-te „Implementierungs-, Integrations- und Prüfkonzept System“, „Systemarchitektur“,

60


„Systemspezifikation“, „Prüfprozedur Systemelement“, „Implementierungs-, Integra-tions- und Prüfkonzept SW“, „SW-Architektur“, „SW-Spezifikation“, „SW-Einheit“, „SW-Komponente“ und „SW-Modul“, also zehn an der Zahl, eingespart werden können.Zudem kann die Änderung des Produkts „Prüfspezifikation Systemelement“ gespartwerden.

Vorteile

Diese Variante bietet den Vorteil viel Zeit einsparen zu können, indem viele Produk-te eingespart werden können. Die vom V-Modell geforderten Produkte (speziell dieDokumentation dieser) ist sehr zeitaufwendig und wird somit durch SCRUM gespart.Außerdem können die bereits genannten Vorteile von SCRUM in Bezug auf die Syste-mentwicklung zu einem hohen Anteil genutzt werden, da in dieser Variante ein hoherProzentsatz der Systementwicklung mit SCRUM durchgeführt wird. Besonders zu er-wähnen ist die hohe Flexibilität dieser Variante. Auf späte Änderungen im Pflichtenheftoder von anderer Stelle kann leicht und schnell reagiert werden und führt lediglich,wenn überhaupt, zu geringen Problemen.

Als Eingabe für das Product Backlog dient in dieser Variante nur das Pflichtenheft. Esmüssen also nur die Informationen des Pflichtenhefts in das Product Backlog über-nommen werden. Je nach Größe des Pflichtenhefts kann dies kürzer oder länger dau-ern.

Nachteile

Allerdings besitzt diese Variante auch Nachteile. In einigen Fällen, beispielsweise wenndas Leben von Anwendern betroffen sein kann, wie zum Beispiel in der Luftfahrt undAutomobilindustrie, müssen Dokumente angefertigt werden, um im Falle des Versa-gens eines Endprodukts nachweisen zu können, dass die Systementwicklung fehler-frei vorgenommen wurde. Dieser Nachweis geschieht über formale Dokumente, alsoProdukte, die vom V-Modell gefordert werden. In solchen Fällen müssen einige Pro-dukte nach Abschluss von SCRUM nachdokumentiert oder während der Durchführungvon SCRUM erzeugt werden, sofern die Dokumente, die mit SCRUM erzeugt werden,nicht als ausreichende, rechtliche Grundlage betrachtet werden können. Dies ist aller-dings ein allgemeiner Kritikpunkt an SCRUM, welcher nicht durch die Integration vonSCRUM zum Tragen kommt. Dennoch wird er umso höher bewertet, je mehr Bereichemit SCRUM durchgeführt werden.

5.1.2 Variante 2: SCRUM für Komponentenentwicklung

Die zweite Variante ähnelt der ersten Variante mit der Ausnahme, dass nun nicht dasgesamte System, sondern lediglich SW-Einheiten mit SCRUM erstellt werden sollen.Dies umfasst in diesem Fall den Feinentwurf und die Realisierung der Systemelemen-te.

61


In Abbildung 5.6 sind wieder die Entscheidungspunkte und Produkte rot umrandet,dessen Aufgaben mit SCRUM durchgeführt werden sollen. SCRUM beginnt unmittel-bar nach dem Entscheidungspunkt „System entworfen“. Das bedeutet, dass die Pro-dukte „Implementierungs-, Integrations- und Prüfkonzept System“, „Systemarchitektur“und Systemspezifikation vorhanden sind. Da die ersten beiden Produkte Produkte er-stellen würden, die sich im ausgewählten Bereich befinden, werden ihre Informationenin das Product Backlog übernommen.

Abbildung 5.6: Durch die zweite Variante markierter Bereich in einem AG/AN-Projektmit Entwicklung, Weiterentwicklung oder Migration

Das Ziel von SCRUM ist in dieser Variante die Erstellung der SW-Einheiten. Die-se sind also Ausgabe von SCRUM. Erneut müssen weitere Produkte erstellt oderverändert werden, die von nun wegfallenden Produkten im V-Modell erstellt wordenwären. Namentlich sind dies die Produkte „Prüfspezifikation Systemelement“, „SW-Komponente“, „SW-Modul“, „Prüfprozedur Systemelement“, „Make-or-Buy Entschei-dung“ und „Prüfprotokoll Systemelement „.

Die „Prüfspezifikation Systemelement“ wird in den erweiterten Bereich – gekennzeich-net durch die rote, gestrichelte Linie – aufgenommen, da auch in dieser Variante dieSW-Einheit mit SCRUM getestet werden soll. Dies hat wiederum zur Folge, dass In-formationen aus dem Projekthandbuch in das Product Backlog aufgenommen werdenmüssen.

62


Allerdings muss das Produkt „Prüfprotokoll Systemelement“ erstellt werden, da diesesin später folgenden Entscheidungspunkten gefordert wird.

Die Informationsflüsse nach der Integration von SCRUM werden in Abbildung 5.7 dar-gestellt.

Abbildung 5.7: Aus Abbildung 5.6 resultierende Informationsflüsse nach der Integrati-on von SCRUM

Auch hier wird durch einen Vergleich der Abbildungen 5.6 und 5.7 deutlich, dass dieProdukte „Implementierungs-, Integrations- und Prüfkonzept SW“, „SW-Architektur“,„SW-Spezifikation“, „SW-Komponente“ und „SW-Modul“ eingespart werden konnten.Im Gegensatz zur ersten Variante sind dies allerdings nur noch fünf Produkte. Wie inVariante 1 kann auch die Änderung des Produkts „Prüfspezifikation Systemelement“gespart werden.

Vor- und Nachteile

Die Vor- und Nachteile dieser Variante sind analog zur ersten Variante aufzulisten. Dain dieser Variante der SCRUM-Anteil nicht ganz so hoch ist, sind folglich sowohl dieVor- als auch die Nachteile nicht so groß.

Die Zeitersparnis durch das Einsparen von Produkten des V-Modells fällt nicht so hochaus, wie bei der ersten Variante, da weniger Bereiche mit SCRUM durchgeführt wer-

63


den und somit weniger Produkte eingespart werden können. Das Product Backlogist auf Informationen aus den beiden Produkten „Systemarchitektur“ und „Implemen-tierungs-, Integrations- und Prüfkonzept System“ angewiesen. Die Gewinnung dieserInformationen kann recht schnell von statten gehen, was allerdings von ihrer Größeabhängt. Prinzipiell fallen die relevanten Informationen dieser Produkte und die Pro-duktgröße insgesamt aber geringer aus, als die Größe des Pflichtenhefts, wodurch dieZeit für die Übernahme von Informationen aus Produkten im Vergleich zur ersten Vari-ante geringer ausfällt. Die Flexibilität sinkt ebenfalls, da bereits einige Entscheidungenim Vorfeld getroffen wurden. Diese Entscheidungen zu ändern oder rückgängig zu ma-chen kostet verhältnismäßig viel Zeit und Geld.

Auf der anderen Seite ist die Sicherheit aus rechtlicher Sicht höher, da mehr Produktegemäß V-Modell, wie in Variante 1 erwähnt, erstellt werden müssen. Der Anteil derNachdokumentation kann somit geringer ausfallen.

5.1.3 Variante 3: SCRUM für Entwurf

In der dritten Variante wird SCRUM nur für die Entwicklung des Entwurfs verwendet.Die Realisierung, Integration und Tests werden anschließend gemäß V-Modell durch-geführt. Es wird sich später zeigen, dass durch die in Kapitel 4.1 getroffenen Entschei-dungen diese Variante für die Anwendung nicht zu gebrauchen ist, da die Produkte,die im Entwurf angefertigt werden, fast alle direkt mit den zu realisierenden Produktender nachfolgenden Entscheidungspunkte zusammenhängen.

Die rote Markierung in Abbildung 5.8 kennzeichnet den Bereich, der mit SCRUMdurchgeführt werden soll. Der Bereich beginnt, wie in Variante 1, unmittelbar nachÜberschreiten des Entscheidungspunkts „System spezifiziert“. Es sind die Produk-te „Prüfspezifikation Dokument“ und „Prüfspezifikation Systemelement“, sowie dasPflichtenheft vorhanden, dessen Informationen mit der Begründung aus Variante 1in das Product Backlog fließen.

Das Ziel von SCRUM ist die Erstellung der Produkte „Implementierungs-, Integrations-und Prüfkonzept SW“, „SW-Architektur“ und „SW-Spezifikation“, mit deren Hilfe spä-ter das System realisiert werden soll. Diese Produkte sind somit das Erzeugnis vonSCRUM.

Nun verdeutlicht Abbildung 5.8 allerdings, dass viele später zu erzeugende Produk-te von den Produkten „Systemarchitektur“ und „Implementierungs-, Integrations- undPrüfkonzept System“ abhängen. Gemäß Kapitel 4.1 müssen diese Produkte somit alleerzeugt werden. Allerdings werden diese Produkte erst in viel später folgenden Ent-scheidungspunkten benötigt. Würden die Produkte „Segment“ und „SW-Einheit“ be-reits zu diesem Zeitpunkt erzeugt, würde dies auch bedeuten, dass die Produkte „SW-Komponente“ und „SW-Modul“ jetzt erzeugt werden sollten, da sie Bestandteile derSW-Einheit sind. Somit würde den folgenden Arbeitsschritten des V-Modells sehr weitvoraus gegriffen und sogar kurzfristig ein Entscheidungspunkt übersprungen werden,um das Produkt „Segment“ zu erzeugen. Auf jeden Fall wäre eine Systemrealisierungdie Folge, welche eigentlich noch nicht vorgenommen werden sollte.

64


Abbildung 5.8: Durch die dritte Variante markierter Bereich in einem AG/AN-Projektmit Entwicklung, Weiterentwicklung oder Migration

Um dieses Problem zu lösen, könnte außerhalb der in Kapitel 4.1 gemachten Aus-sagen, die Produkte „Systemarchitektur“ und „Implementierungs-, Integrations- undPrüfkonzept System“ erzeugt werden. Allerdings würde zum einen die Prüfung derProdukte durch einen Entscheidungspunkt, und somit durch ein Gremium, fehlen. Zumanderen wären somit die Vorteile im Vergleich zum V-Modell-basierten Prozess gering.Es wäre daher sinnvoll, den Entwurf mit dem V-Modell zu erstellen, sofern die Real-sierung, Integration und Tests auch mit dem V-Modell durchgeführt werden sollen.

5.1.4 Variante 4: SCRUM für Realisierung, Integration und Test

In der vierten Variante wird SCRUM für die Realisierung, Integration und Durchführungvon Tests eingesetzt. Der Entwurf wurde bereits gemäß V-Modell erstellt und nun solldas System bis zur Lieferung erstellt und getestet werden.

Abbildung 5.9 stellt den ausgewählten Bereich in einer roten Markierung dar. Der Be-reich umfasst die Entscheidungspunkte „Systemelemente realisiert“ und „System in-tegriert“. Informationen für das Product Backlog werden aus dem Pflichtenheft und denbereits erstellten Produkten „Systemarchitektur“, „Implementierungs-, Integrations- und

65


Prüfkonzept System“, „SW-Architektur“, „Implementierungs-, Integrations- und Prüf-konzept SW“ und „Projekthandbuch“ hergeleitet.

Abbildung 5.9: Durch die vierte Variante markierter Bereich in einem AG/AN-Projektmit Entwicklung, Weiterentwicklung oder Migration

Das Ziel dieser Variante ist die Erstellung des Systems. Wie in Variante 1 sind auchhier die Ausgabeprodukte von SCRUM das „System“ und das „Segment“. Hinzu kommtdas Produkt „Prüfprotokoll Systemelement“. Da alle im Bereich enthaltenen Produktekeine weiteren Produkte erzeugen, muss dies auch nicht durch SCRUM geschehen.

Somit ergeben sich die in Abbildung 5.10 dargestellten Informationsflüsse nach der In-tegration von SCRUM. Es werden also die Produkte „SW-Einheit“, „SW-Komponente“und „SW-Modul“ eingespart.

Vorteile

Die Vorteile der vierten Variante bestehen in einer geringen Zeitersparnis während derRealisierung, Integration und Durchführung von Tests. Immerhin kann dieses auf Ba-sis agiler Methoden durchgeführt werden, was einige Vorteile der agilen Entwicklungund Entwicklung mit SCRUM mit sich bringt. Die Produkte, die für die Realisierungdes Entwurfs gefordert werden, liegen bereits vor. Dies bietet eine gute Rechtsgrund-

66


lage im Falle fehlerhafter Endprodukte. In dieser Variante wird dieser Vorteil mit denVorteilen der Realisierung mit Hilfe agiler Methoden verbunden.

Abbildung 5.10: Aus Abbildung 5.9 resultierende Informationsflüsse nach der Integra-tion von SCRUM

Nachteile

Dies zieht allerdings den Nachteil der sinkenden Flexibilität mit sich. Sollen späte Än-derungen vorgenommen werden, müsse diese in den entsprechenden, zuvor erstelltenProdukten der Entwurfsphase geändert werden. Oft sind hier auch kleine Änderungen,die erst in der Realisierung erkannt und nötig geworden sind, schwerer durchzuführen,als in den ersten beiden Varianten.

Ein weiterer Nachteil ist die große Anzahl Produkte, dessen Informationen in das Pro-

67


duct Backlog übernommen werden müssen. Zusätzlich zu Informationen aus demmöglicherweise sehr großen Pflichtenheft müssen Informationen aus fünf weiterenProdukten in das Product Backlog einfließen. Die Aufbereitung dieser Produkte kannalso sehr viel Zeit in Anspruch nehmen.

5.2 Allgemeine Variationen

Im Folgenden werden Variationen angegeben, die unter anderem unabhängig von denEntscheidungspunkten aus Kapitel 5.1 betrachtet werden. Zum einen betrifft dies all-gemeine Varianten, die unabhängig vom Projektfortschritt durchzuführen sind. Zumanderen werden Varianten vollständigkeitshalber aufgeführt, die in einem Projekt nichtdurchgeführt werden sollten.

5.2.1 Anzahl der eingesetzten Teams

Insbesondere für größere Projekte wird in SCRUM nicht nur ein einziges Team einge-setzt. Um den kompletten Umfang großer Projekte in angemessener Zeit bewältigenzu können, müssen mehr als neun Personen für SCRUM eingesetzt werden. Dies kannauch für die Integration von SCRUM gewünscht sein.

Sollten mehr als neun Personen zum Einsatz kommen, ist es, wie SCRUM vorgibt,wichtig, dass die Teamgröße nicht über neun Teammitglieder hinaus geht. Es müssenalso mehrere Teams gebildet werden. Die Koordination der Teams läuft über das so-genannte, in SCRUM vorgeschlagene, SCRUM of SCRUMs. Dabei trifft sich jeweilsein Repräsentant pro Team nach einem SCRUM Meeting des Teams mit den anderenRepräsentanten der anderen Teams, welche ein eigenes SCRUM-Meeting auf höhe-rer Ebene durchführen. Der Repräsentant kehrt anschließend zu seinem Team zurückund gibt die erhaltenen Informationen weiter, sofern dies notwendig ist.

In der Regel sollten die Entwickler, die V-Modell-basiert entwickelt haben, auf dieseTeams aufgeteilt werden. Probleme dabei gibt es, wenn mehr Entwickler für SCRUMeingesetzt werden sollen, als zuvor beschäftigt waren. Solange aber nicht mehr alsneun Mal so viele Entwickler für SCRUM eingesetzt werden sollen, können die bishe-rigen Entwickler auf die Teams aufgeteilt werden, so dass jedes Team einen Entwicklermit an Bord hat, der sich mit den bisherigen Prozessen auskennt.

5.2.2 Endpunkt der Integration von SCRUM für Entscheidungspunkte

Wird SCRUM gemäß Kapitel 5.1 zwischen Entscheidungspunkten durchgeführt, sobleibt die Frage offen, ob SCRUM kurz vor einem Entscheidungspunkt oder kurz nacheinem Entscheidungspunkt enden soll. Beide Varianten haben ihre eigenen Vor- undNachteile.

68


Endet SCRUM kurz vor einem Entscheidungspunkt, so steht die nachfolgende Prü-fung der Produkte, die durch den Entscheidungspunkt gefordert werden, noch an.Die Produkte müssen somit korrekt mit SCRUM erstellt worden sein, um eine Prü-fung erfolgreich durchzustehen. Produkte, die der vom V-Modell geforderten Qualitätnicht entsprechen, werden somit identifiziert und verbessert, was die Qualität der vonSCRUM gelieferten Produkte sicherstellt.

Allerdings erzielt SCRUM in der Regel qualitativ hochwertige Ergebnisse. SCRUM soll-te eigene Mechanismen durchführen, um die Qualität der Arbeit und der Produkte si-cherzustellen. Eine erneute Überprüfung der Produkte führt in gewisser Hinsicht zukeinem neuen Wissensgewinn. Endet SCRUM kurz hinter einem Entscheidungspunkt,so entfällt die vom V-Modell geforderte Prüfung durch den Entscheidungspunkt. DieEntwicklung kann weiter gehen, ohne dass eine zeitaufwändige Prüfung durch dasManagement durchgeführt werden muss.

5.2.3 Integration von SCRUM ohne Entscheidungspunkte

In Kapitel 5.1 wurde vorgeschlagen, SCRUM genau zwischen Entscheidungspunktendurchzuführen, also den Bereich direkt hinter Absolvieren eines Entscheidungspunk-tes anzusetzen und kurz vor oder nach einem anderen Entscheidungspunkt enden zulassen. Denkbar wäre es auch, den Start- und Endpunkt von SCRUM unabhängig vonden Entscheidungspunkten zu wählen.

Allerdings ist dabei zu berücksichtigen, dass die Entscheidungspunkte vor und nachder Durchführung von SCRUM dennoch im V-Modell eine Rolle spielen. Wird der Start-punkt nicht unmittelbar nach einem Entscheidungspunkt gewählt, so bedeutet dies,dass zwischen dem letzten Entscheidungspunkt und SCRUM bereits an Produktengearbeitet worden ist. Es kann möglich sein, dass die Produkte noch nicht fertig ge-stellt worden sind.

Damit die bisherige Arbeit, die in das Produkt eingeflossen ist, nicht umsonst war,muss SCRUM entweder mit dem unfertigen Produkt weiter arbeiten und versuchen,es fertig zu stellen oder aber die Informationen des Produkts in das Product Backlogübernehmen und somit mit den so gewonnen Informationen weiter arbeiten. Die ersteMöglichkeit würde SCRUM in seiner Funktionsweise einschränken. Zudem bliebe dieFrage offen, warum das Produkt nicht mit dem V-Modell fertig gestellt wurde. Die zwei-te Möglichkeit würde wiederum viel Zeit in Anspruch nehmen, um die Informationenaufzubereiten. Zudem würde das Produkt nicht fertiggestellt werden, wodurch einigeArbeit, die zuvor in die Erstellung des Produkts investiert wurde, umsonst gewesenwäre.

5.2.4 Integration von SCRUM für einzelne Informationsflüsse

Eine weitere Variation besteht darin, Bereiche bestehend aus einzelnen Informations-flüssen zwischen Produkten mit SCRUM durchzuführen. Dies wird in der Regel da-durch problematisch, dass die meisten Informationsflüsse während der Systement-

69


wicklung zwischen sehr vielen Produkten fließen. In Abbildung 5.11 wird ein kleinesBeispiel aus der Gesamtabbildung 5.2 gegeben, an dem dieser Punkt erläutert wer-den soll.

Abbildung 5.11: Kleiner Ausschnitt aus Abbildung 5.2 mit ausgewähltem Bereich

Die gesamte Architektur des Systems soll mit Hilfe von SCRUM erstellt werden. In Ab-bildung 5.11 wird der Bereich daher so gewählt, dass das Produkt „SW-Architektur“ er-zeugt wird und das Produkt „Systemarchitektur“ eingespart werden kann. Nun müssenaber auf Grund dieser Einsparung und der Überlegungen aus Kapitel 4.1 die Produkte„Systemspezifikation“, „Prüfspezifikation Systemelement“, „IIPSW“, „SW-Spezifikation“,„Prüfprozedur Systemelement“ und „Make-or-Buy Entscheidung“ dennoch erzeugt wer-den. Zusätzlich werden als Eingang für SCRUM Informationen aus dem Produkt „IIPS“benötigt, die zu den zusätzlichen Eingangsinformationen hinzukommen. Im Endeffektkönnen somit keine Produkte eingespart werden. SCRUM müsste zudem sehr vieleProdukte erzeugen, bevor wieder zum V-Modell-basierten Entwicklungsprozess zu-rückgekehrt werden kann, obwohl ursprünglich nur ein einziges Produkt mit SCRUMerzeugt werden sollte.

Als Fazit ist es im Allgemeinen sehr schwierig, einzelne Informationsflüsse zwischenProdukten mit SCRUM zu ersetzen und zu erstellen. Es ist sinnvoller, SCRUM fürgrößere Bereiche einzusetzen.

5.2.5 Nachdokumentation

Werden durch die Entwicklung mit SCRUM Produkte eingespart, deren Erstellung imspäteren Verlauf des Projekts aber unerlässlich sind, so müssen diese Produkte nach-dokumentiert – also nachträglich erstellt – werden. Dies kann beispielsweise der Fall

70


sein, wenn ein Produkt durch Gründe rechtlicher Sicherheit vorhanden sein muss.Ein abschließender Testbericht, der alle durchgeführten Tests auflistet und begrün-det, warum diese Tests durchgeführt werden müssen, kann ein Beispiel dafür sein.Genauso können Begründungen von Designentscheidungen oder eine Auswahl einerTechnologie schriftlich gefordert werden.

Zudem gehen Informationen, die in den Gedächtnissen der Entwickler gespeichertund nicht dokumentiert sind im Verlaufe der Zeit verloren. Bereits zum Ende einesProjekts kann es schwierig sein, sich an Entscheidungen zu erinnern, die zu Beginneines Projekts getroffen wurden. Noch schlimmer sieht es aus, wenn sich Entwickleran Projekte erinnern müssen, die Jahre in der Vergangenheit liegen. Oft wurden seitdiesem Projekt andere Projekte durchgeführt, die damals getroffene Entscheidungenverdrängen. Werden nach längerer Zeit detaillierte Informationen benötigt, ist es fürEntwickler fast schon unmöglich, sich im Detail an das Projekt und die Entscheidungenzu erinnern.

Dabei stellt sich die Frage, ob gut und sauber dokumentierte Erzeugnisse von SCRUMdiese Produkte ersetzen können. Die Antwort auf diese Frage fällt von Unternehmenzu Unternehmen unterschiedlich aus. Daher sollen an dieser Stelle möglichst effektiveFormen der Nachdokumentation vorgestellt werden.

Der einfachste Versuch, die fehlenden Produkte nachträglich zu erzeugen, führt überdie in SCRUM entstandene Dokumentation. So werden beispielsweise Entscheidun-gen bezüglich der Erstellung von Code in diesem Code als Kommentare festgehalten.Sind diese Kommentare sauber und logisch erstellt worden, können sie durchaus alsDokumentation angesehen werden. Um diesen Aspekt zu nutzen, müssen alle Ent-wickler hoch diszipliniert ihren Code kommentieren. Sollten die Kommentare alleinnicht ausreichen und ist eine Aufbereitung dieser Kommentare notwendig, so könnensie dennoch erheblich dazu beitragen, die Aufbereitung zu beschleunigen. FrühereEntscheidungen sind mit Hilfe der Kommentare leichter ins Gedächtnis zu rufen. Ent-wickler können sich so unter Umständen vollständig an bereits vergessene Informa-tionen erinnern. Zudem können große Teile der Kommentare aufbereitet und über-nommen werden, wodurch das Produkt nicht von Grund auf neu geschrieben werdenmuss.

Reichen Kommentare als Dokumentation oder Informationsquelle nicht aus, kann einSchritt weiter gegangen werden, indem eine entsprechende Rolle allein für die Auf-gabe der Dokumentation geschaffen wird. Die Person, die diese Rolle bekleidet, hatwährend der gesamten Durchführung von SCRUM ausschließlich die Aufgabe, Ent-scheidungen und Vorgänge zu dokumentieren, die bezüglich der kritischen, fehlendenProdukte benötigt werden. Anschließend oder auch während dieser Aufgabe kann sieaus diesen Dokumentationen das Produkt erstellen, welches später in vergleichsweiseguter Qualität vorliegt.

Somit entsteht der Vorteil, dass die benötigten Produkte, die der Absicherung dienen,direkt während der Entwicklung geschrieben werden. Die Entwickler müssen sich so-mit nicht nachträglich mit der Erstellung von Produkte beschäftigen. Da die kritischenProdukte ohnehin erstellt werden müssen, wird bei dieser Methode keine zusätzliche

71


Zeit im Vergleich zu der Nachdokumentation am Ende der Entwicklungsphase benö-tigt.

Der Nachteil bei dieser Variante ist, dass entweder ein zusätzlicher Mitarbeiter ein-gestellt werden muss oder aber ein Teammitglied diese Rolle bekleidet und somit fürdie eigentlich anstehende Arbeit nicht mehr zur Verfügung steht. Ein weiteres, großesProblem besteht darin, dass die dokumentierende Rolle nicht immer Entscheidungen,die Entwickler während ihrer Arbeit treffen, mitbekommt. Also müssen Informationen,wie weiter oben bereits gesagt, wieder aus Kommentaren gewonnen werden.

Allerdings kann im Falle von Unklarheiten der entsprechende Entwickler direkt gefragtwerden, welcher die Informationen noch frisch im Gedächtnis vorliegen hat. Es mussin diesem Fall also nachgefragt werden, warum Entwickler Entscheidungen getroffenhaben, was diese vom Arbeiten abhält.

Dies befreit die Entwickler somit nicht von ihrer Aufgabe, Code sauber zu kommen-tieren, da die Kommentare möglicherweise in Produkte einfließen. Selbst wenn diesnicht der Fall ist, sollte Code aus vielen anderen Gründen kommentiert werden.

72

6 Implementierung

6.1 Prototypische Entwicklung zur Ermittlung undDarstellung von Produktabhängigkeiten des V-Modells

Für die Herleitung von Informationsflüssen in Kapitel 3 werden die Produktabhängig-keiten des V-Modells herangezogen. Das V-Modell gibt dabei an, welche Produktab-hängigkeiten zwischen Produkten existieren. Allerdings besitzt das V-Modell sehr vieleProdukte und somit auch sehr viele Produktabhängigkeiten.

Um eine Übersicht über alle Produkte und ihre Abhängigkeiten zu bekommen, ist einetextuelle Darstellung, wie sie im V-Modell gegeben wird, ungeeignet. Eine grafischeÜbersicht über Produkte und ihre Produktabhängigkeiten ist wünschenswert, um einenInformationsfluss zu erkennen und einen Überblick über alle voneinander abhängigenProdukte zu bekommen.

Zudem muss es möglich sein, kleinere Mengen von Produkten auszuwählen, damitTeilbereiche der gesamten Produktabhängigkeiten gezielt betrachtet werden können.Somit können ausschließlich Produkte, die zum Betrachtungszeitpunkt von Interessesind, in den Fokus gerückt und betrachtet werden, um sich auf diese zu konzentrieren.

Der entwickelte und im Folgenden beschriebene Prototyp zur Ermittlung und Darstel-lung von Produktabhängigkeiten des V-Modells wird genau diesen Forderungen ge-recht. Zudem wird er benötigt, um alle Produkte bei der Planung der Integration vonSCRUM zu berücksichtigen. Wird SCRUM für einen Teilbereich ausgewählt, so kannvisuell angezeigt werden, welche Produkte von der Ersetzung betroffen sind. Somit istschnell ersichtlich, ob Zwischenprodukte innerhalb des Bereichs erzeugt werden müs-sen. Mit Hilfe des Prototypen wird also das Risiko, dass Produkte übersehen und nichterzeugt werden, minimiert.

6.1.1 Funktionsweise

Um die Produktabhängigkeiten des V-Modells zu gewinnen, werden HTML-Seitendes V-Modells geparst. Die HTML-Seiten müssen mit dem Projektassistenten des V-Modells [vmo] gewonnen werden. Dies geschieht, indem ein Tailoring des durchzufüh-renden Projekts mit Hilfe des Projektassistenten durchgeführt wird.

Das getailorte Projekt kann anschließend mit dem Assistenten in HTML-Format ex-portiert werden. Dafür müssen dort die Teile 3 und 5 der Dokumentation exportiertwerden. Anschließend müssen die exportierten HTML-Seiten in die entsprechendenOrdner des Prototypen kopiert werden. Teil 3 beinhaltet Informationen über die Ent-

73

6 Implementierung

scheidungspunkte und muss in den Ordner „HTML_Decision_Gates“ kopiert werden.Teil 5 hingegen beinhaltet Informationen über die zu erzeugenden Produkte und mussfolglich in den Ordner „HTML_Products“ kopiert werden.

Anschließend verfügt der Prototyp über alle benötigten Informationen aus dem V-Modell. Das Startmenü ist in Abbildung 6.1 dargestellt, in dem weitere Einstellungs-möglichkeiten vorgenommen werden können, welche die Aufgaben und damit resul-tierende Anzeige des Prototypen vorgibt.

Abbildung 6.1: Hauptmenü des Prototypen zur Darstellung von Produktabhängigkei-ten

Der Prototyp kann sowohl erzeugende Produktabhängigkeiten, als auch inhaltlicheProduktabhängigkeiten darstellen. Welche dieser Produktabhängigkeiten angezeigtwerden soll, wird über die Kategorie „Modus der Abhängigkeiten“ bestimmt. Die Ein-stellungsmöglichkeiten „Erzeugende Abhängigkeiten“ und „Erzeugte Abhängigkeiten“unterscheiden sich durch die Leserichtung des Prototypen. Bei der ersten Variantewird die Richtung ausgehend vom erzeugenden Produkt hin zum erzeugten Produktgelesen, bei der zweiten Variante wird die Richtung andersherum gelesen. Abbildun-gen 6.2 stellt beispielhaft dar, wie die Ausgabe für erzeugende und inhaltliche Produk-tabhängigkeiten aussieht.

Da der Graph, welcher die Produkte und ihre Abhängigkeiten beinhaltet, sehr groß

74

6 Implementierung

Abbildung 6.2: Kleines Beispiel für erzeugende (links) und inhaltliche (rechts) Abhän-gigkeiten aus dem V-Modell

werden kann, können zusammengehörige Produkte zusammengefasst werden, umPlatz zu sparen. Diese Funktion ist in der Kategorie „Strukturierung“ zu aktivieren.Ein Beispiel wird in Abbildung 6.3 gegeben. Als zusammengehörig lassen sich diehierarchisch zusammengehörigen Produkte des Systems („System“, „Segment“, „SW-Einheit“, „SW-Komponenten“, „SW-Modul“), der Architektur („Systemarchitektur“, „SW-Architektur“) und der Spezifikation („Systemspezifikation“, „SW-Spezifikation“) betrach-ten. Dies sind die Produkte, die durch strukturelle Produktabhängigkeiten miteinanderverbunden sind.

Abbildung 6.3: Kleines Beispiel für das Zusammenfassen von Produkten zur besserenÜbersicht

Der Prototyp bietet die Möglichkeit, anzeigen zu lassen, von welchen Entscheidungs-punkten die angezeigten Produkte gefordert werden. Zudem lassen sich die Aktivitätenvisualisieren, die zur Erstellung des Produkts durchgeführt werden, sowie die Rollen,die an dem Produkt mitwirken oder verantwortlich für das Produkt sind. Diese Funktio-nen können in der Kategorie „Zusätzliche Anzeigen“ hinzugeschaltet werden.

Standardmäßig werden alle Produkte und ihre Abhängigkeiten ungefiltert angezeigt.Allerdings kann es wünschenswert sein, nur einige der Produkte visualisieren zu las-

75

6 Implementierung

sen. Dafür bietet der Prototyp eine Filterfunktion, die die angezeigten Produkte aufeine ausgewählte Menge beschränkt. Welche Produkte angezeigt werden sollen, lässtsich über das in Abbildung 6.4 dargestellte Menü, welches über den Button „Produkte“erreichbar ist, einstellen.

Abbildung 6.4: Auswahlmenü des Prototypen zur Darstellung von Produktabhängigkei-ten für Produkte des V-Modells. In dieses Menü kann über den Button„Produkte“ aus Abbildung 6.1 gelangt werden.

Nach der Generierung der dot-Datei (vergleiche Kapitel 6.1.2) über den Button „Ge-nerieren“ wird der Benutzer über die fehlerfreie Erstellung dieser Datei am unterenBildschirmrand informiert. Zeitgleich wird ein Bild in PNG-Format erstellt, welches denGraphen beinhaltet. Die Erzeugung dieses Bildes kann – je nach Rechenleistung desverwendeten Computers – etwas Zeit in Anspruch nehmen. Dies ist in derartigen Fäl-len der Größe des zu visualisierenden Graphen geschuldet. Abschließend kann derGraph durch Klicken des Buttons „Visualisieren“ angezeigt werden.

76

6 Implementierung

Der Prototyp bietet die Möglichkeit, weitere Einstellungen vorzunehmen. Die Einstel-lungsmöglichkeiten reichen von der Wahl des Bildanzeigeprogramms über diverse An-passung bis hin zu der Farbe der Pfeile des Graphen. Da diese Einstellungen in derRegel selten verwendet werden, gibt es dafür keine grafische Oberfläche. Stattdessenkönnen die Änderungen über die im Ordner „config“ vorhandene Konfigurationsdateivorgenommen werden.

6.1.2 Technische Realisierung

Wie in Kapitel 6.1.1 bereits erwähnt, parst der Prototyp HTML-Seiten, die vom V-Modell-Projektassistenten erstellt wurden. Das Parsen der HTML-Seiten wird mit Hilfeder Java-Bibliothek „jsoup“ [jso] durchgeführt. jsoup bietet Funktionen an, um eineHTML-Datei zu parsen und mit Java auf die geparsten Elemente zuzugreifen.

Diese Elemente werden verwendet, um Informationen über Produkte, Produktabhän-gigkeiten, Entscheidungspunkte, Aktivitäten und Rollen zu gewinnen. Anschließendwerden diese Informationen aufbereitet und in ein dot-Format exportiert. Dieses For-mat kann von „Graph Visualization“ [gra] gelesen und zu einem gerichteten Graphenverarbeitet werden, welcher im PNG-Format gespeichert und angezeigt werden kann.

Für den abgebildeten Baum im Produktauswahlmenü wird das JIDE Common Layervon JIDE Software [jid] verwendet, welches die Möglichkeit bietet, einen Baum zusam-men mit Checkboxes einzufügen und zu verwenden. Über diesen Baum geschieht dieSelektion von Produkten (vergleiche Abbildung 6.4).

6.2 Leitfaden zur Integration von SCRUM in das V-Modell XT

Zusätzlich zu den Ergebnissen dieser Arbeit soll ein Leitfaden erstellt werden, derdiese Ergebnisse zusammenfasst und visuell anzeigt. Der Leitfaden dient der grobenEntscheidungshilfe, welche Position für eine Integration von SCRUM am Besten fürein Unternehmen geeignet ist. Er nimmt dem Benutzer die Aufgabe ab, jede Variantezu prüfen und anschließend entscheiden zu müssen, welche Variante die passendsteist. Die Details zur Umsetzung der Variante müssen allerdings in der Arbeit selbstnachgelesen werden.

Um bewerten zu können, welche Variante für den Benutzer am besten geeignet ist,werden die in Tabelle 4.1 angegebenen Vor- und Nachteile als Bewertungskriterienherangezogen. Das Bewertungsmenü des Leitfadens ist in Abbildung 6.5 abgebildet.Der Benutzer muss für jedes Kriterium angeben, wie wichtig ihm dieses ist. Zusätzlichwird nach der Größe des Projekts gefragt, da diese Frage für jedes durchzuführendeProjekt relevant ist.

Sind alle Kriterien bewertet worden, wird die Auswertung dieser Bewertung vorgenom-men. Dazu wird jeder Vor- und Nachteil der Varianten 1 (Kapitel 5.1.1),2 (Kapitel 5.1.2)und 4 (Kapitel 5.1.4) gewichtet. Die Gewichtung fließt in die Gesamtbewertung der je-

77

6 Implementierung

Abbildung 6.5: Hauptmenü des Leitfadens zur Integration von SCRUM in das V-ModellXT

weiligen Variante ein, sofern das Kriterium als wichtig erachtet wurde. Wie genau dieGewichtung ausgewählt wurde, wird in Kapitel 6.2.1 erklärt.

Mit Hilfe des Buttons „Weiter“ lassen sich die Varianten mit der besten Bewertung an-zeigen (Abbildung 6.6). In einigen Fällen können zwei Varianten die gleiche Bewertungbekommen haben. Wenn dem so ist, werden beide Varianten vorgeschlagen. Für je-de Variante wird angegeben, welches gewünschte Kriterium des Benutzers umgesetztwird und welches nicht.

Ein Kriterium wird komplett umgesetzt, wenn es als unwichtig beurteilt wurde oder dieVariante bezüglich des Kriteriums Vorteile besitzt. Ein Kriterium wird teilweise umge-setzt, wenn die Variante bezüglich des Kriteriums geringe Vorteile besitzt. Nicht um-gesetzt wird hingegen ein Kriterium, wenn die Variante bezüglich dieses KriteriumsNachteile besitzt.

Ob eine Variante bezüglich eines Kriteriums gut oder schlecht dasteht, hängt von derArt des Kriteriums und dem Vergleich zwischen ihr und den anderen Varianten ab.Kriterien, die aus Vorteilen entstanden sind, müssen möglichst hoch erfüllt sein, Kri-terien, die aus Nachteilen entstanden sind hingegen möglichst gering. Die folgendenKriterien stehen dem Benutzer zur Bewertung zu Verfügung.

78

6 Implementierung

Abbildung 6.6: Vorschlag geeigneter Varianten. In dieses Menü kann über den Button„Weiter“ aus Abbildung 6.5 gelangt werden.

Zeitersparnis Eine Variante ist gut, wenn sie eine hohe Zeitersparnis mit sich bringt.

Flexibilitätsgewinn Eine Variante ist gut, wenn sie eine hohe Flexibilität aufweist.

Geringere Sicherheit Eine Variante ist gut, wenn sie wenig Sicherheitsverlust in Kaufnimmt.

Erhöhter Aufbereitungsaufwand Eine Variante ist gut, wenn sie wenig Aufbereitungs-aufwand bedarf.

Wie gut oder schlecht eine Variante im Vergleich zu anderen Varianten ist, kann denKapiteln 5.1.1, 5.1.2 und 5.1.4 entnommen werden.

Zudem stellt der Leitfaden das der Variante zugehörige Bild dar, damit grundlegendersichtlich ist, um welche Variante es sich handelt, sowie die Kapitelnummer dieserArbeit, wo diese Variante weiter erläutert wird. Bei Bedarf kann die Variante somitleicht gefunden und Informationen nachgelesen werden.

Im Falle von größeren Projekten, wird eine Anmerkung ausgegeben, dass die in Ka-pitel 5.2.1 beschriebenen Hinweise bezüglich der Projektgröße berücksichtigt werdensollten.

79

6 Implementierung

6.2.1 Gewichtung der Kriterien des Leitfadens

Da sich die Varianten, die im Leitfaden zur Integration von SCRUM in das V-ModellXT vorgeschlagen werden, in ihren Vor- und Nachteilen unterscheiden, werden dieseUnterschiede als Kriterium für die dem Vorschlag zu Grunde liegenden Bewertungherangezogen. Da nicht alle Vor- und Nachteile zu gleichen Anteilen in den Variantenenthalten sind, müssen diese gewichtet werden. Wie diese Gewichtung aussieht, wirdim Folgenden betrachtet.

In den Kapiteln 5.1.1, 5.1.2 und 5.1.4 wird beschrieben, wie die in Tabelle 4.1 angege-benen Vor- und Nachteile in den Varianten zur Geltung kommen. Basierend auf dieserBeschreibung wird die in Tabelle 6.1 folgende Gewichtung vorgenommen.

Vorteile Nachteile

Z F S A

Variante 1 1 1 -1 0

Variante 2 0 0 0 1

Variante 4 -1 -1 2 -2Z = Zeitersparnis, F = Flexibilität, S = Sicherheit, A = Aufbereitungsaufwand

Tabelle 6.1: Grobe Übersicht über Vor- und Nachteile der Integration von SCRUM indas V-Modell XT

In der Regel folgt die Gewichtung einem einfachen Muster. Die Beste Variante bezüg-lich eines Kriteriums bekommt einen positiven Wert, die schlechteste einen negativen.Die Variante, die sich zwischen den anderen beiden Varianten befindet, bekommt denWert 0.

Der Unterschied im Aufbereitungsaufwand ist zwischen der vierten und den erstenbeiden Varianten besonders groß. Daher wird er für Variante 4 doppelt gewichtet. Da-mit die vierte Variante dennoch bei ausgewähltem Sicherheitskriterium zum Einsatzkommen kann, wird dieser Vorteil der Variante gegenüber den anderen ebenfalls ver-doppelt.

Die Bewertung einer Variante geschieht gemäß der Formel

Vi = BZ � GZi+ BF � GFi + BS � GSi + BA � GAi

mit

i 2 f1; 2; 4g; BX 2 f0; 1g; X 2 fZ; F; S; Ag

wobei Vi die Bewertung der Variante i , BX die vom Nutzer durchgeführte Bewertungdes Kriteriums X und GXi

die Gewichtung des Kriteriums bezüglich Variante i gemäßTabelle 6.1 ist.

80

6 Implementierung

Daraus ergeben sich die Bewertungen der Varianten in Abhängigkeit der in den Tabel-len 6.2 bis 6.4 aufgelisteten, möglichen Kombinationen von Kriterien.

- Z F S A

Variante 1 0 1 1 -1 0

Variante 2 0 0 0 0 1

Variante 4 0 -1 -1 2 -2Z = Zeitersparnis, F = Flexibilität, S = Sicherheit, A = Aufbereitungsaufwand

Tabelle 6.2: Bewertung der Varianten in Abhängigkeit der Kriteriumskombinationen(ein Kriterium gewählt)

ZF ZS ZA FS FA SA

Variante 1 2 0 1 0 1 -1

Variante 2 0 0 1 0 1 1

Variante 4 -2 1 -3 1 -3 0Z = Zeitersparnis, F = Flexibilität, S = Sicherheit, A = Aufbereitungsaufwand

Tabelle 6.3: Bewertung der Varianten in Abhängigkeit der Kriteriumskombinationen(zwei Kriterien gewählt)

ZFS ZFA ZSA FSA ZFSA



Variante 4 0 -4 -1 -1 -2Z = Zeitersparnis, F = Flexibilität, S = Sicherheit, A = Aufbereitungsaufwand

Tabelle 6.4: Bewertung der Varianten in Abhängigkeit der Kriteriumskombinationen(drei Kriterien gewählt)

81

7 Fazit

In dieser Arbeit wurde beschrieben, dass die Integration von SCRUM in das V-ModellXT auf Basis von Informationsflüssen möglich ist.

Um SCRUM in das V-Modell zu integrieren, müssen zuerst die gesamten Informations-flüsse des V-Modells, sowie die Informationsflüsse in SCRUM hinein und aus SCRUMheraus identifiziert werden. Damit eine Integration von SCRUM durchgeführt werdenkann, wurde beschrieben, wie die Informationsflüsse und Methoden von SCRUM an-gepasst werden müssen. Anschließend konnten die Informationsflüsse von SCRUMin den gesamten Informationsfluss des V-Modells integriert werden. Durch den neuentstandenen Informationsfluss ist es möglich, ein V-Modell-basiertes Projekt mit inte-griertem SCRUM durchzuführen. Um dies an Beispielen vorzuführen, wurden Integra-tionsvarianten vorgestellt, die sich teils gut und teils schlecht für die Integration eignen.

Um die Informationsflüsse zu visualisieren, wurde ein Prototyp entwickelt, der mit Hilfeder Produktabhängigkeiten des V-Modells diese Aufgabe erledigt. Die Visualisierungder Informationsflüsse hilft dabei, SCRUM in das V-Modell zu integrieren, ohne Infor-mationsflüsse zu übersehen und somit Fehler im Ablauf des Projekts zu erzeugen.

Der entwickelte Leitfaden für die Integration von SCRUM gibt übersichtlich an, wel-che Integrationsvarianten unter Berücksichtigung bewerteter Kriterien am sinnvollstenfür die Integration geeignet sind. Dies hilft dabei, einen Vorschlag für die Variante zubekommen, die für die eigenen Bedürfnisse am Besten geeignet ist und bietet einengroben Einstieg.

Abschließend wird die Arbeit in Kapitel 7.1 kritisch zur Diskussion gestellt. In Kapitel7.2 werden zum Schluss mögliche, an diese Arbeit anknüpfende Aufgaben beschrie-ben.

7.1 Kritische Würdigung

In dieser Arbeit wurde SCRUM in das V-Modell XT integriert. Dabei wurde erläutert,auf welche Art und Weise SCRUM angepasst werden muss, um sich in das V-ModellXT einzufügen. Das V-Modell bleibt in seiner gesamten Durchführung, bis auf die Be-reiche, in denen SCRUM zum Einsatz kommt, unverändert. Nun wäre es aber denk-bar, dass das V-Modell auch oder ausschließlich angepasst wird. Dieser Lösungswegwird von dieser Arbeit nicht verfolgt. Zum einen liegt es daran, dass es leichter ist,einen flexiblen, gut anpassbaren, agilen Prozess, wie SCRUM, an einen statischenProzess anzupassen. Zum anderen ist nicht ganz klar, in wie fern die Vorteile des(sehr großen) V-Modells erhalten bleiben, wenn Anpassungen an vielen Bereichen

82

7 Fazit

vorgenommen werden. Aussagen über die Gewährleistung der Qualität werden vomV-Modell garantiert, indem die Einhaltung von Aspekten wie die Prüfung der Produk-te durch Entscheidungspunkte und dem Tailoring eingehalten werden. Würden bei-spielsweise Anpassungen am Mechanismus der Entscheidungspunkte vorgenommenwerden, müsste gleichzeitig für jede Änderung betrachtet werden, ob die Vorteile desV-Modells immer noch Bestand haben. Eine jeweilige Betrachtung für jede Änderungam V-Modell kann unter Umständen sehr aufwendig sein. Da SCRUM gemäß der Auf-gabenstellung innerhalb eines V-Modell-basierten Projekts zum Einsatz kommen soll,bleiben Änderungen an SCRUM ohnehin nicht ganz aus. Zumindest die in Kapitel4.2.6 gemachten Aussagen bezüglich des Umgangs mit Fragen, die durch die Integra-tion entstehen, wären notwendig gewesen, da diese Fragen erst nach einem Wechselder Prozessart zum Vorschein kommen und die Beantwortung dieser Fragen nach derDurchführung von SCRUM zu spät gewesen wären.

Zudem deckt diese Arbeit nicht alle vorstellbaren Integrationsmöglichkeiten ab, son-dern umreißt nur die wichtigsten. So wäre es beispielsweise denkbar, dass ein Projektnormal gemäß V-Modell durchgeführt wird. Ändern sich die Anforderungen für dasProjekt, wäre es vorstellbar darauf zu reagieren, indem die Änderungen mit SCRUMdurchgeführt werden. Die Änderungen können anschließend in das V-Modell integriertwerden um danach das Projekt gemäß V-Modell fortzusetzen. Diese Variante erfor-dert weitere Überlegungen, die aus Zeitgründen nicht vorgenommen werden konnten.Durch genauere Betrachtung dieser Variante hätten gegebenenfalls weitere Variantenentstehen können, die die Ergebnisse dieser Arbeit hätten erweitern können. Außer-dem hätte die Betrachtung der Variante möglicherweise zur Lösung einiger Problemeführen können, welche beispielsweise die Integration der Variante aus Kapitel 5.1.3ermöglichen könnte.

Diese Arbeit wurde im Rahmen des Software Engineering geschrieben und beziehtsich bei der Verwendung von Beispielen tendenziell auf Software. Die Realisierungvon Hardware mit Hilfe des V-Modells wurde in dieser Arbeit nicht betrachtet. So wur-de mit Hilfe des Tailoringassitenten des V-Modells ein Projekt getailort, welches dieErstellung von Hardware nicht vorsieht. Prinzipiell funktionieren die in dieser Arbeitvorgestellten Methoden und Ergebnisse auch für die Erstellung von Hardware, da sieallgemein für Informationsflüsse formuliert wurden. Allerdings beziehen sich die die-ser Arbeit zu Grunde liegenden Grundlagen bezüglich der Informationsflüsse nach[STAPEL 2012] ausschließlich auf Softwareprojekte, auch wenn eine Übertragung aufProjekte inklusive Erstellung von Hardware möglich sein kann.

7.2 Ausblick

Im Anschluss an diese Arbeit können weitere Aufgaben folgen. Beispielsweise könnendie in Kapitel 7.1 angestellten Überlegungen weiter verfolgt werden. Es kann versuchtwerden, das V-Modell anzupassen, so dass eine Integration von SCRUM in mehr Be-reichen oder leichter zum Einsatz kommen kann. Dabei muss genau betrachtet wer-den, in wie weit die Vorteile des V-Modell-basierten Prozesses erhalten bleiben.

83

7 Fazit

Der zweite aus Kapitel 7.1 angesprochene Punkt kann ebenfalls weiter verfolgt wer-den. Somit können neuen Ideen zur Integration von SCRUM in das V-Modell XT fest-gehalten werden, die in dieser Arbeit aus Zeitgründen nicht aufgenommen wurden.

Um die Ergebnisse dieser Arbeit auf Projekte zu erweitern, die eine Erstellung vonHardware mit einschließen, muss zuerst betrachtet werden, in wie weit die Aussagenüber Informationen und Informationsflüsse nach [STAPEL 2012] auf solche Projekteübertragbar sind. Eventuelle Abweichungen müssen somit genau analysiert werden.Ist dies geschehen, kann bewertet werden, ob die in dieser Arbeit gelieferten Ergeb-nisse auf Hardwareprojekte übertragbar sind. Anschließend können einige Beispieleähnlich derer aus Kapitel 5.1 konstruiert werden, um zu zeigen, dass die übertragenenErgebnisse auch auf Hardwareprojekte anwendbar sind.

Die beiden in dieser Arbeit konstruierten Prototypen sind bereits mit einer grafischenBenutzeroberfläche versehen und lassen sich somit einigermaßen gut bedienen. Den-noch können weitere Aspekte in die Weiterentwicklung der Prototypen einfließen, umsie im Hinblick auf die Benutzerfreundlichkeit und Effizienz weiter zu verbessern.

Zum Schluss bleibt die praktische Anwendung der in dieser Arbeit gelieferten Aussa-gen und Ergebnisse in einem realen Softwareprojekt. Die theoretischen Konzepte derArbeit können somit in der Praxis getestet und evaluiert werden. Durch den Praxistestwird sich zeigen, welche Ergebnisse umsetzbar sind und an welchen Konzepten eszu Problemen gekommen ist. Die problematischen Konzepte können im Anschluss andie Evaluation verbessert werden, um das Gesamtergebnis dieser Arbeit zu verbes-sern. Außerdem können Ideen und Verbesserungsvorschläge der an der Evaluationbeteiligten Personen in die Ergebnisse einfließen und diese somit weiter verbessern.Dies könnte beispielsweise in Form von unfamgreichen Befragungen vor, während undnach dem Praxistest durchgeführt werden.

84

Literaturverzeichnis

[gra] Graph Visualization. http://www.graphviz.org. Zuletzt eingesehen am14.10.2011.

[jid] JIDE Software. http://www.jidesoft.com/. Zuletzt eingesehen am14.10.2011.

[jso] jsoup Bibliothek für Java. http://jsoup.org/. Zuletzt eingesehen am14.10.2011.

[agi] Manifesto for Agile Software Development . http://www.agilemanifesto.org. Zuletzt eingesehen am 11.5.2011.

[vmo] V-Modell . http://v-modell.iabg.de. Zuletzt eingesehen am 5.5.2011.

[vor] Vorgehensmodelle. http://www.wi-vm.gi-ev.de. Zuletzt eingesehen am10.5.2011.

[BEEDLE . SCHWABER 2002] Beedle, M. und Schwaber, K. (2002). Agile Software De-velopment with Scrum: Prentice Hall.

[COHN 2004] Cohn, M. (2004). User Stories Applied: For Agile Software Develop-ment : Addison Wesley Professional.

[LÜBKE] Lübke, D. Agile Softwareentwicklung. http://www.iwi.uni-hannover.de/lv/2005-10-27_Vortrag_luebke.pdf. Zuletzt eingesehen am 16.5.2011.

[LUDEWIG . LICHTER 2007] Ludewig, J. und Lichter, H. (2007). Software EngineeringGrundlagen, Menschen, Prozesse, Techniken: dpunkt.verlag. 1. Auflage.

[SCHNEIDER 2010] Schneider, K. (2010). Vorlesung Grundlagen der Softwaretechnik .Leibniz Universität Hannover.

[SCHNEIDER 2011] Schneider, K. (2011). Vorlesung Moderne Software-Entwicklungsmethoden. Leibniz Universität Hannover.

[STAPEL 2012] Stapel, K. (2012). Informationsflusstheorie der Softwareentwicklung.Fachgebiet Software Engineering, Leibniz Universität Hannover. Dissertation, inArbeit.

[STAPEL . SCHNEIDER 2012] Stapel, K. und Schneider, K. (2012). Managing Knowled-ge on Communication and Information Flow in Global Software Projects. Submittedfor consideration to Expert Systems Special Issue on Knowledge Engineering inGlobal Software Development.

[WALLIN . 2002] Wallin, C., Larsson, S., Ekdahl, F., und Crnkovic, I. (2002). Combi-ning Models for Business Decisions and Software Development . . Euromicro Con-ference, Dortmund: IEEE.

85

http://www.graphviz.org

http://www.jidesoft.com/

http://jsoup.org/

http://www.agilemanifesto.org

http://www.agilemanifesto.org

http://v-modell.iabg.de

http://www.wi-vm.gi-ev.de

http://www.iwi.uni-hannover.de/lv/2005-10-27_Vortrag_luebke.pdf

http://www.iwi.uni-hannover.de/lv/2005-10-27_Vortrag_luebke.pdf

Erklärung der Selbstständigkeit

Hiermit versichere ich, dass ich die vorliegende Masterarbeit selbständig und ohnefremde Hilfe verfasst und keine anderen als die in der Arbeit angegebenen Quellenund Hilfsmittel verwendet habe. Die Arbeit hat in gleicher oder ähnlicher Form nochkeinem anderen Prüfungsamt vorgelegen.

Hannover, den 27.10.2011

Stephan Kiesling

86

Danksagung

Hiermit möchte ich mich bei allen Personen bedanken, die mich bei der Erstellungdieser Arbeit unterstützt haben.

Insbesondere möchte ich mich bei meinem Betreuer M. Sc. Kai Stapel für die exzel-lente und umfassende Betreuung bedanken. Seine ausführlichen Kommentare undAnregungen haben diese Arbeit sehr bereichert.

87

Date post:	16-Jul-2018
Category:	Documents
Upload:	dangnguyet
View:	215 times
Download:	0 times

Integration agiler Entwicklungszyklen in das V-Modell auf ... · SCRUM in ihren V-Modell-basierten...

Documents