Top Banner
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: michithomas91@gmail.com Abgabedatum: 05. Oktober 2016
49

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

Apr 30, 2020

Download

Documents

Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
  • 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: michithomas91@gmail.com

    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

    file:///C:/Michi/Studium/PPM6/Projektarbeit/Projektarbeit%202016.docx%23_Toc463173072file:///C:/Michi/Studium/PPM6/Projektarbeit/Projektarbeit%202016.docx%23_Toc463173073file:///C:/Michi/Studium/PPM6/Projektarbeit/Projektarbeit%202016.docx%23_Toc463173074file:///C:/Michi/Studium/PPM6/Projektarbeit/Projektarbeit%202016.docx%23_Toc463173075file:///C:/Michi/Studium/PPM6/Projektarbeit/Projektarbeit%202016.docx%23_Toc463173076file:///C:/Michi/Studium/PPM6/Projektarbeit/Projektarbeit%202016.docx%23_Toc463173077file:///C:/Michi/Studium/PPM6/Projektarbeit/Projektarbeit%202016.docx%23_Toc463173078file:///C:/Michi/Studium/PPM6/Projektarbeit/Projektarbeit%202016.docx%23_Toc463173079

  • 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än