Projektarbeit Das Planungskonzept in Scrum im Vergleich zu ...€¦ · Projektarbeit Das Planungskonzept in Scrum im Vergleich zu allgemeinen Ansätzen der iterativen Projektplanung

Projektarbeit

Das Planungskonzept in Scrum

im Vergleich zu allgemeinen Ansätzen

der iterativen Projektplanung

Studiengang: Produktion und Prozessmanagement

Betreuer: M.Sc. Matthias Albert

Verfasser/-in: Carina Schönberger (Matr.-Nr.: 185933)

Michael Thomas (Matr.-Nr.: 185399)

Kontaktdaten: [email protected]

Abgabedatum: 05. Oktober 2016

I

Inhaltsverzeichnis

1 Einleitung ............................................................................................................. 1

2 Vorgehensmodelle............................................................................................... 2

2.1 Iterativer Planungsansatz .............................................................................. 4

2.2 Inkrementeller Planungsansatz ..................................................................... 6

2.3 Iterativ-inkrementeller Planungsansatz .......................................................... 6

3 Scrum .................................................................................................................. 7

3.1 Werte und Prinzipien von Scrum ................................................................... 8

3.2 Scrum Flow und der Sprint ............................................................................ 9

3.3 Rollen .......................................................................................................... 12

3.3.1 Product Owner ...................................................................................... 12

3.3.2 Entwicklungsteam ................................................................................. 14

3.3.3 Scrum-Master ....................................................................................... 15

3.4 Meetings ...................................................................................................... 16

3.4.1 Sprint Planning ...................................................................................... 16

3.4.2 Daily Scrum ........................................................................................... 18

3.4.3 Sprint Review ........................................................................................ 19

3.4.4 Retrospektive ........................................................................................ 20

3.5 Artefakte ...................................................................................................... 20

3.5.1 Product Backlog .................................................................................... 21

3.5.2 Sprint Backlog ....................................................................................... 22

3.5.3 Inkrement .............................................................................................. 22

3.5.4 Definition of Done ................................................................................. 22

4 Iterativ-inkrementelle Vorgehensmodelle .......................................................... 23

4.1 Spiralmodell ................................................................................................. 23

4.2 Extreme Programming ................................................................................. 24

II

4.3 Feature-Driven-Development ...................................................................... 26

5 Scrum im Vergleich zu iterativen Vorgehensmodellen ...................................... 29

5.1 Vergleich: Scrum – Spiralmodell.................................................................. 29

5.2 Vergleich: Scrum – Extreme Programming ................................................. 31

5.3 Vergleich: Scrum – Feature-Driven-Development ....................................... 34

5.4 Zusammenfassende Darstellung der Ergebnisse ........................................ 37

6 Zusammenfassung ............................................................................................ 39

7 Fazit ................................................................................................................... 40

Literaturverzeichnis .................................................................................................... V

III

Abbildungsverzeichnis

Abbildung 1: Darstellung wiederholender Modelle ...................................................... 3

Abbildung 2: Darstellung wiederverwendbarer Modelle .............................................. 4

Abbildung 3: Darstellung Iterationsschleife ................................................................. 4

Abbildung 4: Abfolge von Iterationsschleifen .............................................................. 5

Abbildung 5: Scrum Prozess-Ablauf ......................................................................... 10

Abbildung 6: Ablauf Spiralmodell .............................................................................. 23

Abbildung 7: Extreme Programming Prozess-Ablauf ................................................ 25

Abbildung 8: Feature Driven Develeopment Phasenablauf ...................................... 27

IV

Tabellenverzeichnis

Tabelle 1: Spezifische und nicht spezifische Merkmale von Scrum .......................... 38

1 Einleitung

1

1 Einleitung

Im Rahmen des Studiums im Studiengang Produktion und Prozessmanagement soll

eine Projektarbeit verfasst werden, bei der die Studenten eine speziell hierfür ausge-

wählte Problemstellung bearbeiten. Ihr Vorgehen sowie die Ergebnisse sollen dabei

in einer wissenschaftlichen Arbeit, wie der vorliegenden, dokumentiert werden. Ziel

dieses Studienbausteins ist es, die Studenten an die Arbeit im Team weiter heranzu-

führen und ihre Kenntnisse im Verfassen von wissenschaftlichen Arbeiten zu vertie-

fen. Außerdem wird die Möglichkeit geboten, bereits erworbene Kenntnisse im Be-

reich des Projektmanagements anzuwenden. Die vorliegende Projektarbeit beschäf-

tigt sich mit folgendem Thema: „Das Planungskonzept in Scrum im Vergleich zu all-

gemeinen Ansätzen der iterativen Projektplanung“. Die Aufgabenstellung besteht

dabei aus folgenden Aspekten:

dem literaturgestützten Herausarbeiten typischer Merkmale und Prämissen des

Scrum-Planungsansatzes

dem Recherchieren und Auswerten zitierwürdiger Fachquellen zu allgemeinen

Merkmalen iterativer Vorgehensmodelle

dem Beantworten der Frage, welche Merkmale spezifisch für Scrum sind oder

auch unabhängig von Scrum ihre Berechtigung haben

Dieser Aufgabenstellung entsprechend werden in der vorliegenden Arbeit zunächst

der iterative Planungsansatz und im darauffolgenden Schritt die typischen Merkmale

von Scrum herausgearbeitet.

Um ein grundlegendes Verständnis für den iterativen Planungsansatz erlangen zu

können, wird zu Beginn des zweiten Kapitels die Einordnung des iterativen Pla-

nungsansatzes in die vorhandenen Vorgehensmodelle und Planungsansätze vorge-

nommen. Darauf folgt die Erläuterung des iterativen Planungsansatzes. Im Laufe der

Arbeit wird sich zeigen, dass dem inkrementellen Planungsansatz hierbei eine tra-

gende Rolle zukommt, da er eng in Verbindung mit dem iterativen steht. Aufgrund

dessen wird im zweiten Kapitel auf diesen ebenfalls eingegangen. Im dritten Kapitel

folgt die Erarbeitung der typischen Merkmale und Prämissen von Scrum. Analog zu

den obigen Ausführungen, wird im vierten Kapitel ferner auf die iterativ-

inkrementellen Vorgehensmodelle eingegangen. Abschließend erfolgt im letzten Ka-

pitel der Arbeit der Vergleich zwischen Scrum und den vorgestellten iterativen Vor-

gehensmodellen.

2 Vorgehensmodelle

2

2 Vorgehensmodelle

Im kompetenzbasierten Projektmanagement wird zwischen drei grundlegenden Mo-

dellen unterschieden, die im Laufe dieses Kapitels vorgestellt werden:

Sequentielle Modelle: Zu dieser Kategorie zählen Phasen-, Wasserfall- und

Schleifenmodelle.

Wiederholende Modelle: Zu dieser Modellklasse zählen die inkrementellen,

iterativen, rekursiven und evolutionären Modelle.

Wiederverwendende Modelle: Modelle dieser Kategorie sind darauf ausgerich-

tet, bestehende Module zu recyceln sowie in der Entwicklung auf die erneute

Verwendbarkeit hin zu arbeiten.

(vgl. Gessler, 2014, S. 362)

Sequentielle Modelle

Merkmal dieser Modellfamilie ist die Voraussetzung, dass alle Aktivitäten einer Phase

vollständig abgeschlossen sein und die erforderlichen Ergebnisse vorliegen müssen,

bevor in die nächste Phase übergegangen werden darf. Die Ergebnisse der vorher-

gehenden Phase dienen dabei als Arbeitsgrundlage für die darauffolgende Phase.

Das Wasserfallmodell ist hierbei als führendes Modell zu nennen. Dabei sind Rück-

schritte in die vorherige Phase zwar erlaubt, allerdings nur, um begangene Fehler zu

korrigieren. Voraussetzung für die Anwendung eines sequentiellen Vorgehensmo-

dells sind stabile Anforderungen und klare Zieldefinitionen. Sind diese nicht gegeben,

wird das Projekt unter Anwendung eines sequentiellen Modells scheitern. Grund hier-

für ist, dass im Rahmen dessen kaum flexibel agiert werden kann. Für diesen Fall

wären wiederholende Modelle besser geeignet, die im folgenden Abschnitt näher

erläutert werden. (vgl. Gessler, 2014, S. 362)

Wiederholende Modelle

Bei dem wiederholenden Vorgehen wird ein Projekt nicht in sequentiellen Phasen

bearbeitet, sondern in kleinen Teilmengen (Inkremente) nacheinander abgearbeitet.

Dabei durchläuft ein Inkrement (Teilmenge der Gesamtanforderung) alle zur Fertig-

stellung erforderlichen Phasen (Analyse, Entwurf, Implementierung, etc.), bevor ein

weiteres Inkrement bearbeitet wird. Im Zuge dessen wird die Komplexität mit jedem

2 Vorgehensmodelle

3

Inkrement erhöht. Dieses Vorgehen ist schematisch in folgender Abbildung darge-

stellt:

Der große Vorteil wiederholender Modelle liegt darin, dass Teilprodukte bereits früh

fertiggestellt sind. Das heißt, im Falle einer Terminverschiebung könnten zumindest

diese Teilprodukte ausgeliefert werden.

Wie bereits beschrieben, werden wiederholende Modelle überwiegend dann ange-

wendet, wenn Anforderungen instabil sind beziehungsweise Ziele nur vage definiert

werden können. „In diesem Fall könnte z. B. mit den sichersten Anforderungen be-

gonnen werden, um dann mit wachsender Erfahrung Sicherheit zu gewinnen. Not-

wendig ist jedoch, dass die Anforderungen in Teilmengen untergliederbar und diese

möglichst wenig voneinander abhängig sind.“ (Gessler, 2014, S. 363)

Aus dieser Modellfamilie lässt sich das Spiralmodell von Boehm (1988) als zentral

bezeichnen. Dieses ist in vier Quadranten unterteilt, welche immer wieder durchlau-

fen werden.

Wiederverwendbare Modelle

Wiederverwendende Modelle zielen darauf ab, die erzielten Ergebnisse für andere

Projekte wiederverwendbar zu machen. Um die Ergebnisse allerdings so aufbereiten

zu können, dass sie wiederverwendbar werden, ist ein zusätzlicher Aufwand von Nö-

ten. In dieser Modellfamilie wird ergänzend dazu mit Ergebnissen aus vorhergehen-

den Projekten gearbeitet. Dieses Vorgehen wird mit Hilfe der nachfolgenden Grafik

verdeutlicht:

Abbildung 1: Darstellung wiederholender Modelle, Quelle: Gessler, 2014

2 Vorgehensmodelle

4

Durch das Zurückgreifen auf Erfahrungen aus anderen Projekten können Prototypen

schneller entwickelt werden. „Nachteilig kann sein, dass wiederverwendete Ergeb-

nisse, wenn sie nicht ausreichend passend sind, die Komplexität erhöhen und zudem

anzupassen sind.“ (Gessler, 2014, S. 364)

2.1 Iterativer Planungsansatz

Der iterative Planungsansatz besteht aus dem Grundsatz, ein Produkt in mehreren

Iterationsschleifen zu erarbeiten. Eine Iteration besteht dabei, wie in folgender Abbil-

dung ersichtlich, aus den Aktivitäten „Analysieren“, „Entwerfen“, „Codieren“ und „Tes-

ten“. (vgl. Hörger, 2010)

In jeder Iteration findet zum selben Zeitpunkt ein Meeting statt, bei dem die Ergebnis-

se der Iteration besprochen werden. Bereits am Ende der ersten Iterationsschleife

muss ein Ergebnis vorliegen, das die spätere Lösung in ihren Grundzügen beinhaltet.

Dieses Ergebnis wird in den nachfolgenden Iterationen weiter optimiert und erweitert,

so lange bis in der letzten Iteration die Lösung vorliegt. „Gleichzeitig fließen die Er-

fahrungswerte einer Iteration in den nächsten Iterationsschritt mit ein. Es findet also

Abbildung 3: Darstellung Iterationsschleife

Abbildung 2: Darstellung wiederverwendbarer Modelle, Quelle: Gessler, 2014

2 Vorgehensmodelle

5

eine stetige Verbesserung des Prozesses statt.“ (Hörger, 2010, S. 3) Dies wird in

folgender Grafik verständlich.

Der Nutzen des iterativen Planungsansatzes liegt in der Möglichkeit, das Projekt je-

derzeit nach einer beliebigen Iteration zu beenden. Ist beispielsweise der Auftragge-

ber mit dem Ergebnis einer Iteration bereits vollständig zufrieden, kann er das Projekt

vorzeitig als abgeschlossen erklären.

Der iterative Planungsansatz findet häufig dann Anwendung, wenn ein Projekt nicht

auf Basis klarer Ziele geplant und gesteuert werden kann. Dazu lassen sich folgende

beispielhafte Vorgehensweisen beschreiben:

Es handelt sich um ein Softwareprojekt, dessen Ziele nur vage formuliert sind und

sich häufig ändern. Der Projektmanager geht hierbei also nach dem iterativen Vorge-

hen vor und lässt das Projekt mehrere Iterationsschleifen durchlaufen. Innerhalb je-

der Schleife werden die Ziele dabei überarbeitet und an alle Betreffenden kommuni-

ziert. (vgl. Gessler, 2014, S. 31)

Genauso trifft diese Vorgehensweise auf die Erstellung eines Lastenhefts zu. Dieses

wird meist vom Auftraggeber verfasst. Dabei „ist (es, d. Verf.) durchaus üblich, dass

in einem iterativen Vorgehen mehrere Versionen nacheinander und mit wachsendem

Kenntnisstand über das Projekt verfeinert ausgearbeitet werden, bis schließlich die

gewünschte Endgenauigkeit erreicht ist.“ (Gessler, 2014, S. 340)

Erstmals angewandt wurde das iterative Vorgehen bei der Entwicklung der US-

Militär-Standards DoD-STD-2167 im Jahre 1970. Dieses erste iterative Vorgehens-

modell wurde von Winston Royce publiziert. Die erfolgreich entwickelten US-Militär-

Abbildung 4: Abfolge von Iterationsschleifen

2 Vorgehensmodelle

6

Standards deuten auf den Erfolg hin, zu dem dieses Modell verhilft. Auch David Mai-

bor, der den Grundstein für das Wasserfallmodell legte, dementierte Jahre später,

„dass er, wäre er damit damals vertrauter gewesen, das iterative Vorgehen im STD-

2167 (US-Militärstandard) viel deutlicher empfohlen hätte.“

(Oestereich & Weiss, 2008, S. 12)

2.2 Inkrementeller Planungsansatz

Der inkrementelle Planungsansatz unterscheidet sich insofern vom iterativen, als

hierbei das Endprodukt und -ergebnis in Teilergebnisse zerlegt wird und diese nach-

einander erarbeitet werden. Ein Grundprodukt wird also schrittweise um weitere In-

kremente (Teilergebnisse) ergänzt. Die große Gefahr beim inkrementellen Vorgehen

besteht darin, dass gegen Ende des Projekts immer mehr Funktionen gewünscht

werden könnten und das Projekt somit nur noch schwer abgeschlossen werden kann

(vgl. Lieder, 2008)

2.3 Iterativ-inkrementeller Planungsansatz

Bei dem iterativ-inkrementellen Planungsansatz werden die beiden genannten Vor-

gehensweisen kombiniert. „Größere Funktionspakete werden inkrementell nachei-

nander abgearbeitet. Gerade bei größeren Paketen ist es von Vorteil, eine frühe

funktionierende aber einfache Version dem Kunden zum Testen zu übergeben, bevor

man diese iterativ weiterentwickelt.“ (Dräther, u.a., 2013, S. 137) So kann der Auf-

traggeber bereits bei der ersten Iteration seine Meinung miteinbringen und somit teu-

re Änderungen zu späteren Zeitpunkten verhindert.

Auffallend ist, dass bekannte Vorgehensmodelle häufig eine Kombination aus beiden

Planungsansätzen vereinen. Dies gilt beispielsweise auch für das Spiralmodell nach

Boehm, das von manchen Autoren als iteratives Vorgehen und von anderen als in-

krementell-iteratives Vorgehen beschrieben wird

(vgl. Rumpe, 2001; Oestereich & Weiss, 2008, S. 13)

3 Scrum

7

3 Scrum

Im folgenden Kapitel soll ein Einblick in den Planungsansatz von Scrum gegeben

werden. Dabei soll aufgezeigt werden, was diese Methode auszeichnet und welche

typischen Merkmale sie besitzt. Dazu findet in Kapitel 5 ein Vergleich zu weiteren

iterativen Vorgehensmodellen statt, um Merkmale herauszuarbeiten, die spezifisch

für Scrum sind.

Der Scrum Planungsansatz wird als ein Rahmenwerk bezeichnet, in dem verschie-

dene Prozesse und Techniken eingesetzt werden, um komplexe Aufgabenstellungen

zu lösen. Dadurch sind Scrum-Teams in der Lage, Produkte mit höchst möglichem

Wert und Kreativität zu entwickeln und diese auszuliefern. Die Scrum Methode ge-

hört der Gruppe der agilen Vorgehensmodelle an und wurde in den 1990er Jahren

von Ken Schwaber und Jeff Sutherland entwickelt. Sie erarbeiteten einen Leitfaden

mit verschiedenen Spielregeln, der als Scrum-Guide bezeichnet wird. Dieser wird

auch im folgenden Verlauf der vorliegenden Arbeit herangezogen. Die Scrum Metho-

de geht von der Prämisse aus, dass ein Softwareprojekt aufgrund seiner vorhande-

nen Komplexität nur bedingt durchgängig planbar ist. Die Scrum Methode versucht

daher, durch seine Vorgehensweise, diese Komplexität durch eine oder mehrere An-

nahmen zu vereinfachen. Diese Annahmen werden im Folgenden aufgeführt:

1. Transparenz: Der Status des Projekts wird in täglichen Meetings innerhalb ei-

nes Sprints dauerhaft erfasst und kontrolliert.

2. Überprüfung: In regelmäßigen Abständen werden die Produktinkremente ge-

liefert, kontrolliert sowie beurteilt.

3. Anpassung: Die Anforderungen an ein Produkt werden nicht unwiderrufbar

festgelegt, sondern können auch während eines Projekts noch angepasst und

verändert werden.

(vgl. Schilling, 2016)

Diese Vorgehensweise für Scrum erlaubt es, auch sehr komplexe Projekte zu meis-

tern. Scrum besteht allerdings nicht nur aus einem Planungsansatz, sondern ver-

wendet eine Mischung des iterativen und inkrementellen Ansatzes. Ergänzend dazu

zeichnet die Scrum Methode außerdem die stetige Weiterentwicklung und Verbesse-

rung von Prozessen, Methoden und Mitarbeitern aus, um eine dauerhaft hohe Quali-

tät zu gewährleisten. Dabei unterliegt Scrum immer den Grundsätzen des Agilen Ma-

nifests:

3 Scrum

8

1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.

2. Funktionierende Programme sind wichtiger als ausführliche Dokumentation.

3. Die stetige Abstimmung mit dem Kunden ist wichtiger als die ursprüngliche

Leistungsbeschreibung in Verträgen.

4. Der Mut und die Offenheit stehen über dem Befolgen eines festgelegten

Plans.

„Die folgenden Rollen, Artefakte und Methoden von SCRUM stellen eine Implemen-

tierung dieser Grundsätze und Annahmen dar.“ (Hörger, 2010) Scrum bietet als

Rahmenwerk demnach kein striktes Vorgehen nach diesen Regeln, sondern sie las-

sen sich je nach Situation an das Projekt anpassen.

3.1 Werte und Prinzipien von Scrum

Im Folgenden soll näher auf die Werte und Prinzipien von Scrum eingegangen wer-

den. Diese stellen grundlegende Eigenschaften dar, um ein erfolgreiches Einsetzen

der Scrum-Methode ermöglichen zu können. Laut Scrum-Guide werden keine explizi-

ten Werte für Scrum genannt, jedoch beschreiben Ken Schwaber und Mike Beedle in

ihrem Buch fünf Werte für Scrum. Für die Anwendung von Scrum sind diese Werte

ein wichtiger Bestandteil. Außerdem helfen sie dabei, Änderungen am Prozess zu

ermöglichen, da durch die Werte neue Handlungsmöglichkeiten erschlossen werden

können. Diese stetige Weiterentwicklung stellt einen zentralen Faktor im Vorgehen

dar. Im Folgenden werden die soeben umschriebenen fünf Werte aufgezeigt und

kurz erläutert:

Mut: Ist eine wichtige Eigenschaft, wenn man neue Wege gehen möchte und

nur durch neue Wege können Innovationen vorangetrieben werden – im Pro-

dukt sowie im Prozess.

Respekt: Um gemeinsame Lösungen erarbeiten zu können sowie für ein Mit-

einander, ist Respekt ein sehr grundlegender Wert. Nur dadurch gelingt es,

Bedürfnisse und Interessen von vielen Beteiligten berücksichtigen zu können.

Ergänzend dazu ist Respekt eine Voraussetzung für Offenheit.

Commitment: Dieser Wert zielt auf die Selbstverpflichtung der Mitglieder an

einem gemeinsamen Ziel ab, an dem sie arbeiten wollen.

Offenheit: Alle Informationen müssen für jeden Projektbeteiligten bereitgestellt

und offengelegt werden. Es sollen keine Probleme oder Fakten verschleiert

werden.

3 Scrum

9

Fokus: Das Scrum-Team fokussiert sich voll auf die anstehenden Aufgaben.

Im Sprint soll fokussiert gearbeitet werden. Es soll sich mit voller Energie auf

die Aufgabe konzentriert werden, zu der man sich verpflichtet hat.

(vgl. Dräther, u.a., 2013, S. 32)

Die einzelnen Praktiken, die in Scrum eingesetzt werden, z.B. das Sprint Review

oder die Retrospektive, beruhen auf verschiedenen Prinzipien. In der vorhandenen

Fachliteratur zu Scrum lässt sich keine einheitliche Aussage darüber finden, welche

Prinzipien grundsätzlich verfolgt werden. Nachfolgend werden deshalb drei

ausgewählte Prinzipien vorgestellt, die für Scrum entscheidend sind.

Empirie:

Während eines Scrum Ablaufs werden stetig Daten erfasst, was es ermöglicht,

Verbesserungen zu erkennen und umzusetzten. Dadurch wiederum wird in Zukunft

ein effektiveres Arbeiten erreichbar. Dieses Prinzip findet in der Retrospektive seinen

Einsatz, die in Kapitel 3.4.4 näher beschrieben wird.

Emergenz:

Dises Prinzip beschreibt ein unerwartetes Auftreten von Faktoren, die die Qualität

beeinflussen können. Die Scrum-Methode reagiert darauf mit einer schrittweisen

Lösungsentwicklung. So können Erkenntnisse, die am Anfang noch nicht erkannt

wurden, auch später noch in das Produkt mit einfließen.

Selbstorganisation:

In Scrum arbeiten interdiziplinäre und selbstorganisierte Teams, die auf diese Weise

die Produktanforderungen umsetzten. Dabei geht es nicht nur um technologische

Fragen, sondern sie bestimmen auch selbstständig, welche Prozesse nötig sind, um

ein Produkt zu entwickeln. Dies wird bei der Beschreibung des Entwicklungsteams im

späteren Verlauf der Arbeit deutlich.

Auf weitere Prinzipien wird an dieser Stelle nicht eingegangen, da der Umfang der

Arbeit dies nicht zulässt.

(vgl. Dräther, u.a., 2013, S. 40)

3.2 Scrum Flow und der Sprint

Dieses Kapitel zeigt den grundlegenden Ablauf eines Scrum Prozesses auf sowie

Merkmale eines Sprints und dessen genauen Ablauf.

Der Prozessablauf von Scrum wird anhand der Abbildung 5 verdeutlicht.

3 Scrum

10

Am Anfang eines jeden Projekts steht eine Vision, wie ein Endprodukt aussehen

könnte. Anhand dieser Vision werden Eigenschaften abgeleitet, die das Produkt ha-

ben muss oder könnte. Diese Eigenschaften und Anforderungen werden in einem

Product Backlog dokumentiert und als Backlog Items bezeichnet. Durch einen Pro-

duct Owner werden diese Backlog Items priorisiert und geordnet. Danach kommt es

zur eigentlichen Iteration von Scrum, die auch Sprint genannt wird. Die Dauer eines

Sprints ist auf maximal einen Monat definiert. Zu Beginn und auch während eines

Sprints finden verschiedene Meetings statt, in denen festgelegt wird, was umgesetzt

werden soll und wie dies vonstattengehen soll. Das Ergebnis eines jeden Sprints wird

als Produktinkrement bezeichnet. Aufgrund der schrittweisen Erarbeitungsweise in

Scrum, ergeben alle Produktinkremente zusammen das fertige Endprodukt. Der ge-

naue Inhalt und die Merkmale eines Sprints werden im folgenden Abschnitt genauer

erläutert. (vgl. Roock & Wolf, 2016, S. 17 f.)

Der Sprint

Der Sprint wird sowohl als Herz von Scrum als auch als Iteration bezeichnet. Das Ziel

eines Sprints ist es, am Ende jeder Iteration ein potentielles auslieferbares Produk-

tinkrement zu erhalten. Ein Produktinkrement ist das umgesetzte Resultat, der im

Product Backlog festgelegten Anforderungen und muss immer am Ende eines jeden

Sprints nach der jeweiligen Definition of Done fertig sein. Die Definition of Done wird

in Kapitel 3.5.4 näher erläutert. Ein Sprint zeichnet sich durch eine festgelegte Län-

ge, eine einheitliche innere Struktur und ein definiertes Ergebnis aus. Die Länge ei-

nes Sprints wird im Vorfeld definiert. Dabei ist zu beachten, dass jeder Sprint inner-

halb eines Projekts die gleiche Dauer hat. Der Effekt aus dieser Regel ist, dass sich

Abbildung 5: Scrum Prozess-Ablauf

3 Scrum

11

ein Entwicklungsrhythmus bildet und daraus wiederum ein besseres Arbeitsergebnis

entwickeln kann. Verschiedene Untersuchungen haben gezeigt, dass sich bei einem

immer wiederkehrenden Takt, die Leistungsfähigkeit eines Teams enorm steigert.

Auf den Takt eines Sprints kann es verschiedene Einflussfaktoren geben, die beach-

tet werden müssen, z.B. Fehlzeiten von Mitgliedern durch Urlaube oder regelmäßi-

ges Abhalten von Meetings. Eine grundlegende Antwort auf die Frage, wie lange ein

Sprint dauern sollte, gibt es nicht. Allerdings sollte beachtet werden, dass ein zu lan-

ger Sprint das Risiko von unerwarteten Fehlern erhöhen kann. Das Entwicklungs-

team muss bei der Planung versuchen, weit in die Zukunft zu schauen. Dadurch

kann es zu Unsicherheiten kommen, die zu Beginn nicht erkennbar waren. Laut

Scrum-Guide sollte ein Sprint eine maximale Time Box von einem Monat und mini-

mal von einer Woche haben. Sollte während eines Sprints festgestellt werden, dass

die Dauer falsch bemessen wurde, kann diese für den nächsten Sprint angepasst

werden. Hier zeigt sich, was die Scrum-Methode ausmacht. Wie bereits erwähnt, sol-

len alle Sprints innerhalb eines Projekts die gleiche Länge haben. Allerdings bietet

die Scrum Methode ein Abweichen dieser Regeln an. Denn "Scrum verlangt nicht

das unreflektierte Befolgen von Regeln, sondern lässt Raum für das Anpassen des

Scrum-Frameworks an die Bedürfnisse des Projekts". (Dräther, u.a., 2013, S. 47)

Das oberste Ziel eines Sprints ist es, ein erfolgreiches Produktinkrement herzustellen

und falls Faktoren auftreten, die für dieses Ziel keinesfalls hilfreich sind, müssen An-

passungen vorgenommen werden. Deshalb kann für den nächsten Sprint eine An-

passung der im Vorfeld definierten Prämisse erfolgen. Es ist auch möglich einen

Sprint abzubrechen, wenn festgesellt wird, dass das Sprint-Ziel obsolet geworden ist.

Dies kann aufgrund verschiedener Gründe passieren: Beispielsweise kann das Un-

ternehmen neu ausgerichtet worden sein oder die Marktanforderungen haben sich

geändert. Dabei sollte allerdings immer bedacht werden, welche Folgen ein solcher

Abbruch hat: Dieser bringt eine hohe Ressourcenverschwendung mit sich und er-

gänzend dazu verliert die bereits erbrachte Leistung schnell an Wert. Im letzten Ab-

schnitt der Ausführungen zu den Sprints soll noch näher auf die verschiedenen Er-

eignisse und die Aufgabenverteilung innerhalb dieser eingegangen werden: In einem

Sprint finden verschiedene Ereignisse statt, um den Ablauf zu planen oder um den

aktuellen Status des Sprints ersichtlich zu machen. Zu Beginn jedes Sprits findet ein

Sprint Planning statt, am Ende ein Sprint Review und anschließend wird eine Retro-

spektive durchgeführt. Außerdem wird täglich ein Daily Scrum abgehalten. Die Inhal-

3 Scrum

12

te der einzelnen Meetings werden in Kapitel 3.4 erläutert. Die Aufgabenverteilung

innerhalb eines Sprints unterliegt ebenfalls einer klaren Ordnung. Das Entwicklungs-

team ist für die Umsetzung der Backlog Items verantwortlich. Der Product Owner un-

terstützt das Entwicklungsteam und erarbeitet schon während des aktuellen Sprints

die Backlog Items, die im nächsten Sprint umgesetzt werden sollen. Der Scrum Mas-

ter achtet darauf, dass der Status des Sprints ständig bekannt ist, dass Meetings

stattfinden und dass die in der Retrospektive erarbeiteten Verbesserungspotentiale

umgesetzt werden. Wenn ein Sprint komplett abgeschlossen ist, folgt direkt im An-

schluss immer der nächste Sprint. Dies hat den Vorteil, dass die Ergebnisse des vor-

herigen Sprints noch frisch in Erinnerung sind und wichtige Informationen nicht ver-

gessen werden. Deshalb sollte bei der Taktung eines Sprints darauf geachtet wer-

den, dass er mitten in der Woche beginnt und beendet wird.

(vgl. Dräther, u.a., 2013, S. 44 ff.; vgl. Sutherland & Schwaber, 2013, S. 8 f.)

3.3 Rollen

In diesem Kapitel wird auf die einzelnen Rollen von Scrum eingegangen. Laut

Scrum-Guide werden drei Rollen definiert. Es können auch zusätzliche Rollen, wie

die Stakeholder bestimmt werden. In dieser Arbeit werden nur die drei Hauptrollen

von Scrum, der Product Owner, das Entwicklungsteam und der Scrum Master, ge-

nauer beschrieben. Diese drei Rollen zusammen bilden das Scrum-Team. Die Zu-

sammenarbeit der Rollen untereinander ist überaus wichtig, um ein erfolgreiches

Produkt zu entwickeln. Dabei steht das gemeinsame Entwickeln eines wertvollen

Produkts durch das Scrum-Team im Vordergrund.

3.3.1 Product Owner

Der Product Owner ist für die Wertsteigerung und die Arbeit des Entwicklungsteams

verantwortlich. Außerdem sorgt er für die ständige Einbeziehung des Kunden, was

durch das Agile Manifest gefordert ist. Er formuliert gemeinsame Anforderungen mit

dem Kunden und stellt diese dem Entwicklungsteam vor. Diese Anforderungen do-

kumentiert er im Product Backlog. Eine der Hauptaufgaben des Product Owner sind

die Pflege und Erstellung des Product Backlog. Dies umfasst laut Scrum-Guide fol-

gende Aufgaben:

3 Scrum

13

Einträge klar formulieren

Einträge positionieren

Wert der Arbeit optimieren, die vom Entwicklungsteam geleistet wird

sicherstellen, dass das Product Backlog für alle sichtbar und transparent ist

sicherstellen, dass das Entwicklungsteam die Einträge versteht

Der Product Owner hat die Möglichkeit, diese Aufgaben selbst durchzuführen oder

auch einzelne an das Entwicklungsteam zu delegieren. Trotzdem bleibt jedoch der

Product Owner Verantwortlicher über den Inhalt des Product Backlog. Was bedeutet,

dass er auch im Falle einer Weitergabe einzelner Aufgaben, für deren Inhalt verant-

wortlich bleibt. Die Rolle des Product Owner muss immer eine einzelne Person be-

setzen und kein Komitee. Er darf zwar Wünsche eines Komitees im Product Backlog

wiedergeben, allerdings darf nur der Product Owner Einträge verändern. Diese Rolle

darf demnach nicht wie im klassischen Sinn als Projektleiter angesehen werden. Er

ist nicht der disziplinarische Leiter und verantwortet auch den Scrum Prozess nicht.

Bei der Zusammenarbeit mit dem Entwicklungsteam begegnen sich dagegen beide

Parteien auf Augenhöhe. Der Product Owner unterstützt das Entwicklungsteam z.B.

bei technischen Fragen zu den Backlog Items. Eine ständige Kommunikation zwi-

schen beiden ist dabei von grundlegender Bedeutung. Kontinuierlich werden Anfor-

derungen weiter verfeinert, um ein hochwertiges Produkt zu erstellen.

Eine weitere entscheidende Aufgabe des Product Owners ist die Release Planung.

Eine Release Planung ist notwendig, um den Stakeholdern des Projekts einen Aus-

blick für die Weiterentwicklung des Produkts zu geben. Dabei erstellt der Product

Owner einen Plan, der über mehrere Iterationen hinaus reicht, wie sich das Produkt

in den nächsten sechs bis zwölf Monaten weiterentwickelt. Die Rolle des Product

Owners wird auch als eine Rolle der zwei Gesichter bezeichnet. Gegenüber dem

Kunden muss er Anforderungen aufnehmen sowie bewerten und auf der anderen

Seite muss er diese mit dem Entwicklungsteam auf ihre Umsetzbarkeit prüfen. So

kann es vorkommen, dass die Rolle des Product Owners mit zwei verschiedenen

Personen besetzt wird, die dann mit den jeweiligen Parteien verhandeln. Bei dieser

Variante ist der organisatorische Aufwand allerdings größer und es muss auch klar

definiert sein, wer am Ende Entscheidungen durchsetzen kann. Ein großer Vorteil

dieser Methode ist, dass sich beide Parteien nicht vernachlässigt fühlen, wodurch

allerdings auch wird der Grad an Komplexität größer wird. In der Regel wird diese

3 Scrum

14

Rolle allerdings von einer Person ausgefüllt, je nach Umfang des Projekts kann es

aber auch Ausnahmen geben.

(vgl. Dräther, u.a., 2013, S. 63 ff.; vgl. Sutherland & Schwaber, 2013, S. 5)

3.3.2 Entwicklungsteam

Das Entwicklungsteam ist für die Umsetzung der geplanten Backlog Items in einem

Sprint verantwortlich. Es setzt die Planungen des Scrum-Teams um, sodass am En-

de eines jeden Sprints ein potentiell auslieferbares Produktinkrement ausgegeben

werden kann.

Die Hauptaufgabe des Entwicklungsteams ist es ein technisch erfolgreiches und

wertbares Produkt zu entwickeln. Die Verantwortung gegenüber dem Produkt muss

beim Entwicklungsteam somit höchste Priorität haben. Das Entwicklungsteam hat

auch das Recht, dem Product Owner zu wiedersprechen, sollte dieser Backlog Items

in einem Sprint Backlog fordern, die aus Sicht des Entwicklungsteams die Qualität

des Produktinkrements verschlechtern. Das Entwicklungsteam zeichnet aus, dass es

seine Organisation selbst bestimmt. Allerdings sollten der Product Owner und der

Scrum Master darauf achten, dass keine Subteams gebildet werden oder Rollen in-

nerhalb des Teams definiert werden. "Natürlich wird es auch in Scrum-

Entwicklungsteams Spezialisten mit besonderen Skills geben“. (Roock & Wolf, 2016,

S. 20) Die Verantwortung für das entstehende Produktinkrement trägt aber das gan-

ze Entwicklungsteam und nicht ein Einzelner.

Entwicklungsteams bei Scrum werden auch als cross-funktional Teams bezeichnet,

die interdisziplinär tätig sind. Das bedeutet, dass sie als Team alle Fähigkeiten ha-

ben, um das Produkt zu entwickeln. Die Größe des Entwicklungsteams wird laut

Scrum-Guide zwischen drei und neun Mitgliedern definiert. Diese Anzahl wurde fest-

gelegt da bei einem Team mit weniger als drei Mitgliedern die Gefahr besteht, dass

innerhalb des Teams wichtige Fähigkeiten zur Umsetzung des Produkts nicht gege-

ben sind. Bei einem zu großen Team mit über neun Mitgliedern nimmt der organisa-

torische Aufwand einen zu großen Rahmen ein.

(vgl. Dräther, u.a., 2013, S. 59 ff.; vgl. Sutherland & Schwaber, 2013, S. 6; vgl. Roock

& Wolf, 2016, S. 20)

3 Scrum

15

3.3.3 Scrum-Master

Der Scrum-Master ist für die Durchführung der Scrum-Methode verantwortlich. Dabei

achtet er darauf, dass die Scrum Theorien, Techniken sowie Regeln eingehalten

werden. Für die Rolle des Scrum-Masters sind einige Eigenschaften von entschei-

dender Bedeutung, die im Folgenden dargestellt werden.

Er sollte einen hohen Grad an Erfahrung haben sowie ein hohes Maß an Disziplin

und Selbstreflektion. Von Vorteil wäre beispielsweise, wenn der Scrum Master inner-

halb des Unternehmens eine Führungsrolle besitzt. Dadurch besitzt er bereits das

Vertrauen des Managements. Er hat aber gegenüber dem Scrum-Team keine diszip-

linarische Funktion, sondern agiert eher als Coach. Dem Entwicklungsteam kann er

beispielsweise bei der Selbstorganisation helfen, wobei er allerdings keine Aufgaben

verteilt, sondern die Rolle des Coaches einnimmt. Er unterstützt das Scrum-Team

auch beim Entwickeln eines hochwertigen Produkts, indem er Hindernisse beseitigt,

die das Entwicklungsteam aufhalten können. Auftretende Hindernisse können bei-

spielsweise folgende sein:

Beschaffen von Lizenzen

Klären von Kommunikationswegen

Organisation von Meetings

Herstellen von Kontakten zu externen Experten

Gegenüber dem Product Owner dient der Scrum-Master auf verschiedene Arten. Er

unterstützt ihn bei dem Finden neuer Techniken zum Pflegen und Verwalten des

Product Backlog. Er vermittelt ihm ein Verständnis für das Formulieren von eindeuti-

gen Product Backlog Einträgen. Außerdem achtet er darauf, dass der Product Owner

und das Entwicklungsteam eng zusammenarbeiten und sich auch regelmäßig aus-

tauschen. Dabei steht im Mittelpunkt, dass die Meetings stattfinden und nach der

Timeboxing Methode abgehalten werden. In den Meetings tritt der Scrum-Master

auch als Moderator auf und hat im Blick, dass alle Mitglieder zu Wort kommen und

sich einbringen können. Der Scrum-Master agiert dem Scrum-Team gegenüber als

Servant Leader. Dabei macht er keine Ansagen oder trifft Entscheidungen, sondern

stellt sich ganz in den Dienst des Teams.


3 Scrum

16

3.4 Meetings

Im diesem Kapitel soll ein Überblick über die verschiedenen Ereignisse in Scrum ge-

wonnen werden. Laut dem Scrum-Guide wird dabei zwischen vier Meetings während

dem Scrum-Prozess unterschieden. Einige dieser Meetings finden nur einmal je Pro-

jekt statt und einige auch mehrmals.

Bei der Durchführung der Meetings sollte darauf geachtet werden, dass diese immer

am gleichen Ort und zur gleichen Zeit stattfinden. Dadurch entwickelt sich bei den

Mitgliedern ein gewisser Automatismus, wodurch der organisatorische Aufwand in

den Hintergrund rückt und der Fokus auf den Inhalt gelegt werden kann. Alle Mee-

tings bei Scrum werden mithilfe der Timeboxing Methode abgehalten. Dabei wird ein

fest definierter und begrenzter Zeitrahmen gesetzt, in dem allerdings auch genügend

Zeit für die einzelnen Themenpunkte eingeplant ist. Durch die Timeboxing Methode

werden die Konzentration und das ergebnisorientierte Arbeiten gefördert. Meetings

geben den Mitgliedern die Möglichkeit sich selbst zu reflektieren und durch diese

Selbstreflektion neue Verbesserungspotentiale zu erkennen, „denn Scrum lebt und

entwickelt sich durch kontinuierliche Verbesserung und Anpassung an die aktuellen

Gegebenheiten." (Dräther, u.a., 2013, S. 73)

Es ist wichtig, dass alle Scrum Meetings innerhalb eines Projekts abgehalten werden.

Nur dadurch kann eine hohe Transparenz erreicht, mögliche Fehler schnell erkannt

und darauf reagiert werden. (vgl. Dräther, u.a., 2013, S. 72)

3.4.1 Sprint Planning

Das Sprint Planning wird immer zu Beginn eines neuen Sprints abgehalten. Das ge-

samte Scrum-Team nimmt an diesem Meeting teil. Während des Meetings wird die

Arbeit, die während des nächsten Sprints eingeplant ist, besprochen. Für die Organi-

sation des Meetings ist der Scrum Master verantwortlich. Er muss auch dafür sorgen,

dass die Teilnehmer den Zweck des Sprint Plannings verstehen und innerhalb der

vorgegebenen Time Box das Ziel des Meetings erreichen.

Der Inhalt des Sprint Planning teilt sich in zwei unterschiedliche Bereiche.

Im ersten Teil des Meetings wird folgende Frage geklärt: „Was ist in dem Produkt-

Inkrement des kommenden Sprints enthalten?“

Im zweiten Teil wird folgende Frage beantwortet: „Wie wird die für die Lieferung des

Produkt-Inkrements erforderliche Arbeit erreicht?“

(Sutherland & Schwaber, 2013, S. 9)

3 Scrum

17

Erst nachdem beide Inhalte besprochen wurden, ist das Sprint Planning abgeschlos-

sen.

Sprint Planning Teil 1

Am ersten Teil des Meetings nimmt das gesamte Scrum-Team teil, damit alle Team-

mitglieder verstehen, um was es in den anfallenden Sprint geht. Dieser Teil des Mee-

tings bezieht sich hauptsächlich auf die fachliche Ebene. Die Basis für die beginnen-

de Planung bilden das Product Backlog sowie der aktuelle Entwicklungsstand des

Produkts. Zu Beginn stellt der Product Owner die nach ihrer Priorität sortierten Back-

log Items vor und erläutert dem Entwicklungsteam die fachlichen Anforderungen an

das Produkt. Der Scrum-Master hat hier die Aufgabe darauf zu achten, dass die Dis-

kussion lediglich auf der fachlichen Ebene stattfindet, sodass technische Aspekte

zunächst ausgeklammert werden.

"Alle Mitglieder des Scrum-Teams tragen in dieser Phase durch gezieltes Nachfra-

gen und fokussierte Diskussion dazu bei, dass am Ende ein gemeinsames fachliches

Verständnis jedes Backlog Items entsteht." (Dräther, u.a., 2013, S. 76) Am Ende die-

ser Diskussion muss jedes Mitglied die einzelnen Backlog Items verstanden haben

und es muss festgelegt sein, welche Backlog Items im nächsten Sprint entwickelt

werden sollen. Es dürfen zwar alle an der Diskussion teilnehmen, aber nur das Ent-

wicklungsteam darf über die Anzahl der Backlog Items entscheiden, da sie für die

Umsetzung der Backlog Items verantwortlich sind. Auf dieser erarbeiteten Basis defi-

niert nun, das gesamte Scrum-Team ein gemeinsames Sprint-Ziel. An diesem Ziel

kann sich das Team während des Sprints orientieren und den Status erfassen. Am

Ende des ersten Teils muss ein gemeinsames Verständnis über funktionale und nicht

funktionale Anforderungen herrschen. Die jeweiligen Backlog Items für den folgen-

den Sprint sind ausgewählt und es wurde ein gemeinsames Sprint-Ziel definiert.

Sprint Planning Teil 2

In diesem Teil des Meetings wird nicht mehr auf der fachlichen, sondern der techni-

schen Ebene kommuniziert. Es muss festgelegt werden, wie die Arbeit während des

Sprints erfolgen soll. Es müssen Aufgaben definiert werden, die gemeistert werden

sollen, um das vorgegebene Sprint-Ziel zu erreichen. Als Teilnehmer für diesen Teil

des Sprint Planning fungieren nur die Mitglieder des Entwicklungsteams. Auf Wunsch

können auch andere Mitglieder daran teilnehmen, um bei fachlichen oder techni-

3 Scrum

18

schen Fragen zu unterstützen. Aufgrund der Auswahl der Backlog Items aus dem

ersten Teil, erstellt das Entwicklungsteam zunächst einen Systementwurf. Dadurch

lassen sich anfallende Aufgaben genau erkennen. Das Entwicklungsteam muss ab-

schätzen können, ob alle geplanten Produktinkremente während des Sprints erarbei-

tet werden können. Sollte das Entwicklungsteam in dieser Phase feststellen, dass die

Anzahl der Backlog Items zu hoch oder zu klein ist, haben sie die Möglichkeit, in

Rücksprache mit dem Product Owner, die Anzahl anzupassen. Am Ende des Mee-

tings werden, die Aufgaben für die ersten Tage des Sprints soweit verfeinert, dass

sie nicht mehr als einen Tag in Anspruch nehmen. Als Ergebnis dieses Meetings

steht das Sprint Backlog. Hier sind alle Aufgaben enthalten, die während des Sprints

umgesetzt werden sollen. Außerdem sollte das Entwicklungsteam in der Lage sein,

dem Product Owner und dem Scrum Master aufzuzeigen, wie es die Umsetzung des

Sprint-Ziels erreichen möchte.


3.4.2 Daily Scrum

Der Daily Scrum wird täglich abgehalten, dauert maximal 15 Minuten und sollte mög-

lichst immer zu gleichen Uhrzeit und am selben Ort stattfinden. Im Daily Scrum findet

die Planung der Aufgaben statt, die bis zum nächsten Daily Scrum erledigt werden

müssen. Außerdem werden die Aktivitäten des vorhergegangenen Tages abgegli-

chen und synchronisiert. Teilnehmer des Meetings ist das Scrum-Team. Die Mitglie-

der des Entwicklungsteams, schildern den Fortschritt ihrer Arbeit anhand der drei

folgenden Fragen:

Was habe ich seit dem letzten Daily Scrum erreicht?

Was werde ich bis zum nächsten Daily Scrum erreichen?

Welche Hindernisse sind mir im Weg gewesen?

Anhand des im Sprint Planning definierten Sprint-Ziels kann abgeglichen werden, ob

der aktuelle Status des Sprints weiterhin konform zum Erreichen des Ziels ist. Zu be-

tonen ist an dieser Stelle, dass es im Daily Scrum nicht darum geht, wie etwas er-

reicht wurde, sondern was erreicht wurde. Der Status des Projekts soll demnach

deutlich werden. Es muss klar erkennbar sein, an welchen Produktinkrementen aktu-

ell gearbeitet wird. In erster Linie ist das Ziel, den Gesprächs- und Klärungsbedarf

aufzudecken. Es kann auch sein, dass einzelne Fragen innerhalb des Daily Scrum

nicht geklärt werden können. Hier greift der Scrum-Master ein und sorgt dafür, dass

3 Scrum

19

einzelne Mitglieder sich im Anschluss intensiver austauschen. Das Daily Scrum hat

die Eigenschaft, die Kommunikation der Teammitglieder zu verbessern. Außerdem

fördert es eine schnelle Anpassung des Sprints aufgrund von auftretenden Hinder-

nissen. Am Ende des Meetings sollte das Entwicklungsteam in der Lage sein, dem

Product Owner aufzuzeigen, auf welchem Stand der Sprint ist und welche Backlog

Item umgesetzt wurden. (vgl. Dräther, u.a., 2013, S. 80 ff.)

3.4.3 Sprint Review

Am Ende eines Sprints wird das Sprint Review durchgeführt. Hier werden die Ergeb-

nisse aus dem vorhergegangen Sprint vorgestellt und bei Bedarf auch Anpassungen

am Product Backlog vorgenommen. An diesem Meeting nimmt das gesamte Scrum-

Team Teil. Auf Einladung können auch andere, aber dennoch am Projekt Beteiligte,

teilnehmen. Diese indirekt beteiligten Personen können Stakeholder, das Manage-

ment oder auch der Kunde des Produkts sein. Das Entwicklungsteam stellt alle neu-

en Funktionen vor, die im Sprint neu erarbeitet wurden. Dabei ist hervorzuheben,

dass keine halbfertigen Produktinkremente gezeigt werden. Es soll nur das präsen-

tiert werden, was auch wirklich fertig ist. Das Entwicklungsteam beantwortet auf-

kommenden Fragen und schildert eventuell Probleme, die bei der Umsetzung aufge-

treten sind. Während des Meetings gleicht der Product Owner, die Ergebnisse an-

hand des Sprint Backlog ab, um zu sehen, welche Anforderungen erfüllt wurden oder

noch bearbeitet werden müssen. Sollte festgellt werden, dass geplante Anforderun-

gen nicht umgesetzt wurden, muss das Entwicklungsteam schildern, aufgrund wel-

cher Probleme dies nicht gelungen ist. Im nächsten Schritt überlegt das gesamte

Scrum-Team, wie diese im darauffolgenden Sprint umgesetzt werden können oder

ob diese gegebenenfalls gestrichen werden müssen. Am Ende des Sprint Reviews

entsteht unter Berücksichtigung der erzielten Ergebnisse ein überarbeitetes Product

Backlog. In diesem können auch neue Backlog Items vorhanden sein, die im nächs-

ten Sprint möglicherweise eingeplant werden. Das Sprint Review liefert allen, die am

Projekt beteiligt sind, Informationen über den aktuellen Stand der Entwicklung und

bietet eine Möglichkeit, kurzfristig Änderungen am Projekt durchzusetzen.


3 Scrum

20

3.4.4 Retrospektive

Die Scrum Methode basiert auf der ständigen Weiterentwicklung, nicht nur der Mitar-

beiter, sondern auch des Scrum Prozesses. Dazu wird nach dem Sprint Review eine

Retrospektive abgehalten. Das Ziel der Retrospektive ist es, Verbesserungspotentia-

le zu erarbeiten, um diese im nachfolgenden Sprint umzusetzen. Dadurch soll die

Effektivität und Qualität der Arbeit und des Prozesses gesteigert werden. Für dieses

Meeting ist in etwa eine Time Box von drei Stunden angesetzt. Der Scrum-Master ist

dafür verantwortlich, dass dieses Meeting stattfindet, nimmt aber ebenfalls als

gleichwertiges Mitglied daran teil.

Die Retrospektive legt ihr Hauptaugenmerk auf zwei unterschiedliche Bereiche. Zu-

nächst wird die Zusammenarbeit untereinander betrachtet, wobei folgende Fragen

geklärt werden sollen:

Wie kann man auf direkten und kürzeren Wegen miteinander kommunizieren?

Mit wem haben wir erfolgreich zusammengearbeitet?

Danach richtet sich der Blick auf die Werkzeuge und Tools, die während des Sprints

verwendet wurden:

Brauchen wir wirklich alle verwendeten Tools?

An welcher Stelle haben uns Prozesse behindert?

Als Ergebnis der Retrospektive stehen mehrere Verbesserungspotentiale, wodurch

eine Anpassung im nächsten Sprint vorgenommen werden kann. Eine der wichtigs-

ten Voraussetzungen für ein erfolgreiches Meeting ist das Schaffen eines geschütz-

ten Raums. In diesem begegnen sich die Mitglieder auf Augenhöhe und es herrscht

eine wertschätzende Atmosphäre. (vgl. Dräther, u.a., 2013, S. 89 f.; vgl. Sutherland &

Schwaber, 2013, S. 12 f.) Dafür gilt als Grundlage folgende Regel:

"Ganz egal, was wir entdecken werden: Wir glauben zutiefst, dass jeder nach besten

Kräften gearbeitet hat, wenn man den aktuellen Wissensstand, die Fähigkeiten und

Fertigkeiten, die verfügbaren Ressourcen und die derzeitige Situation zugrunde legt."

(Dräther, u.a., 2013, S. 91)

3.5 Artefakte

Laut dem Scrum-Guide werden drei Artefakte für Scrum definiert: das Product Back-

log, das Sprint Backlog sowie das Inkrement. In weiteren Quellen wird aber auch die

Definition of Done genannt. Im Folgenden werden diese vier Artefakte genauer vor-

gestellt. Ziel der Artefakte bei Scrum ist es, eine größtmögliche Transparenz über die

3 Scrum

21

Schlüsselinformationen im Projekt zu erhalten. Die Artefakte helfen dem Scrum-

Team, einen Überblick über das Projekt zu bekommen und diesen zu bewahren.

3.5.1 Product Backlog

Die Verantwortung über das Product Backlog unterliegt wie bereits in Kapitel 3.3.1

beschrieben komplett dem Product Owner. Wie Tilo Linz in seinem Buch „Testen in

Scrum-Projekten“ beschreibt, basiert das Product Backlog auf folgender Theorie.

„Wenn man die Planung auf nur eine Dimension reduziert, auf eine simple Liste der

Arbeitsergebnisse, die erreicht werden sollen, dann verschwindet eine Menge Kom-

plexität. Genau dies passiert in Scrum" (Linz, 2013, S. 10) und soll mit dem Product

Backlog erreicht werden. Alle funktionalen und nicht funktionalen Anforderungen, die

nötig sind, um das Produktinkrement zu entwickeln, werden hier dokumentiert. Es ist

nicht notwendig direkt zu Beginn ein vollständiges Product Backlog zu erstellen. "Ein

Product Backlog ist ein dynamisches Gebilde und wird permanent angepasst und

weiterentwickelt.“ (Dräther, u.a., 2013, S. 97)

Es kann verschiedene Einflüsse auf das Product Backlog geben, sowohl externe als

auch interne. Externe Einflüsse können Marktveränderungen oder neue gesetzliche

Bestimmungen sein, interne fachliche oder technische Entwurfsentscheidungen. Wie

bereits erwähnt, entwickelt sich ein Product Backlog immer weiter. Zu Beginn sind

nur Anforderungen vorhanden, die initial erforderlich sind. Alle anderen Anforderun-

gen sind nur grob beschrieben. Das Product Backlog muss ausreichend genau de-

tailliert sein, so dass die Anforderungen an das Produkt jederzeit erkennbar sind. Im

Lauf des Projekts werden diese verfeinert, gegebenenfalls verändert oder verworfen.

Durch Feedback vom Kunden oder dem Anwender wächst das Product Backlog kon-

tinuierlich weiter. Die Backlog Items werden durch den Product Owner priorisiert und

in eine Reihenfolge gebracht. Am Ende enthält es alle Features, Anforderungen und

Funktionen des Produkts. Auch wenn mehrere Entwicklungsteams an einem Produkt

arbeiten, sollte es immer nur ein Product Backlog geben. Dadurch kann es zu keinen

Missverständnissen kommen. Ein Product Backlog kann verschiedene Erscheinungs-

formen haben. Diese können beispielsweise eine einfache Sammlung von Story

Cards sein oder auch mit unterschiedlichen Tool, wie einer Exel-Liste, realisiert wer-

den. Das Product Backlog ermöglicht dem Product Owner jederzeit, den Fortschritt

des Projekts zu erkennen. Diese Überprüfung kann er im Sprint Review erheben und

sie den Stakeholdern des Produkts präsentieren. (vgl. Dräther, u.a., 2013, S. 97 ff.)

3 Scrum

22

3.5.2 Sprint Backlog

Im Sprint Backlog sind alle Backlog Items enthalten, die im Sprint entwickelt werden

sollen. Des Weiteren enthält das Sprint Backlog einen groben Plan, wie das Entwick-

lungsteam vorgehen möchte, um das Produktinkrement zu entwickeln und das

Sprint-Ziel zu erreichen. Die Verantwortung über das Sprint Backlog liegt bei dem

Entwicklungsteam und wird während des Sprint Plannings erarbeitet. Das Sprint

Backlog muss so detailliert sein, dass während des Daily Scrums der aktuelle Stand

und der Fortschritt während des Sprints erkennbar sind. Sollten während eines

Sprints zusätzliche Arbeiten anfallen, um das Sprint-Ziel zu erreichen, werden diese

im Sprint Backlog nachgetragen. Die Backlog Items müssen nicht komplett ausgear-

beitet sein, sie können im Laufe des Sprints verfeinert werden. Das Sprint Backlog

ist, so wie das Product Backlog, ein dynamisches Gebilde, das sich immer weiter-

entwickelt. (vgl. Sutherland & Schwaber, 2013, S. 15)

3.5.3 Inkrement

Als Inkrement werden die einzelnen Ergebnisse des Sprints bezeichnet. Diese ent-

halten alle Backlog Items, die im Sprint Backlog definiert wurden. Diese müssen so

weit entwickelt werden, dass sie nach der Definition of Done als abgeschlossen gel-

ten. Es entsteht ein potentielles auslieferbares Produktinkrement. Die Summe der

einzelnen Produktinkremente bildet am Ende eines Projekts das fertige Produkt.

3.5.4 Definition of Done

Damit festgestellt werden kann, ob die Anforderungen an die Qualität eines Produk-

tinkrements erreicht wurden, muss ein gemeinsames Verständnis geschaffen wer-

den. Deshalb wird zu Beginn eines Projekts oder Sprints eine Definition of Done fest-

gelegt. Darin wird beschrieben, wann ein Produktinkrement als erledigt angesehen

wird. Wie oben bereits erwähnt, muss gewährleistet sein, dass alle Teammitglieder

ein gemeinsames Verständnis entwickeln. Nur so kann eine hohe Transparenz reali-

siert werden. Eine Definition of Done entwickelt sich meist iterativ zu dem Produk-

tinkrement. So sind am Anfang nur wenige, aber aus Sicht des Teams durchaus

wichtige, Kriterien formuliert. Diese erweitern sich dann mit dem Produkt aufgrund

der wachsenden Erfahrung. (vgl. Sutherland & Schwaber, 2013, S. 17 f.)

4 Iterativ-inkrementelle Vorgehensmodelle

23


Wie in der Einleitung bereits begründet, konnten im Rahmen dieser Ausarbeitung

keine rein iterativen Vorgehensmodelle zum Vergleich mit Scrum gefunden werden.

Meist wird der iterative mit dem inkrementellen Planungsansatz kombiniert (siehe

Kapitel 2.3). Aus diesem Grund werden in diesem Kapitel die bekanntesten und/oder

die in der Praxis am meisten angewandten iterativ-inkrementellen Vorgehensmodelle

beschrieben.

4.1 Spiralmodell

Der Grundsatz des Spiralmodells nach Boehm liegt vor allem darin, dass ein Projekt

an sich als ein risikogetriebener Prozess betrachtet wird und es sieht deshalb mehre-

re Risikoanalysen über den Projektverlauf hinweg vor. Auf Änderungen bezüglich der

Ergebniserwartungen oder auch Änderungen bezüglich der eventuellen Risiken ei-

nes Projekts kann mit diesem Modell dynamisch reagiert werden. Das Modell wird

dabei in Form einer Spirale visualisiert, bei der während des Projektverlaufs immer

wieder die gleichen vier Quadranten durchlaufen werden. Diese vier Quadranten

können auch als die Phasen des Spiralmodells betrachtet werden. Das stetige

Wachstum der Spirale soll dabei den Fertigstellungsgrad symbolisieren. (vgl.

Angermeier, 2004)

Abbildung 6: Ablauf Spiralmodell, Quelle: Broy & Gronau, 2009


24

Wie in Abbildung 6 ersichtlich, werden die vier Phasen des Spiralmodells wie folgt

bezeichnet: „Festlegung der Ziele und Beurteilung von Alternativen“, „Risikoanalyse“,

„Entwicklung und Test“ und „Planung des nächsten Zyklus“.

Bei jedem Zyklus der Spirale werden folgende Entwicklungsdomänen durchlaufen:

Entwicklungsdeterminanten (Quadrant I):

Identifikation der Ziele (u.a. Einsatzbereich, Funktionalität, Modifizierbarkeit); Festle-

gung von Alternativen (u.a. Lösungsvarianten, Wiederverwendung, Zukauf); Bestim-

mung der Einschränkungen (u.a. Kosten, Termine, Schnittstellen)

Entwicklungsrisiken (Quadrant II):

Bewertung von Alternativen; Aufdeckung von Risikoquellen (Produktrisiko: Aufga-

benstellung, Zulieferung, Produktionsmittel; Prozessrisiko: Mitarbeiter, Auftraggeber,

Organisation) sowie Beherrschung der Risiken (u.a. in Form von Benutzerbefragung,

Simulation, Prototyping)

Entwicklungsdurchführung (Quadrant III):

Entwicklung und Abnahme des Softwaresystems auf der jeweiligen Stufe

Entwicklungsplanung (Quadrant IV):

Planung der nächsten Stufe des Softwaresystems (u.a. Kosten, Zeitrahmen, benötig-

te Ressourcen)“

Diese vier Quadranten werden während eines Projekts immer wieder durchlaufen.

Die nächste Entwicklungsstufe darf jedoch erst begonnen werden, wenn die Ergeb-

nisse der Vorstufe abgenommen wurden. Konnten alle Risiken in mehreren Durch-

läufen eliminiert werden, kann das Projektergebnis in einem letzten Durchlauf der

vier Quadranten fertiggestellt werden. Vordefinierte Rollen oder Prinzipien sieht das

Spiralmodell nicht vor. (vgl. Broy & Gronau, 2009, S. 180)

4.2 Extreme Programming

Das Extreme Programming (nachfolgend XP genannt) besteht aus zwei Phasen. Ei-

ner Planungsphase, in der Anforderungen geklärt werden und Verständnis für das

Projekt geschaffen wird und einer Iterationsphase, in der die Umsetzung erfolgt. Die

Iterationsphase wiederum besteht aus mehreren Aktivitäten, die in jeder Iteration


25

Zwischenergebnisse hervorbringen sollen. „Die Aktivitäten des XP Vorgehensmodells

sind nur abstrakt beschrieben, um Entwicklern so viele Freiräume wie möglich zu

bieten und das Vorgehensmodell leichtgewichtig zu halten.“ (Bunse & Knethen,

2002, S. 57) In der Planungsphase werden gemeinsam mit dem Auftraggeber z.B.

Budget- und Zeitpläne erstellt und eine erste prototypische Architektur (bei Software-

Projekten) entworfen. Auf Basis dieser können die folgenden Entwicklungsschritte

(Iterationen) geplant werden. Charakteristische Aktivitäten in dieser Phase können

folgende sein:

Sammlung von „User-Stories“

Erstellung einer prototypischen Architektur

Entwicklung von Testszenarien

Erstellung eines Releaseplans

In der zweiten Phase, der Iterationsphase, die eben-

falls in nachfolgender Grafik veranschaulicht wird,

werden die Pläne aus der Planungsphase schließlich

umgesetzt und in mehreren Iterationsschleifen das

gewünschte Ergebnis entwickelt. Typische Aktivitäten

dieser Phase lassen sich folgende beispielhaft nen-

nen:

Entwicklung von Testfällen

Planung und Implementierung des Inkrements

Überarbeitung der Architektur

Test des aktuellen Inkrements

Erfassung von Daten

Durchführung von Akzeptanztests

Das XP-Modell definiert drei eindeutige Rollen, die im Folgenden erläutert werden:

Den Kunden, welcher während des Projekts die Aufgabe hat, Funktionstests für die

Software zu entwerfen. Außerdem muss dieser dabei jederzeit ansprechbar sein, um

eventuell Fragestellungen zu klären.

Den Projektleiter, der die Verantwortung für das Projekt trägt. „Er verwaltet Ressour-

cen, Kosten, Zeitpläne, um damit eine optimale Qualität zu erreichen.“ (Rumpe,

2001, S. 8)

Abbildung 7: Extreme Programming Prozess-Ablauf, Quelle: Franz, 2011


26

Den Entwickler, der die eigentliche Arbeit innerhalb des Projekts vollzieht und die

Hauptlast trägt. Unter den Entwicklern gibt es jedoch keine Unterscheidung (z.B.

nach Spezialgebieten) mehr.

Das gesamte Team arbeitet dabei nach den folgenden Grundwerten:

Feedback

Respekt

Kommunikation

Einfachheit

Mut

Aus diesen fünf Werten leiten sich die 15 Prinzipien des Extreme Programming ab.

Diese sind unmittelbares Feedback, Einfachheit anstreben, inkrementelle Verände-

rung, Veränderung wollen, Qualitätsarbeit, lernen lehren, geringe Anfangsinvestition,

auf Sieg spielen, gezielte Experimente, offene und aufrichtige Kommunikation, Ins-

tinkte des Teams nutzen und nicht dagegen arbeiten, Verantwortung übernehmen,

an örtliche Gegebenheiten anpassen, mit leichtem Gepäck reisen, ehrliches Messen.

Anhand dieser 15 Prinzipien kann ein Grundverständnis für das Extreme Program-

ming vermittelt werden. (vgl. Hense, 2012, S. 14 ff.; vgl. Franz, 2012)

4.3 Feature-Driven-Development

Feature-Driven-Development ist ein teiliteratives Prozessmodell und soll im Folgen-

den näher betrachtet werden, da es sich gut eignet, um typische Merkmale des

Scrum Planungsansatzes einzusehen. FDD wurde 1997 von dem Australier Jeff De

Luca entwickelt. Seine Motivation war es, ein festes Rahmenmodell zu erschaffen,

um große Projekte erarbeiten zu können. Diese Methode eignet sich besonders gut

zur Einführung in klassisch organisierten Unternehmen, da die dortigen Strukturen

sehr gut mit dem Rollenmodell von FDD einhergehen. Der Prozess bei dieser Me-

thode läuft in fünf Phasen ab, die sich in Planung und Entwurf aufteilen, wie die Ab-

bildung 8 zeigt. Bei einer Projektdauer von 6 Monaten ist der Zeitrahmen für die ers-

ten drei Phasen auf 2-3 Wochen festgelegt, die letzten zwei Phasen laufen in einer

Iteration von jeweils 2 Wochen ab. Im Folgenden wird der Inhalt der Phasen erläutert.


27

Erste Phase: Erstelle das Gesamtmodell

In der Phase von FDD nehmen ausgewählte Experten teil, die von Seiten des Pro-

jektleiters bestimmt wurden. Des Weiteren nehmen die Entwickler teil und die Leitung

dieser Phase unterliegt dem Chefarchitekten. In dieser Phase soll ein Überblick über

das System gewonnen werden. Das Team hat die Aufgabe, einen groben Syste-

mentwurf zu erstellen, der auch Domänenmodell genannt wird. Das Verfeinern des

Systems soll schrittweise erfolgen. Daraufhin werden separate Teams mit Experten

und Entwicklern gebildet, die jeweils Modelle zu ausgewählten Aufgaben anfertigen

und diese den anderen Teams vorstellen.

Zweite Phase: Erstelle die Feature Liste

In dieser Phase zerlegt ein Team aus Chefprogrammierern die im Vorfeld definierten

Systembereiche in einzelne Features. Diese Features werden in einer Feature Liste

dokumentiert.

Dritte Phase: Plane je Feature

Hier werden die festgelegten Features priorisiert und in eine festgelegte Reihenfolge

gebracht. Die Priorisierung findet anhand der Komplexität und der Auslastung des

Teams statt. Hier spielt auch die Abhängigkeit der Features untereinander eine Rolle.

Verantwortlich für diese Phase sind der Projektmanager, Entwicklungsmanager und

die Chefprogrammierer.

Vierte Phase: Entwirf je Feature

Der Chefprogrammierer wählt in dieser Phase aus, welche Features in der nächsten

Iteration umgesetzt werden müssen. Wichtig dabei ist, dass dieser auch eine Umset-

zung der ausgewählten Features innerhalb von zwei Wochen achtet. Es werden Se-

Abbildung 8: Feature Driven Develeopment Phasenablauf


28

quenzdiagramme erstellt, die Klassenmodelle verfeinert und Klassenbesitzer be-

stimmt, wodurch sich die Features Teams bilden.

Fünfte Phase: Entwickle je Feature

In dieser Phase erfolgt die Implementierung der bestimmten Klassen durch ihre Be-

sitzer. Damit die Qualität der Features bestimmt werden kann, werden in dieser Pha-

se Komponententests durchgeführt. Als Ergebnis dieser Phase stehen ausgereifte

Features, die dokumentiert sind und dem Kunden präsentiert werden können.

Das Rollenmodell von FDD definiert viele unterschiedliche Rollen. Diese werde in

Schlüsselrollen, unterstützende Rollen sowie zusätzliche Rollen unterteilt. An dieser

Stelle werden nur die sechs Schlüsselrollen aufgezeigt, da der Rahmen der Arbeit

einen größeren Umfang nicht zulässt.

Projektmanager

Chefarchitekt

Entwicklungsmanager

Chefprogrammierer

Klassenbesitzer

Domänenexperten

Aufgrund des hierarchischen Rollenmodells ist eine Selbstorganisation der einzelnen

Teams nicht möglich. Allerdings ist es wichtig, dass die Hauptrollen ein hohes Maß

an Kompetenz und Erfahrung mitbringen. Durch das Bearbeiten des Projekts in

überschaubaren Features wird eine ausreichende Transparenz erzielt. Das FDD ist

zwar in Deutschland weniger verbreitet, für klassisch ausgerichtete Unternehmen, die

große Projekte durchführen möchten, allerdings sehr ansprechend.

(vgl. Hense, 2012, S. 53 ff.)

5 Scrum im Vergleich zu iterativen Vorgehensmodellen

29


In diesem Kapitel sollen Unterschiede zwischen Scrum und verschiedenen iterativen

Vorgehensmodellen dargestellt werden. Als Grundlage dafür wurden in Kapitel 3 die

Scrum-Methode ausführlich behandelt und verschiedene Merkmale aufgezeigt.

In Kapitel 4 wurden drei unterschiedliche iterative Vorgehensmodelle vorgestellt. Die

spezifischen Merkmale von Scrum im Vergleich zu iterativen Vorgehensmodellen

beziehen sich lediglich auf die hier verwendeten iterativen Vorgehensmodelle. Um

spezifische Merkmale von Scrum besser zu erkennen, wurde eine Tabelle erstellt,

die im Anhang zu finden ist. Hier wurden verschiedene Merkmale der unterschiedli-

chen Vorgehensmodelle betrachtet und ausgewertet. Anschließend werden in Kapitel

5.4 spezifische Merkmale der Scrum-Methode aufgezeigt.

5.1 Vergleich: Scrum – Spiralmodell

In diesem Kapitel werden die im Anhang erarbeiteten Merkmale genauer erläutert. Es

sollen Unterschiede zwischen der Scrum-Methode und dem Spiralmodell aufgezeigt

werden.

Iteration

Das Spiralmodell durchläuft immer vier Phasen, die bereits in Kapitel 4.1 erläutert

wurden. Eine Dauer für die Iteration ist nicht festgelegt. Bei Scrum wird die Iteration

als Sprint bezeichnet, wobei keine Phasen durchlaufen werden. Es gibt allerdings

verschiedene Ereignisse, die abgehalten werden. Dazu wurde in Kapitel 3 die Scrum-

Methode ausführlich erläutert.

Meetings

Bei Scrum werden vier unterschiedliche Meetings definiert. Das Spiralmodel definiert

lediglich ein Meeting, das am Ende einer jeden Iteration durchgeführt wird. Genau

wie der Sprint Review dient dieses Meeting dazu, die Ergebnisse aus der vorherge-

gangenen Iteration zu präsentieren.

Rollen

Im Gegensatz zu Scrum definiert das Spiralmodell keinerlei Rollen. Dies trägt auch

dazu bei, dass das Spiralmodell nicht sehr verbreitet ist.


30

Transparenz

Auch das Spiralmodel hat wie Scrum eine gute Transparenz. Aufgrund der Iteratio-

nen können am Ende jeder Iteration Anpassungen an den Anforderungen vorge-

nommen werden. Der Kunde hat die Möglichkeit am Ende der Iteration, das Produkt

zu begutachten. Dadurch ist ihm der Fortschritt der Produktentwicklung ständig be-

kannt.

Einarbeitungszeit

Das Spiralmodell nach Boehm findet nur geringen Einsatz in der Praxis, da es ein

sehr theoretisches Modell ist. Die Umsetzung gestaltet sich im Vergleich zu Scrum

als sehr schwierig, da keine Werte, Prinzipien oder Rollen definiert werden. Aufgrund

der fehlenden Werte und Prinzipien gestaltet sich die Einarbeitung mühevoll.

Prozessverbesserung

Am Ende jeder Iteration findet ein Meeting statt, bei dem die Ergebnisse aus der Vo-

riteration und das Vorgehen der nächsten Iteration besprochen werden. Dabei wird

auch über mögliche Verbesserungen im bestehenden Prozess diskutiert. Werden

dabei Optimierungspotenziale erkannt, werden diese direkt in der nächsten Iteration

umgesetzt. Am Ende einer Iteration findet bei Scrum dazu eine Retrospektive statt.

Hier werden ebenfalls Verbesserungspotentiale erarbeitet, um diese in der nächsten

Iteration umzusetzen.

Qualitätssicherungsmaßnahmen

Das Spiralmodell nach Boehm erfordert eine Vorgehensweise nach folgender Regel:

Die nächste Iteration darf nicht vor Abnahme der Ergebnisse der Voriteration starten.

Somit wird gewährleistet, dass an keinem Produkt weitergearbeitet wird, das nicht

den Anforderungen des Kunden entspricht. Am Ende jeder Iteration findet demnach

eine Qualitätssicherung statt.

Flexibilität

Durch die regelmäßigen Meetings, in welchen das Ergebnis der jeweiligen Iteration

und das Vorgehen der nächsten Iteration besprochen werden, kann sehr flexibel auf

Änderungen bezüglich der Anforderungen reagiert werden. Je nach Iterationsdauer-

kann entsprechend flexibel reagiert werden. Analog zum Spiralmodell können bei


31

Scrum am Ende jeder Iteration Anpassungen an den Anforderungen vorgenommen

werden.

Kundeninvolvierung

Das Spiralmodell ermöglicht genau wie bei Scrum, dass der Kunde am Ende einer

jeden Iteration das Ergebnis begutachtet. Somit bleibt der Kunde auf dem aktuellen

Stand der Entwicklung und kann Änderungswünsche direkt äußern. Allerdings ist bei

Scrum der Kunde nicht direkt involviert, sondern wird lediglich durch den Product

Owner eingebunden.

5.2 Vergleich: Scrum – Extreme Programming

In diesem Kapitel werden die in Tabelle 1 erarbeiteten Merkmale genauer erläutert.

Es sollen Unterschiede zwischen der Scrum-Methode und Extreme Programming

aufgezeigt werden.

Iteration

Sowohl bei der XP als auch bei der Scrum-Methode läuft die Entwicklungsarbeit mit

wiederholenden Iterationen ab. Bei Scrum werden diese Iterationen Sprints genannt

und dauern maximal einen Monat. Bei XP findet eine Iterationsphase statt, die maxi-

mal eine Woche dauert. Am Ende beider Methoden entsteht ein Inkrement des Ge-

samtprodukts. Aus der Summe der Teilprodukte ergibt sich am Ende das Gesamt-

produkt.

Meetings

Bei XP wird das Standup-Meeting definiert. Die Scrum-Methode hat im Vergleich da-

zu deutlich mehr Meetings definiert. Das Standup-Meeting ist mit dem Daily Scrum

vergleichbar. Beide Meetings finden täglich statt und dienen dazu die geleistete Ar-

beit aufzuarbeiten sowie die folgende Arbeit zu planen. Bei Scrum findet zusätzlich

ein Sprint Planning, Sprint Review und eine Retrospektive statt, deren Inhalt bereits

in Kapitel 3.4 erläutert wurde.

Rollen

Beide Methoden definieren jeweils drei Rollen, die entscheidend für den Erfolg der

Produktentwicklung sind. Im Vergleich zu Scrum definiert die XP-Methode den Kun-


32

den als eine festgelegte Rolle. Bei Scrum wird der Kunde durch die Rolle des Pro-

duct Owners eingebunden. Dieser bildet die Schnittstelle zwischen dem Kunden und

Entwicklungsteam. Im Gegensatz zu XP definiert Scrum keinen Projektleiter, denn

hier ist nicht eine Person für den Projekterfolg verantwortlich, sondern das gesamte

Scrum-Team.

Werte

Für beide Methoden werden Werte definiert, die für das Ausüben der jeweiligen Me-

thoden entscheidend sind. Bei beiden zählen dazu Mut und Respekt. Unterschiede

gibt es hingegen bei folgenden Werten: Bei Scrum werden zusätzlich Offenheit,

Commitment und Fokus genannt. Im Gegensatz dazu nennt XP hier Feedback, Ein-

fachheit und Kommunikation.

Prinzipien

Bei der XP-Methode werden aufgrund der aufgeführten Werte 15 Prinzipien definiert.

Scrum legt im Vergleich dazu keine expliziten Prinzipien fest. In Kapitel 3.1 wurden

lediglich drei Prinzipien genannt, die für Scrum entscheidend sind.

Dokumentation

Bei der Dokumentation kommt zwischen beiden Methoden zu deutlichen Unterschie-

den. Extreme Programming erfordert nur einen geringen Dokumentationsaufwand.

Die Anforderungen des Kunden werden hier lediglich auf Story User Card dokumen-

tiert. Bei Scrum hingegen ist die Dokumentation ein wichtiges Merkmal und entschei-

dend für den Scrum Prozess. Wie in Kapitel 3.5 beschrieben gibt es mehrere Artefak-

te, die gefüllt werden müssen und wichtige Eigenschaften besitzen.

Transparenz

Beide Methoden legen großen Wert auf eine hohe Transparenz. Bei beiden wird ein

tägliches Meeting abgehalten, um den aktuellen Stand der Iteration zu begutachten.

Außerdem bieten beide Methoden dem Kunden am Ende jeder Iteration an, den

Entwicklungsfortschritt zu begutachten. Ergänzend dazu bietet Extreme Program-

ming dem Kunden an, eng mit dem Entwicklungsteam zusammenzuarbeiten, was bei

Scrum nicht vorgesehen ist.


33

Einarbeitungszeit

Extreme Programming ist ein sehr umfangreiches und kompliziertes Vorgehensmo-

dell. Es fordert eine Menge Disziplin sowie ein hohes Maß an Erfahrung von den

Entwicklern und Managern. „Unerfahrene Entwickler und deren Ausbildung lassen

sich nur eingeschränkt in Projekten unterbringen“. (Hense, 2012, S. 18) Ein XP-

Coach kann dem Team helfen, die Abläufe besser zu verstehen und sich schneller

an das XP zu gewöhnen. Dabei ist der Coach aber kein Entscheidungsträger, son-

dern hat nur eine beratende Funktion. Da bei Scrum insbesondere die Planung eines

Sprints für unerfahrene Teams eine gewisse Herausforderung darstellt, gestaltet sich

die Einführung aufwendiger als bei der XP-Methode. Allerdings werden bei Scrum

ebenfalls die Teams durch den Scrum Master betreut und gecoacht.

Prozessverbesserung

Die Scrum Methode lebt von einer ständigen Weiterentwicklung, die durch eine Ret-

rospektive gefördert wird. Hier werden Verbesserungspotentiale ermittelt, um sie im

nächsten Sprint umzusetzen. Ein spezielles Meeting, um Verbesserungspotentiale

hinsichtlich des Prozesses zu erarbeiten, gibt es bei der XP-Methode nicht.

Qualitätssicherung

Bei XP findet mithilfe von Pair-Programming eine dauerhafte Kontrolle des aktuellen

Arbeitsfortschritts statt. Mit Qualitätssicherungsmaßnahmen wird schon bei den frü-

hen Entwicklungsphasen begonnen. Testfälle müssen schon vor dem eigentlichen

Codieren geschrieben und entwickelt worden sein. So weiß der Entwickler im Vor-

feld, welche Bedingungen das Produkt erfüllen muss. Außerdem kommen verschie-

dene Arten von Integrationstests und Unit-Test zum Einsatz. Ergänzend dazu spielen

ebenfalls die Akzeptanztests eine wichtige Rolle. Die XP-Methode stellt viele Prakti-

ken zur Verfügung, um die Qualität zu überwachen und einzuhalten. Dadurch, dass

in Scrum mit cross-funktionalen Teams gearbeitet wird, wird im Entwicklungsteam

immer ein Entwickler mit Tester-Fähigkeiten vorgesehen. Diese Rolle wird bei Scrum

zwar nicht explizit festgelegt, allerdings wird am Ende eines Projektes die Ausliefe-

rung eines ausgiebig getesteten Produkts gefordert. Demzufolge werden die einzel-

nen Inkremente ausgiebig getestet, um eine hohe Qualität voraussetzen zu können.


34

Flexibilität

Beide Methoden sind sehr flexibel und Änderungswünsche am Produkt können

schnell aufgenommen und realisiert werden. Dies ist möglich, da die Entwicklung des

Produkts in mehreren Iterationen erfolgt. Änderungen an den Anforderungen können

am Ende jeder Iteration besprochen und in der nächsten Iteration umgesetzt werden.

Kundeninvolvierung

Der Kunde definiert die Anforderungen an das Produkt und nimmt eine tragende Rol-

le ein. Er gibt Wünsche anhand von User Story Cards an die Entwickler ab, womit

eine aufwendige Dokumentation vermieden wird. Der Kunde ist bei der XP-Methode

im Gegensatz zu Scrum eine definierte Rolle, ständig präsent und tauscht sich mit

dem Entwicklungsteam aus. Für ein erfolgreiches Produkt ist er damit unverzichtbar.

Der Kunde arbeitet bei Scrum nicht mit dem Entwicklungsteam zusammen. Er kann

dem Product Owner lediglich Anforderungswünsche mitteilen. Diese kommuniziert

der Product Owner dann mit dem Entwicklungsteam. Am Ende eines jeden Sprints

hat der Kunde die Möglichkeit, den Entwicklungsfortschritt im Sprint Review zu be-

gutachten.

5.3 Vergleich: Scrum – Feature-Driven-Development

In diesem Kapitel werden die in Tabelle 1 erarbeiteten Merkmale genauer erläutert.

Es sollen Unterschiede zwischen der Scrum-Methode und Feature-Driven-

Development aufgezeigt werden.

Iteration

Feature-Driven-Development läuft während der Planungsphase wasserfallartig ab.

Die eigentliche Iteration findet in der Entwurfsphase statt, diese Iterationen dauern

maximal zwei Wochen. Am Ende einer Iteration entsteht eine Feature des Gesamt-

produkts.

Meeting

Im Gegensatz zur Scrum-Methode definiert Feature-Driven-Development keine Mee-

tings. Es werden Meilensteine festgelegt, wodurch der Entwicklungsstand erfasst

werden kann. Auch die Ergebnisse der Iteration werden am Ende überprüft, wofür

allerdings kein explizites Meeting definiert ist.


35

Rollen

Im Gegensatz zu Scrum besitzt FDD ein hierarchisches Rollenmodel. Die Rollen bei

FDD unterteilen sich in Schlüsselrollen, unterstützende Rollen und zusätzliche Rol-

len. Die Schlüsselrollen wurden bereits in Kapitel 4.3 dargelegt. Die Anzahl des ge-

samten Entwicklungsteams ist im direkten Vergleich deutlich höher als bei Scrum.

Analog zur XP-Methode nimmt der Kunde bei FDD, im Gegensatz zu Scrum, eine

Schlüsselrolle ein und ist insbesondere in der Planungsphase stark involviert.

Dokumentation

Sowohl die Scrum als auch die FDD-Methode besitzen einen hohen Dokumentati-

onsaufwand. Besonders die FDD-Methode besitzt viele unterschiedliche Artefakte,

die mit Inhalten gefüllt werden müssen. Durch die Dokumentation können alle Mit-

glieder über Änderungen oder den aktuellen Stand informiert werden. Das ist insbe-

sondere bei FDD wichtig, da aufgrund des hierarchischen Rollenmodells nur die obe-

ren Rollen genau informiert werden. Bis auf den hohen Dokumentationsaufwand sind

die Artefakte ansonsten kaum vergleichbar. Die Feature-Liste bei FDD kann gleich-

gesetzt werden mit dem Sprint Backlog oder Project Backlog von Scrum. Eine Defini-

tion of Done besitzt FDD allerdings nicht.

Transparenz

Aufgrund der kurzen Iterationsdauer bleibt der Aufbau bei FDD sehr übersichtlich.

Der Kunde nimmt hauptsächlich in der Planungsphase direkten Einfluss auf das Pro-

dukt. Mithilfe von festgelegten Meilensteinen während der Planungs- und Entwurfs-

phase bleibt der Status des Projekts dauerhaft präsent. Allerdings wird die Transpa-

renz aufgrund des hierarchischen Rollenmodels im Vergleich zu Scrum stark einge-

schränkt, da untergeordnete Rollen nicht direkt mit Informationen ausgestattet wer-

den.

Einarbeitungszeit

FDD kann im Vergleich zu Scrum in ausgewählten Unternehmen besser und schnel-

ler eingeführt werden. Bei klassisch ausgerichteten Unternehmen kann FDD deshalb

sehr schnell eingeführt werden, weil die Rollenmodelle und die Methoden sehr ähn-

lich sind. Bei agilen Unternehmen ist die Einführung allerdings aufwendiger. Auf-

grund der hierarchischen Rollenstruktur ist eine Selbstorganisation des Teams nicht


36

möglich. Die Selbstorganisation ist bei Scrum ein wichtiger Faktor. Deshalb gibt es

bei der FDD-Methode auch keinen Scrum-Master, der als Coach für das Team fun-

giert. Bei FDD sind die übergeordneten Rollen für die Organisation verantwortlich.

Prozessverbesserung

Eine ständige Verbesserung des Prozesses ist bei FDD nicht festgelegt. Bei Scrum

wird dazu am Ende einer jeden Iteration eine Retrospektive durchgeführt. Damit kön-

nen Verbessrungspotentiale erarbeitet werden, um sie im nächsten Sprint umzuset-

zen.

Qualitätssicherungsmaßnahmen

Durch qualifizierte Schlüsselrollen und eine ausgiebige Planung sowie Entwurfspha-

se wird die Fehleranfälligkeit bei FDD minimiert. Der Grundgedanke bei der FDD-

Methode ist folgender: Wenn ein Entwickler selbst für sein Produkt verantwortlich ist,

arbeitet er sauberer und fokussierter.

Die Entwickler bei FDD testen ihre Produkt-Features immer selbst, werden aber

durch andere Entwickler bei ständig stattfindenden Inspektionen überprüft. Die In-

spektionen sind zwar eine zeitaufwendige Methode, aber auch dementsprechend

effektiv. Bei Scrum werden solche Inspektionen nicht durchgeführt, des Weiteren ist

immer das ganze Team für ein Inkrement verantwortlich. Wie bereits in Kapitel 3 be-

schrieben, wird die Qualität bei Scrum durch cross-funktionale Teams und dem

Grundgedanken, immer ein ausgiebig getestetes Produkt auszuliefern, erreicht.

Flexibilität

Aufgrund der wasserfallartigen Abfolge wirkt FDD anfangs eher unflexibel, aber bei

näherem Betrachten ist dennoch eine Flexibilität gegeben. Die kurzen Iterationspha-

sen von maximal zwei Wochen ermöglichen eine schnelle Reaktionszeit auf Ände-

rungen. Dennoch ist dieses Vorgehen deutlich schwergewichtiger als andere Model-

le. Genau wie bei Scrum bestimmt der Kunde zu Beginn Anforderungen, kann aber

während der Iteration nicht in die Entwicklungsarbeit eingreifen.

Kundeninvolvierung

Dem Kunden kommt wie bei XP eine Hauptrolle zu, wird aber nur in der Planungs-

phase einbezogen. Zum Abschluss hat er noch die Aufgabe das Ergebnis zu bewer-


37

ten, kann aber während der Entwurfsphase nicht in den Entwicklungsprozess eingrei-

fen. Bei der Scrum-Methode wird der Kunde über den Product Owner einbezogen.

Dieser agiert als Schnittstelle zwischen dem Kunden und der Entwicklung.

5.4 Zusammenfassende Darstellung der Ergebnisse

Anhand des in Kapitel 5 durchgeführten Vergleichs konnten spezifische Merkmale

von Scrum zu den in Kapitel 4 beschriebenen iterativen Vorgehensmodellen ermittelt

werden. Ergänzend dazu wurden mehrere parallele Merkmale gefunden. Die Tabelle

1 zeigt die spezifischen sowie nicht spezifischen Merkmale der Scrum Methode.

Die Entwicklung bei den in der vorliegenden Arbeit beschrieben Vorgehensmodellen

läuft anhand von Iterationen ab. Am Ende einer jeden Iteration entsteht ein Produk-

tinkrement, was sich mit jeder Iteration weiterentwickelt. Bei Scrum wird die Iteration

als Sprint bezeichnet, die auf eine maximale Dauer von einem Monat festgelegt ist

und damit deutlich länger ist als bei anderen Methoden. Auch die definierten Ereig-

nisse während des Sprints heben sich teilweise von anderen Methoden ab. Das

Sprint Planning und die Retrospektive werden bei anderen Methoden nicht genau

definiert. Insbesondere die Retrospektive dient dazu, Verbesserungspotentiale zu

ermitteln, um den Prozess stetig weiterentwickeln zu können. Eine stetige Weiter-

entwicklung des Prozesses ist bei den hier aufgelisteten Modellen nicht genau defi-

niert.

Beim Daily Scrum oder dem Sprint Review gibt es allerdings ebenso Parallelen zu

anderen Methoden. Der Daily Scrum ist vergleichbar mit dem Standup Meeting der

XP-Methode. Beide werden täglich abgehalten und dienen dazu, alle Teammitglieder

auf den aktuellen Stand zu bringen. Bezogen auf den Grundsatz, dass bei iterativen

Modellen immer ein Meeting am Ende jeder Iteration stattfindet, gibt es Parallelen zu

Scrum. Hier wird am Ende des Sprints ein Sprint Review durchgeführt, indem die

Ergebnisse der Iteration gleichermaßen präsentiert werden.

Zu weiteren Unterschieden kommt es vor allem beim Rollenmodell bei den einzelnen

Modellen. Scrum besitzt kein hierarchisches Rollenmodell oder definiert auch den

Kunden nicht als eine spezifische Rolle. Die Teams bei Scrum werden cross-

funktional zusammengestellt. Dadurch wird gewährleistet, dass alle Fähigkeiten vor-

handen sind, um das Produkt zu entwickeln. Außerdem zeichnen sich die Entwick-

lungsteams bei Scrum dadurch aus, dass sie ihre Organisation selbst bestimmen.

Bei der XP-Methode ist dies nicht möglich, da hier übergeordnete Rollen die Arbeit


38

organisieren. Der Scrum Master agiert bei Scrum als Coach und sorgt dafür, dass die

Methoden und Techniken angewandt und verstanden werden. Auch die anderen

Modelle sehen teilweise die Rolle eines Coaches vor, der dafür sorgt, dass die ein-

zelnen Techniken angewandt werden. Ein weiteres Merkmal von Scrum sind die vor-

handenen Artefakte, wodurch sich die Dokumentation bei Scrum als aufwendig be-

schreiben lässt. Alle Anforderungen, die das Produkt betreffen, werden im Product

Backlog dokumentiert. Hier gibt es erneut Parallelen zu der XP-Methode, bei der alle

Anforderungen mit Story-Cards dokumentiert werden. Scrum besitzt des Weiteren

ein Sprint Backlog, das sich aber mit der Feature-Liste bei FDD vergleichen lässt.

Hier werden lediglich die Anforderungen dokumentiert, die in der jeweiligen Iteration

eingebunden sind. Ergänzend dazu wird bei Scrum eine Definition of Done erstellt,

wodurch sichergestellt werden soll, dass alle Teammitglieder das gleiche Verständnis

davon haben, wann ein Produkt fertig ist. Das Spiralmodell, die XP-Methode oder

FDD definieren ein solches Artefakt nicht. Durch das Ablaufen von Iterationen bieten

alle Modelle eine gewisse Flexibilität. So kann schnell auf neue Anforderungen rea-

giert werden. Die Anforderungen können sich im Laufe des Projekts außerdem ent-

wickeln und verfeinern.

Spezifische Merkmale von Scrum

Nicht spezifische Merkmale von Scrum

Meeting: Sprint Planning, Retrospektive Meeting: Daily Scrum, Sprint Review

Timeboxing Sehr gute Transparenz

Cross-Funktionale Teams Artefakte: Product Backlog, Inkrement, Sprint Backlog

Selbstorganisierte Teams Coaching der Mitglieder

Rollen Sehr gute Flexibilität

Kein hierarchisches Rollenmodell Einbeziehung des Kunden

Artefakte: Definition of Done Überprüfung der Produktinkremente

Iterationsdauer maximal 1 Monat Entwicklung anhand von Iterationen

Sprint mit definierten Ereignissen Tabelle 1: Spezifische und nicht spezifische Merkmale von Scrum

6 Zusammenfassung

39

6 Zusammenfassung

In der vorliegenden Arbeit sollten die spezifischen Merkmale von Scrum im Vergleich

zum iterativen Planungsansatz herausgearbeitet werden.

Der iterative Planungsansatz besteht aus dem Grundsatz, ein Produkt oder ein Er-

gebnis in mehreren Iterationsschleifen zu erarbeiten. Dabei findet in jeder Iteration

zum selben Zeitpunkt ein Meeting statt, bei dem die Ergebnisse der Iteration bespro-

chen werden. Bereits am Ende der ersten Iterationsschleife muss ein Ergebnis vor-

liegen, das die spätere Lösung in ihren Grundzügen beinhaltet. Dieses Ergebnis wird

in den nachfolgenden Iterationen weiter optimiert und erweitert, so lange bis in der

letzten Iteration die Lösung vorliegt.

Die Scrum-Methode geht von der Prämisse aus, dass ein Softwareprojekt aufgrund

seiner vorhandenen Komplexität nur bedingt durchgängig planbar ist. Die Scrum Me-

thode versucht daher durch seine Vorgehensweise, diese Komplexität durch die An-

nahmen Transparenz, Überprüfung und Anpassung zu vereinfachen. Scrum definiert

folgende drei Rollen: Der Product Owner ist für die Wertsteigerung und Arbeit des

Entwicklungsteams verantwortlich und sorgt für die ständige Einbeziehung des Kun-

den. Das Entwicklungsteam ist für die Umsetzung der geplanten Backlog Items zu-

ständig, wohingegen der Scrum Master sicherstellt, dass die Scrum-Methoden

durchgeführt sowie die Techniken und Regeln eingehalten werden.

Darüber hinaus gibt Scrum vier verschiedene Meetings vor:

Stets zu Beginn eines neuen Sprints wird das Sprint Planning abgehalten. Das Daily

Scrum dient dagegen zur Besprechung der Tagesaufgaben und findet täglich für ma-

ximal 15 Minuten statt. Am Ende eines Sprints wird das Sprint Review durchgeführt,

wobei die Ergebnisse des vorhergegangenen Sprints vorgestellt und bei Bedarf An-

passungen am Product Backlog vorgenommen werden. Abschließend findet die Ret-

rospektive statt, deren Ziel es ist, Verbesserungspotentiale zu erarbeiten, die im

nachfolgenden Sprint umgesetzt werden.

Abschließend lässt sich sagen, dass Scrum zwar Parallelen zu den iterativ-

inkrementellen Vorgehensmodellen aufweist, aber dennoch Merkmale besitzt, die

spezifisch für Scrum sind. Diese sind beispielsweise einzeln definierte Rollen oder

Meetings. Weitere Merkmale lassen sich in Kapitel 5.4 finden.

7 Fazit

40

7 Fazit

Das Ziel der vorliegenden Arbeit lag darin, herauszufinden, welche typischen Merk-

male die Scrum-Methode sowie allgemeine iterative Vorgehensmodelle besitzen.

Anhand dieser typischen Merkmale sollte herausgearbeitet werden, inwiefern die

Scrum-Methode spezifische und nicht spezifische Merkmale besitzt. Auf Grundlage

dessen wurden zu Beginn allgemeine Vorgehensmodelle betrachtet, um ein grundle-

gendes Verständnis zu schaffen. Die Scrum-Methode wurde in Kapitel 3 ausführlich

dargelegt. Es wurden typische Merkmale, speziell beim Rollenmodell, den stattfin-

denden Ereignissen oder den vorhandenen Artefakten aufgezeigt. Anhand der re-

cherchierten Merkmale wurde in Kapitel 5 ein Vergleich zu verschiedenen Vorge-

hensmodellen durchgeführt. Es konnten mehrere spezifische sowie nicht spezifische

Merkmale der Scrum-Methode herausgearbeitet werden. Insbesondere im Bereich

des Rollenmodells, der Meetings aber auch den Artefakten gab es mehrere Unter-

schiede, aber auch Parallelen zu anderen Modellen. Während der Recherche zu ite-

rativen Vorgehensmodellen zeigte sich, dass häufig eine Mischung aus iterativen und

inkrementellen Planungsansätzen eingesetzt wird. Auch die Scrum-Methode besitzt

Eigenschaften beider Planungsansätze. Für den Vergleich zu den iterativen Vorge-

hensmodellen wurden aus diesem Grund ebenfalls Modelle herangezogen, die itera-

tive und inkrementelle Ansätze besitzen. Abschließend lässt sich sagen, dass sich

iterative Modelle vor allem durch ihr hohe Flexibilität sowie Transparenz auszeich-

nen.

Die wesentlichen Unterschiede zeigten sich im Rollenmodell, bei dem die Scrum-

Methode auf interdisziplinäre Teams setzt und sich alle Teammitglieder auf Augen-

höhe begegnen, wobei keiner alleine für das Projekt verantwortlich ist. Ergänzend

dazu ist die Selbstorganisation des Teams ein wichtiges Merkmal von Scrum.

Diese Projektarbeit konnte demzufolge mehrere Unterschiede sowie Parallelen der

Scrum-Methode zu iterativ-inkrementellen Vorgehensmodellen aufzeigen. Um jedoch

eine noch umfassendere Aussage über die spezifischen Merkmale der Scrum-

Methode treffen zu können, müssten in weiteren Arbeiten ergänzend weitere Modelle

betrachtet werden.

Literaturverzeichnis

V


Broy, M. & Gronau, N., 2009. Gestaltung interorganisationaler Software-

Entwicklung. Berlin: GITO-Verlag.

Bunse, C. & Knethen, A., 2002. Vorgehensmodelle kompakt. Berlin: Spektrum

Akademischer Verlag.

Dräther, R., Koschek, H. & Sahling, C., 2013. Scrum kurz& gut. 1. Auflage

Heidelberg: O`Reilly Verlag GmbH & Co. KG.

Hense, A., 2012. Evaluierung agiler Vorgehnsmodelle in der Softwareentwicklung,

Hamburg: Hochschule für Angewandte Wissenschaften.

Gessler, M., 2014. Kompetenzbasiertes Projektmanagement (PM3). 6. Auflage

Nürnberg: GPM Deutesche Gesellschaft für Projektmanagement.

Linz, T., 2013. Testen in Scrum-Projekten Leitfaden für Softwarequalität in der agilen

Welt. 1. Auflage Heidelberg: dpunkt.verlag.

Roock, S. & Wolf, H., 2016. Scrum verstehen und erfolgreich einsetzten. 1. Auflage

Heidelberg: dpunkt.verlag.

Oestereich, B. & Weiss, C., 2008. Agiles Projektmanagement: Erfolgreiches

Timeboxing für IT-Projekte. 1. Auflage Heidelberg: dpunkt.

Internetquellen

Angermeier, G., 2004. Projekt Magazin. [Online]

https://www.projektmagazin.de/glossarterm/spiralmodell

[Zugriff am 5. September 2016].


VI

Franz, B., 2012. RWTH - Aachen. [Online]

http://dme.rwth-aachen.de/en/system/files/file_upload/course/12/proseminar-

methoden-und-werkzeuge/cameraready-extremeprogramming.pdf


Fritsche, M., 2007. In Tum. [Online]

https://www4.in.tum.de/publ/papers/TUM-I0717_neu.pdf


Hörger, M., 2010. Iterative Prozessmodelle/SCRUM. [Online]

http://www.vis.unistuttgart.de/plain/vdl/vdl_upload/300_17_

09ausarbeitung.pdf


Lieder, T., 2008. setzweinblog. [Online]

http://blog.setzwein.com/2008/02/21/inkrementelles-und-iteratives-vorgehen/


Rumpe, B., 2001. TU München - Fakultät für Informatik. [Online]

https://www4.in.tum.de/misc/perlen/perlen-folien/rumpe-xp-folien.pdf


Schilling, A., 2016. projectcafe24. [Online]

http://www.projectcafe24.de/scrum.html


Sutherland, J. & Schwaber, K., 2013. Der Scrum Guide. [Online]

http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-DE.pdf

[Zugriff am 25. August 2016].

VII

Anhang:

Eidesstattliche Versicherung:

Hiermit erklären wir, Carina Schönberger, 185933 und Michael Thomas, 185399, ei-

desstattlich, dass die vorliegende Arbeit von uns selbständig und ohne unerlaubte

Hilfe angefertigt worden ist und dass wir alle Stellen, die wörtlich oder annähernd

wörtlich aus Veröffentlichungen entnommen sind als Zitate gekennzeichnet haben.

Ferner haben wir die Herkunft aller Daten, Zahlen, Abbildungen, Karten u. Fotos

eindeutig belegt.

__________________ __________________

Ort, Datum Unterschrift

__________________ __________________

Ort, Datum Unterschrift

Projektarbeit Das Planungskonzept in Scrum im Vergleich zu ...€¦ · Projektarbeit Das Planungskonzept in Scrum im Vergleich zu allgemeinen Ansätzen der iterativen Projektplanung

Documents

Projektarbeit Das Planungskonzept in Scrum im Vergleich zu ...€¦ · Projektarbeit Das Planungskonzept in Scrum im Vergleich zu allgemeinen Ansätzen der iterativen Projektplanung