Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
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.
(vgl. Dräther, u.a., 2013, S. 66 ff.; vgl. Sutherland & Schwaber, 2013, S. 6 f.)
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.
(vgl. Dräther, u.a., 2013, S. 75 ff.; vgl. Sutherland & Schwaber, 2013, S. 9 f.)
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.
(vgl. Dräther, u.a., 2013, S. 86 ff.; vgl. Sutherland & Schwaber, 2013, S. 11 f.)
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
4 Iterativ-inkrementelle Vorgehensmodelle
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
4 Iterativ-inkrementelle Vorgehensmodelle
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
4 Iterativ-inkrementelle Vorgehensmodelle
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
4 Iterativ-inkrementelle Vorgehensmodelle
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.
4 Iterativ-inkrementelle Vorgehensmodelle
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
4 Iterativ-inkrementelle Vorgehensmodelle
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
5 Scrum im Vergleich zu iterativen Vorgehensmodellen
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.
5 Scrum im Vergleich zu iterativen Vorgehensmodellen
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
5 Scrum im Vergleich zu iterativen Vorgehensmodellen
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-
5 Scrum im Vergleich zu iterativen Vorgehensmodellen
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.
5 Scrum im Vergleich zu iterativen Vorgehensmodellen
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.
5 Scrum im Vergleich zu iterativen Vorgehensmodellen
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.
5 Scrum im Vergleich zu iterativen Vorgehensmodellen
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
5 Scrum im Vergleich zu iterativen Vorgehensmodellen
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-
5 Scrum im Vergleich zu iterativen Vorgehensmodellen
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
5 Scrum im Vergleich zu iterativen Vorgehensmodellen
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
Literaturverzeichnis
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].
Literaturverzeichnis
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
[Zugriff am 19. September 2016].
Fritsche, M., 2007. In Tum. [Online]
https://www4.in.tum.de/publ/papers/TUM-I0717_neu.pdf
[Zugriff am 18. September 2016].
Hörger, M., 2010. Iterative Prozessmodelle/SCRUM. [Online]
http://www.vis.unistuttgart.de/plain/vdl/vdl_upload/300_17_
09ausarbeitung.pdf
[Zugriff am 2. September 2016].
Lieder, T., 2008. setzweinblog. [Online]
http://blog.setzwein.com/2008/02/21/inkrementelles-und-iteratives-vorgehen/
[Zugriff am 18. September 2016].
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
[Zugriff am 20. September 2016].
Schilling, A., 2016. projectcafe24. [Online]
http://www.projectcafe24.de/scrum.html
[Zugriff am 19. September 2016].
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