Hybride Softwareentwicklung Kombination von V-Modell XT und Scrum

Inhaltsverzeichnis

I. Inhalts verzeichnis

II. Abbildungs verzeichnis

III. Tabellenverzeichnis

1 Einleitung

2 Entwicklungsansätze im Vergleich
2.1 V-Modell XT - Vertreter der klassischen Welt
2.2 Scrum - Vertreter der agilen Welt

3 Hybrider Ans atz -Erfolgreiche Kombination von klassischer und agiler Welt
3.1 Klassische und agile Welt vereint
3.2 Anforderungen
3.3 Notwendige Anpassungen
3.4 Konkrete Lösung
3.5 Veränderte Rollen
3.5.1 Mögliche Konflikte Doppelrollen - Agile und klassische Rolle
3.5.2 Unterschiedliche Hüte verbinden klassische und agile Rollen
3.5.3 Mögliche Konflikte Doppelrollen - Zwei klassische Rollen
3.6 Grenzen

4 Zusammenfassung

5 Ausblick

Quellenverzeichnis

II. Abbildungsverzeichnis

Abbildung 1 Logo IUBH I

Abbildung 2 V -Modell XT B und o.J 3

Abbildung 3 hybrider Ent wicklungszyklus 14

III. Tabellenverzeichnis

Tabelle 1 Komponenten V-Modell XT und Scrum 7

Tabelle 2 Entscheidungs punkte V-Modell XT und hybride Lösung 13

1 Einleitung

Ein erfolgreiches Softwareprojekt zeichnet sich dadurch aus, dass der zeitliche Rahmen, das Budget sowie der definierte Feature-Umfang eingehalten werden. Eine Studie des US-Amerikanischen Marktforschungsinstitutes Forrester belegt, dass über 60% aller IT-Projekte nicht planmäßig abgeschlossen und mindestens einer der genannten Faktoren nur bedingt erfüllt werden (Sandhaus et al., 2015, S. 306).

Durch den Einsatz von Vorgehensmodellen soll die Komplexität der Entwicklungsprojekte beherrschbar werden, indem die Entwicklungstätigkeiten transparent und besser kontrollierbar werden. Hierdurch kann der Entwicklungsprozess planbar, nachvollziehbar und übersichtlicher gestaltet werden (Höhn Höppner 2008, S. 4).

Fragen wie „Was ist zu tun?“ (Produkte), „Wie ist etwas zu tun?“ (Entwicklungst ä tigkeiten) und „Womit ist etwas zu tun?“ (Rollen) können im Rahmen des Entwicklungsprozesses standardisiert beantwortet werden. Ein standardisiertes Handeln mittels Vorgehensmodelle trägt dazu bei, Projektrisiken zu minimieren. Abweichungen in der Planung und Risiken können früh erkannt werden und Prozesse lassen sich gut steuern. Es wird unter Anderem sichergestellt, dass Produkte vollständig und in der gewünschten Qualität entwickelt werden (Höhn Höppner 2008, S. 4) (Broy Rausch 2005, S. 221).

Es existiert heute eine Vielzahl diverser Vorgehensmodelle für IT-Projekte. Diese lassen sich weitestgehend in zwei grundsätzliche Kategorien unterteilen. Der klassische und der agile Ansatz. Beide Ansätze verfolgen dabei unterschiedliche Methoden und Philosophien bei der Entwicklung. Bereits Gregor Sandhaus et al. (2015) haben eine Vereinbarkeit der beiden Ansätze in dem Werk Hybride Softwareentwicklung näher betrachtet und überprüft (S. 118).

Um eine Vereinbarkeit besser zu verstehen, ist es hilfreich, die beiden Ansätze an konkreten Beispielen näher zu beleuchten. Als konkrete Vertreter der klassischen Welt wird das V-Modell XT und aus der agilen Welt Scrum untersucht. Scrum gilt unter Kostenaspekten und das V-Modell XT unter Qualitätsaspekten als eine jeweils effiziente Entwicklungsmethode. (Maximini 2013, S. 91) (Friedrich et al., 2009, S. 89)

Diese Seminararbeit knüpft an die Forschungsrichtung der genannten Publikationen an und soll die Frage beantworten, inwieweit sich das Konzept von Scrum mit den Rahmenbedingungen des V- Modell XT vereinbaren lässt. Zur Beantwortung dieser Frage werden beide Modelle systematisch auf eine sinnvolle Kombination analysiert und eine konkrete Lösung ausgearbeitet. Was zu vermeiden gilt, ist das Scrum und V-Modell XT parallel verwendet werden. Beispielsweise das Scrum intern angewendet und in Richtung Auftraggeber die Einhaltung des V-Modell XT vorgegeben wird.

Um die Zielsetzung umsetzen zu können ist die Seminararbeit wie folgt aufgebaut:

- In Kapitel 2 - „ Entwicklungsans ä tze im Vergleich “ werden Vorgehensmodelle aus der agilen und der klassischen Entwicklung untersucht.

- In Kapitel 0 - „ Hybrider Ansatz - Erfolgreiche Kombination von klassischer und agiler Welt “ werden die Bedingungen für eine hybride Lösung inklusive einer möglichen Lösung herausgearbeitet.

- In Kapitel 4 - „ Zusammenfassung “ erfolgen die Zusammenfassung der Ergebnisse sowie der Ausblick.

2 Entwicklungsansätze im Vergleich

Dieses Kapitel gibt eine Einführung in das V-Modell XT - einem Vertreter der klassischen Welt - sowie in die agile Welt von Scrum.

2.1 V-Modell XT - Vertreter der klassischen Welt

Das V-Modell XT wurde im Jahr 2005 veröffentlicht. Es stellt gerade für öffentliche Auftraggeber in Deutschland ein Standard für Softwareentwicklungsprojekte dar. XT ¹ ist eine Kurzform für engl. Extreme Tailoring und steht für die projektspezifische Anpassung des V-Modells (Friedrich et al., 2004,

S. 6). Durch das sog. Tailoring wird eine Möglichkeit geboten, die Projektdurchführung unter Einhaltung von bestimmten Bedingungen flexibel an das Entwicklungsprojekt anzupassen (Friedrich et al., 2004, S. 27). Die sog. Vorgehensbausteine bilden die Grundlage für die Prozesserarbeitung bzw. - anpassung. Diese Bausteine verknüpfen Produkte, Aktivitäten und Rollen (Friedrich et al., 2004, S.

4). Durch die Möglichkeit des Tailoring kann jeder Vorgehensbaustein einzeln verändert, erweitert und flexibel zusammengestellt werden. Jeder Vorgehensbaustein kann als ein Teilprozess im Projekt betrachtet werden und beschreibt welches Produkt (Was), durch welche Aktivität (Wie) mit Hilfe welcher Rolle (Wer) erbracht wird (Friedrich et al., 2004, S. 6). Zur Projektfortschrittskontrolle erfolgt die Unterteilung des Entwicklungsprojektes mit Hilfe von sog. Entscheidungspunkten. Unter einem Entscheidungspunkt ist eine Art Meilenstein im Projektverlauf zu verstehen, zu dem geprüft wird, ob ein Projektabschnitt erfolgreich abgeschlossen und der nächste Projektabschluss begonnen werden kann (Friedrich et al., 2004, S. 5ff) (Höhn Höppner 2008, S. 6ff). Im Rahmen der Qualitätssicherung werden aber bestimmte Entwicklungsschritte als sog. V-Modell-Kern vorgeschrieben und sollen nicht weggelassen werden (Höhn Höppner 2008, S. 11). Die grauen Bestandteile, wie in Abbildung

2 visualisiert, beinhalten die Vorgehensbausteine, welche für die Systementwicklung benötigt werden, inklusive derer dem Projektstart und -ende. (Höhn Höppner 2008, S. 7).

Abbildung in dieser leseprobe nicht enthalten

Abbildung 2 V-Modell XT (Broy Rausch 2005, S. 225)

Die Reihenfolge der Entscheidungspunkte wird von der sog. Projektdurchf ü hrungsstrategie ² (Wann) vorgegeben (Höhn Höppner 2008, S. 7).

Das V-Modell XT erlaubt mehrere Projektdurchführungsstrategien wie bspw. eine inkrementelle, komponentenbasierte und agile Systementwicklung. Für jeden Projekttyp ist definiert, welche Vorgehensbausteine und welche Projektdurchführungsstrategien für dieses Projekt relevant sind (Höhn Höppner 2008, S. 7f.).

Die hybride Lösung wird auf den Projekttyp Systementwicklung (AN, kurz f ü r Auftragnehmer) zugeschnitten, zumal es sich hier um die gängigste Durchführungsstrategie für die iterative Entwicklung handelt. Das V-Modell XT erlaubt das Durchlaufen des Entwicklungsprojektes in Iterationen, welche mit der Lieferung eines Teilsystems enden. In jeder Iteration werden Anforderungen ausgewählt und umgesetzt, bis alle Anforderungen berücksichtigt und das System vollständig umgesetzt wurde. Wichtig ist anzumerken, dass der Projekttyp Inkrementelle Systementwicklung kein striktes Folgen von Analyse, Design, Entwicklung sowie Test vorschreibt und damit im Umkehrschluss eine sequenzielle Abfolge von Entwicklungsaktivitäten erlaubt. Die Entwicklungsschritte können dementsprechend parallel ablaufen. Ein Entscheidungspunkt kann aber erst endgültig überprüft werden, wenn die Produktergebnisse des vorigen Entscheidungspunktes vollständig vorliegen (Friedrich et al., 2004, S. 20) Das V-Modell XT erlaubt dementsprechend eine gewisse Parallelität der Entwicklungsaktivitäten. Entwicklungsaufgaben können bereits begonnen werden, auch wenn der Entscheidungspunkt noch nicht erreicht wurde (Höhn Höppner 2008, S. 445f.). Die endgültige Überprüfung erfolgt erst dann, wenn die Produkte aus dem Entscheidungspunkt vollständig vorhanden sind. Diese Entscheidungspunkte sind auch als Quality Gate bekannt (Höhn Höppner 2008, S. 55).

2.2 Scrum - Vertreter der agilen Welt

Scrum ist ein flexibles, iteratives und inkrementelles Vorgehen mit Schwerpunkt auf Flexibilität und maximalem Kundennutzen (Brandstäter 2013, S. 36). Der Scrum Guide schreibt die essentiellen Bestandteile (Rollen, Artefakte und Ereignisse) vor (Sutherland Schwaber 2014, S. 135). Die Idee von Scrum ist die Kundenanforderungen zu sammeln und diese schrittweise abzuarbeiten. Zu diesem Zweck besitzt Scrum drei Rollen:

- Product Owner ³
- Scrum Master ⁴
- Entwicklungsteam ⁵

Anforderungen werden in einer Liste, dem sog. Product Backlog ⁶ erstellt, geändert und entsprechend priorisiert. Diese Liste ist in ständiger Veränderung. In einer Iteration, dem sog. Sprint, wird ein Arbeitspaket in kleinere Pakete in einer weiteren Liste, dem sog. Sprint Backlog ⁷ heruntergebrochen. Zu Beginn eines Sprints wird durch das Team das Sprint Backlog erstellt und mit sämtlichen Anforderungen vom Product Owner verantwortet. Der Sprint Backlog stellt einen Plan dar, welcher beschreibt, welche neue Funktionalität in dem Sprint umzusetzen ist. Um diese Umsetzung zu planen erfolgt ein von dem Scrum Master geführtes Sprint Planning Meeting ⁸. Der Sprint Backlog stellt einen Plan dar, welcher beschreibt welche neue Funktionalität in dem Sprint umzusetzen ist. Um diese Umsetzung zu planen erfolgt ein von dem Scrum Master geführtes Sprint Planning Meeting. Im Sprint wird eine neue, vorher definierte Funktionalität in einem festgelegten Zeitrahmen erstellt. Im sog. Daily Scrum ⁹ wird in wenigen Minuten die Arbeit des Entwicklungsteams abgeglichen. Der Scrum Master stellt in diesem kurzen Meeting sicher, dass Anforderungen erfolgreich umgesetzt werden. Im Sprint Review ¹⁰ wird die neue Funktionalität geprüft und in der Sprint Retroperspektive Maßnahmen ausgearbeitet, dass zukünftige Sprints noch effizienter ablaufen. Das Product Backlog wird nach Bedarf angepasst, neue Anforderungen können aufgenommen bzw. bestehende Anforderungen angepasst werden (Maximini 2013, S. 23ff.) (Goll Hommel 2015, S. 10). Das Entwick- lungsteam organisiert sich selbst bei der Bearbeitung der Tasks aus dem Sprint Backlog. Damit die Qualität der Entwicklungsergebnisse sichergestellt werden kann, wurde die sog. Definition of Done eingeführt, welche eine Voraussetzung darstellt, dass eine Anforderung als realisiert gilt. Nach jedem Sprint wird ein funktionsfähiges Teilsystem inklusive Test und notwendiger Dokumentation geliefert, welches sich dem Gesamtsystem nach und nach annähert (Sobiech 2016, S. 74) (Goll Hommel 2015, S. 96).

3 Hybrider Ansatz -Erfolgreiche Kombination von klassischer und agiler Welt

Dieses Kapitel soll die Frage nach der Vereinbarkeit von V-Modell XT und Scrum klären. Hiermit ist der erste Grundstein für den hybriden Ansatz geschaffen. In wie weit das V-Modell XT und Scrum miteinander kombiniert werden können um einen Mehrwert zu schaffen, wird im weiteren Verlauf dieses Kapitels verstärkt untersucht.

3.1 Klassische und agile Welt vereint

Beide Ansätze haben Ihre Existenzberichtigung und scheinen auf den ersten Blick nicht komplett unvereinbar. Beispielsweise erlauben beide Vorgehensmodelle ein inkrementelles Vorgehen (Friedrich et al., 2004, S. 19) (Goll Hommel 2015, S. 76). Die Idee, das V-Modell XT und Scrum zu kombinieren, hilft dabei zwei Welten, welche irrtümlich als schwer vereinbar gelten, zu verbinden. Hofstetter und Jud erläutern, warum agiles, iteratives Vorgehen in Software-Projekten essentiell ist, aber auch, was Scrum fehlt (Hofstetter Jud 2013, S. 133). Im Gegensatz zum V-Modell XT wird durch Scrum folgendes nur marginal abgedeckt oder ist nur bedingt geeignet:

- „[N]euartige, große Systeme, für die zuerst eine Systemarchitektur entworfen werden muss“ (Hofstetter Jud 2013, S. 135).
- „[K]omplexe Ausgangslagen, die eine vorgängige Situations- und Anforderungsanalyse er- fordern“ (Hofstetter Jud 2013, S. 135).
- „Softwareprojekte im Rahmen technischer Produktentwicklung“ (Hardware/Software CoEnt- wicklung)“ (Hofstetter Jud 2013, S. 135).

Der erste Grund, der für eine mögliche Kombination spricht, ist das gemeinsame Ziel, IT-Projekte erfolgreich durchzuführen. Die Ansätze unterscheiden sich lediglich in der Art dieses Ziel zu errei- chen. Während das V-Modell XT ziel- und ergebnisorientiert vorgeht, verfolgt der agile Ansatz von Scrum ein Handeln nach dem sog. agilen Manifest (Goll Hommel 2015, S. 13). Genau dieses ergeb- nisorientierte Vorgehen von V-Modell XT schafft eine Voraussetzung für eine mögliche Kombination, indem es wenig Vorgaben gibt, wann und in welcher Reihenfolge Entwicklungsaktivitäten durchzu- führen sind (Friedrich et. al, 2009, S. 48 und S. 79) (Höhn Höppner 2008, S. 7). Einschränkungen entstehen lediglich durch eventuelle Produktabhängigkeiten im Rahmen von V-Modell XT (Höhn Höppner 2008, S. 7). Es soll kein vollkommen neues Modell geschaffen werden, denn die agilen Scrum-Bestandteile sind für eine erfolgreiche Kombination in den Rahmen von V-Modell XT zu in- tegrieren (Sandhaus et al., 2015, S. 118).

Wenn man Scrum in den V-Modell XT-Rahmen integrieren möchte, ist es notwendig, die Unterschiede von V-Modell XT und Scrum zu analysieren. Der Unterschied zwischen der klassischen und agilen Welt soll nicht nur überwunden, sondern die Unterschiede bestmöglich kombiniert werden. Doch was sind die angedeuteten Unterschiede des klassischen und agilen Vorgehensmodells? Um dies zu beantworten, werden einige Unterschiede in Tabelle 1 visualisiert:

Tabelle 1 Komponenten V-Modell XT und Scrum

Eigene Darstellung in Anlehnung an (Schuh 2004, S. 346) (Nerur, Sridhar et al., 2005, S. 72ff.) (Conboy et al., 2011, S. 48ff.) (Boehm, Barry W, Turner, Richard 2004, S66ff.)

Abbildung in dieser leseprobe nicht enthalten

Tabelle 1 zeigt, dass V-Modell XT und Scrum sich in wichtigen Komponenten in der Vorgehensweise unterscheiden.

In der Literatur bestehen einige Uneinigkeiten in Bezug auf die Vereinbarkeit von agilen und klassi- schen Vorgehensmodellen. Cohn (2010) gibt zu verstehen, dass dieser nicht an die Möglichkeit glaube, agile und klassische Vorgehensmodelle parallel nutzen zu können. Dauerhaft wird das Ent- wicklungsteam wieder in alte Denkmuster verfallen und der Mehrwert wird somit nichtig (S. 423). 2014 legten Sandhaus et al. mit zwei Fallstudien die Praxistauglichkeit von hybriden Lösungen dar (S. 118). Welche Aussage aus den Publikationen entspricht nun der Wahrheit und kann als Grund- lage für die weitere Untersuchung über die Vereinbarkeit von agiler und klassischer Welt genutzt werden? Unter den bereits gesammelten Erkenntnissen kann vermutet werden, dass die Aussage von Cohn in einem gewissen Rahmen einer plakativen Aussage entspricht. Welche agilen und wel- che klassischen Vorgehensmodelle seiner Ansicht nach als nicht vereinbar gelten, wird nicht weiter ausgeführt (Cohn 2010, S. 423). Sandhaus et al. (2014) erörtern im Gegenzug durch Fallstudien konkrete Beispiele, wo ein Mehrwert durch eine Kombination entsteht (S. 118). Daraus lässt sich schließen, dass nicht jedes klassische oder agile Vorgehensmodell sich dazu eignet, ein hybrides Vorgehen zu bilden. Somit kann festgehalten werden, dass beide Autoren in Ihrer Aussage Recht

[...]

¹ XT: Kurz für Extreme Tailoring.

² Projektdurchf ü hrungsstrategie: Rahmen für eine geordnete und nachvollziehbare Projektdurchführung (Höhn Höppner 2008, S. 7).

³ Product Owner: Er nimmt die Sichtweise des Kunden ein. Weiterhin erfasst, schätzt und priorisiert die Anforderungen verwaltet diese in einem sog. Product Back log (Goll Hommel 2015, S.84 und 88f).

⁴ Scrum Master: Prozessverantwortlicher welcher sicherstellt, dass Scrum als Prozess eingehalten wird (Canditt et. al. 2011, S. 5).

Seite 4

⁵ Entwicklungsteam: Entwickelt die Software und organisiert sich selbst ohne den klassischen Projektleiter aus dem V-Modell XT (Goll Hommel 2015, S. 88ff.).

⁶ Product Backlog: Verwaltung der Anforderungen. Es handelt sich um lebendes Dokument und wird ständig aktualisiert (Hanser 2010, S. 73).

⁷ Sprint Backlog: Plan des Entwicklerteams welche Anforderungen im Sprint abgearbeitet werden sollen (Hanser 2010, S. 75).

⁸ Sprint Planning Meeting: Legt die Ziele des nächsten Sprints fest (Goll Hommel 2015, S. 93f.).

⁹ Daily Scrum: Kurze tägliche Teamsynchronisierung um bspw. Entwicklungsprobleme zu beheben (Goll Hommel 2015, S. 9).

¹⁰ Sprint Review: Überprüfung der Softwareteillösung nach jedem Sprint (Goll Hommel 2015, S. 10).

Seite 5

[...]