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

Transkript

1 Projektarbeit Das Planungskonzept in Scrum im Vergleich zu allgemeinen Ansätzen der iterativen Projektplanung Studiengang: Betreuer: Produktion und Prozessmanagement M.Sc. Matthias Albert Verfasser/-in: Carina Schönberger (Matr.-Nr.: ) Michael Thomas (Matr.-Nr.: ) Kontaktdaten: Abgabedatum: 05. Oktober 2016

2 Inhaltsverzeichnis 1 Einleitung Vorgehensmodelle Iterativer Planungsansatz Inkrementeller Planungsansatz Iterativ-inkrementeller Planungsansatz Scrum Werte und Prinzipien von Scrum Scrum Flow und der Sprint Rollen Product Owner Entwicklungsteam Scrum-Master Meetings Sprint Planning Daily Scrum Sprint Review Retrospektive Artefakte Product Backlog Sprint Backlog Inkrement Definition of Done Iterativ-inkrementelle Vorgehensmodelle Spiralmodell Extreme Programming I

3 4.3 Feature-Driven-Development Scrum im Vergleich zu iterativen Vorgehensmodellen Vergleich: Scrum Spiralmodell Vergleich: Scrum Extreme Programming Vergleich: Scrum Feature-Driven-Development Zusammenfassende Darstellung der Ergebnisse Zusammenfassung Fazit Literaturverzeichnis... V II

4 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 Abbildung 6: Ablauf Spiralmodell Abbildung 7: Extreme Programming Prozess-Ablauf Abbildung 8: Feature Driven Develeopment Phasenablauf III

5 Tabellenverzeichnis Tabelle 1: Spezifische und nicht spezifische Merkmale von Scrum IV

6 1 Einleitung 1 Einleitung Im Rahmen des Studiums im Studiengang Produktion und Prozessmanagement soll eine Projektarbeit verfasst werden, bei der die Studenten eine speziell hierfür ausgewä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 heranzuführen und ihre Kenntnisse im Verfassen von wissenschaftlichen Arbeiten zu vertiefen. Außerdem wird die Möglichkeit geboten, bereits erworbene Kenntnisse im Bereich des Projektmanagements anzuwenden. Die vorliegende Projektarbeit beschäftigt sich mit folgendem Thema: Das Planungskonzept in Scrum im Vergleich zu allgemeinen 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 Planungsansatzes in die vorhandenen Vorgehensmodelle und Planungsansätze vorgenommen. Darauf folgt die Erläuterung des iterativen Planungsansatzes. Im Laufe der Arbeit wird sich zeigen, dass dem inkrementellen Planungsansatz hierbei eine tragende 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 iterativinkrementellen Vorgehensmodelle eingegangen. Abschließend erfolgt im letzten Kapitel der Arbeit der Vergleich zwischen Scrum und den vorgestellten iterativen Vorgehensmodellen. 1

7 2 Vorgehensmodelle 2 Vorgehensmodelle Im kompetenzbasierten Projektmanagement wird zwischen drei grundlegenden Modellen 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 ausgerichtet, 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 vorhergehenden Phase dienen dabei als Arbeitsgrundlage für die darauffolgende Phase. Das Wasserfallmodell ist hierbei als führendes Modell zu nennen. Dabei sind Rückschritte in die vorherige Phase zwar erlaubt, allerdings nur, um begangene Fehler zu korrigieren. Voraussetzung für die Anwendung eines sequentiellen Vorgehensmodells sind stabile Anforderungen und klare Zieldefinitionen. Sind diese nicht gegeben, wird das Projekt unter Anwendung eines sequentiellen Modells scheitern. Grund hierfü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 Fertigstellung erforderlichen Phasen (Analyse, Entwurf, Implementierung, etc.), bevor ein weiteres Inkrement bearbeitet wird. Im Zuge dessen wird die Komplexität mit jedem 2

8 2 Vorgehensmodelle Inkrement erhöht. Dieses Vorgehen ist schematisch in folgender Abbildung dargestellt: Abbildung 1: Darstellung wiederholender Modelle, Quelle: Gessler, 2014 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 angewendet, wenn Anforderungen instabil sind beziehungsweise Ziele nur vage definiert werden können. In diesem Fall könnte z. B. mit den sichersten Anforderungen begonnen werden, um dann mit wachsender Erfahrung Sicherheit zu gewinnen. Notwendig 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 durchlaufen 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 vorhergehenden Projekten gearbeitet. Dieses Vorgehen wird mit Hilfe der nachfolgenden Grafik verdeutlicht: 3

9 2 Vorgehensmodelle Abbildung 2: Darstellung wiederverwendbarer Modelle, Quelle: Gessler, 2014 Durch das Zurückgreifen auf Erfahrungen aus anderen Projekten können Prototypen schneller entwickelt werden. Nachteilig kann sein, dass wiederverwendete Ergebnisse, 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 Abbildung ersichtlich, aus den Aktivitäten Analysieren, Entwerfen, Codieren und Testen. (vgl. Hörger, 2010) Abbildung 3: Darstellung Iterationsschleife In jeder Iteration findet zum selben Zeitpunkt ein Meeting statt, bei dem die Ergebnisse 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 Erfahrungswerte einer Iteration in den nächsten Iterationsschritt mit ein. Es findet also 4

10 2 Vorgehensmodelle eine stetige Verbesserung des Prozesses statt. (Hörger, 2010, S. 3) Dies wird in folgender Grafik verständlich. Abbildung 4: Abfolge von Iterationsschleifen Der Nutzen des iterativen Planungsansatzes liegt in der Möglichkeit, das Projekt jederzeit nach einer beliebigen Iteration zu beenden. Ist beispielsweise der Auftraggeber 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 Vorgehen vor und lässt das Projekt mehrere Iterationsschleifen durchlaufen. Innerhalb jeder Schleife werden die Ziele dabei überarbeitet und an alle Betreffenden kommuniziert. (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 Dieses erste iterative Vorgehensmodell wurde von Winston Royce publiziert. Die erfolgreich entwickelten US-Militär- 5

11 2 Vorgehensmodelle Standards deuten auf den Erfolg hin, zu dem dieses Modell verhilft. Auch David Maibor, 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 (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 nacheinander erarbeitet werden. Ein Grundprodukt wird also schrittweise um weitere Inkremente (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 Vorgehensweisen kombiniert. Größere Funktionspakete werden inkrementell nacheinander 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 Auftraggeber bereits bei der ersten Iteration seine Meinung miteinbringen und somit teure Ä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 inkrementell-iteratives Vorgehen beschrieben wird (vgl. Rumpe, 2001; Oestereich & Weiss, 2008, S. 13) 6

12 3 Scrum 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 verschiedene 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 gehö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 Methode geht von der Prämisse aus, dass ein Softwareprojekt aufgrund seiner vorhandenen Komplexität nur bedingt durchgängig planbar ist. Die Scrum Methode versucht daher, durch seine Vorgehensweise, diese Komplexität durch eine oder mehrere Annahmen zu vereinfachen. Diese Annahmen werden im Folgenden aufgeführt: 1. Transparenz: Der Status des Projekts wird in täglichen Meetings innerhalb eines Sprints dauerhaft erfasst und kontrolliert. 2. Überprüfung: In regelmäßigen Abständen werden die Produktinkremente geliefert, 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 meistern. Scrum besteht allerdings nicht nur aus einem Planungsansatz, sondern verwendet eine Mischung des iterativen und inkrementellen Ansatzes. Ergänzend dazu zeichnet die Scrum Methode außerdem die stetige Weiterentwicklung und Verbesserung von Prozessen, Methoden und Mitarbeitern aus, um eine dauerhaft hohe Qualität zu gewährleisten. Dabei unterliegt Scrum immer den Grundsätzen des Agilen Manifests: 7

13 3 Scrum 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 Implementierung dieser Grundsätze und Annahmen dar. (Hörger, 2010) Scrum bietet als Rahmenwerk demnach kein striktes Vorgehen nach diesen Regeln, sondern sie lassen 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 werden. Diese stellen grundlegende Eigenschaften dar, um ein erfolgreiches Einsetzen der Scrum-Methode ermöglichen zu können. Laut Scrum-Guide werden keine expliziten 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 Produkt sowie im Prozess. Respekt: Um gemeinsame Lösungen erarbeiten zu können sowie für ein Miteinander, 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. 8

14 3 Scrum 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 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. 9

15 3 Scrum Am Anfang eines jeden Projekts steht eine Vision, wie ein Endprodukt aussehen könnte. Anhand dieser Vision werden Eigenschaften abgeleitet, die das Produkt haben muss oder könnte. Diese Eigenschaften und Anforderungen werden in einem Product Backlog dokumentiert und als Backlog Items bezeichnet. Durch einen Product 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 genaue Inhalt und die Merkmale eines Sprints werden im folgenden Abschnitt genauer erläutert. (vgl. Roock & Wolf, 2016, S. 17 f.) Abbildung 5: Scrum Prozess-Ablauf 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 Produktinkrement 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 näher erläutert. Ein Sprint zeichnet sich durch eine festgelegte Länge, eine einheitliche innere Struktur und ein definiertes Ergebnis aus. Die Länge eines Sprints wird im Vorfeld definiert. Dabei ist zu beachten, dass jeder Sprint innerhalb eines Projekts die gleiche Dauer hat. Der Effekt aus dieser Regel ist, dass sich 10

16 3 Scrum 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 beachtet werden müssen, z.b. Fehlzeiten von Mitgliedern durch Urlaube oder regelmäßiges 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 langer Sprint das Risiko von unerwarteten Fehlern erhöhen kann. Das Entwicklungsteam 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 minimal 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, sollen 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 Anpassungen vorgenommen werden. Deshalb kann für den nächsten Sprint eine Anpassung 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 Unternehmen 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 ergänzend dazu verliert die bereits erbrachte Leistung schnell an Wert. Im letzten Abschnitt der Ausführungen zu den Sprints soll noch näher auf die verschiedenen Ereignisse 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 Retrospektive durchgeführt. Außerdem wird täglich ein Daily Scrum abgehalten. Die Inhal- 11

17 3 Scrum te der einzelnen Meetings werden in Kapitel 3.4 erläutert. Die Aufgabenverteilung innerhalb eines Sprints unterliegt ebenfalls einer klaren Ordnung. Das Entwicklungsteam ist für die Umsetzung der Backlog Items verantwortlich. Der Product Owner unterstützt das Entwicklungsteam und erarbeitet schon während des aktuellen Sprints die Backlog Items, die im nächsten Sprint umgesetzt werden sollen. Der Scrum Master 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 Anschluss immer der nächste Sprint. Dies hat den Vorteil, dass die Ergebnisse des vorherigen Sprints noch frisch in Erinnerung sind und wichtige Informationen nicht vergessen werden. Deshalb sollte bei der Taktung eines Sprints darauf geachtet werden, 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, genauer beschrieben. Diese drei Rollen zusammen bilden das Scrum-Team. Die Zusammenarbeit 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 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 dokumentiert er im Product Backlog. Eine der Hauptaufgaben des Product Owner sind die Pflege und Erstellung des Product Backlog. Dies umfasst laut Scrum-Guide folgende Aufgaben: 12

18 3 Scrum 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 verantwortlich bleibt. Die Rolle des Product Owner muss immer eine einzelne Person besetzen 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 zwischen beiden ist dabei von grundlegender Bedeutung. Kontinuierlich werden Anforderungen 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 Ausblick 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 13

19 3 Scrum 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) 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 Ende 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 innerhalb 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 ganze 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 haben, um das Produkt zu entwickeln. Die Größe des Entwicklungsteams wird laut Scrum-Guide zwischen drei und neun Mitgliedern definiert. Diese Anzahl wurde festgelegt da bei einem Team mit weniger als drei Mitgliedern die Gefahr besteht, dass innerhalb des Teams wichtige Fähigkeiten zur Umsetzung des Produkts nicht gegeben sind. Bei einem zu großen Team mit über neun Mitgliedern nimmt der organisatorische 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) 14

20 3 Scrum 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 entscheidender 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 innerhalb des Unternehmens eine Führungsrolle besitzt. Dadurch besitzt er bereits das Vertrauen des Managements. Er hat aber gegenüber dem Scrum-Team keine disziplinarische 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 beispielsweise 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 eindeutigen Product Backlog Einträgen. Außerdem achtet er darauf, dass der Product Owner und das Entwicklungsteam eng zusammenarbeiten und sich auch regelmäßig austauschen. 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.) 15

21 3 Scrum 3.4 Meetings Im diesem Kapitel soll ein Überblick über die verschiedenen Ereignisse in Scrum gewonnen werden. Laut dem Scrum-Guide wird dabei zwischen vier Meetings während dem Scrum-Prozess unterschieden. Einige dieser Meetings finden nur einmal je Projekt 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 Meetings 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) Sprint Planning Das Sprint Planning wird immer zu Beginn eines neuen Sprints abgehalten. Das gesamte 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 Organisation 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) 16

22 3 Scrum Erst nachdem beide Inhalte besprochen wurden, ist das Sprint Planning abgeschlossen. Sprint Planning Teil 1 Am ersten Teil des Meetings nimmt das gesamte Scrum-Team teil, damit alle Teammitglieder verstehen, um was es in den anfallenden Sprint geht. Dieser Teil des Meetings bezieht sich hauptsächlich auf die fachliche Ebene. Die Basis für die beginnende Planung bilden das Product Backlog sowie der aktuelle Entwicklungsstand des Produkts. Zu Beginn stellt der Product Owner die nach ihrer Priorität sortierten Backlog 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 Diskussion lediglich auf der fachlichen Ebene stattfindet, sodass technische Aspekte zunächst ausgeklammert werden. "Alle Mitglieder des Scrum-Teams tragen in dieser Phase durch gezieltes Nachfragen 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 dieser 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 Entwicklungsteam darf über die Anzahl der Backlog Items entscheiden, da sie für die Umsetzung der Backlog Items verantwortlich sind. Auf dieser erarbeiteten Basis definiert 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 folgenden 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 technischen 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- 17

23 3 Scrum 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 abschätzen können, ob alle geplanten Produktinkremente während des Sprints erarbeitet 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 Meetings 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.) Daily Scrum Der Daily Scrum wird täglich abgehalten, dauert maximal 15 Minuten und sollte möglichst 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 abgeglichen und synchronisiert. Teilnehmer des Meetings ist das Scrum-Team. Die Mitglieder 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 betonen ist an dieser Stelle, dass es im Daily Scrum nicht darum geht, wie etwas erreicht wurde, sondern was erreicht wurde. Der Status des Projekts soll demnach deutlich werden. Es muss klar erkennbar sein, an welchen Produktinkrementen aktuell 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 18

24 3 Scrum 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 Hindernissen. 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.) Sprint Review Am Ende eines Sprints wird das Sprint Review durchgeführt. Hier werden die Ergebnisse 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 Management oder auch der Kunde des Produkts sein. Das Entwicklungsteam stellt alle neuen Funktionen vor, die im Sprint neu erarbeitet wurden. Dabei ist hervorzuheben, dass keine halbfertigen Produktinkremente gezeigt werden. Es soll nur das präsentiert werden, was auch wirklich fertig ist. Das Entwicklungsteam beantwortet aufkommenden Fragen und schildert eventuell Probleme, die bei der Umsetzung aufgetreten sind. Während des Meetings gleicht der Product Owner, die Ergebnisse anhand des Sprint Backlog ab, um zu sehen, welche Anforderungen erfüllt wurden oder noch bearbeitet werden müssen. Sollte festgellt werden, dass geplante Anforderungen nicht umgesetzt wurden, muss das Entwicklungsteam schildern, aufgrund welcher 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ächsten 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.) 19

25 3 Scrum Retrospektive Die Scrum Methode basiert auf der ständigen Weiterentwicklung, nicht nur der Mitarbeiter, sondern auch des Scrum Prozesses. Dazu wird nach dem Sprint Review eine Retrospektive abgehalten. Das Ziel der Retrospektive ist es, Verbesserungspotentiale 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. Zunä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 wichtigsten Voraussetzungen für ein erfolgreiches Meeting ist das Schaffen eines geschützten 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 Backlog, das Sprint Backlog sowie das Inkrement. In weiteren Quellen wird aber auch die Definition of Done genannt. Im Folgenden werden diese vier Artefakte genauer vorgestellt. Ziel der Artefakte bei Scrum ist es, eine größtmögliche Transparenz über die 20

26 3 Scrum Schlüsselinformationen im Projekt zu erhalten. Die Artefakte helfen dem Scrum- Team, einen Überblick über das Projekt zu bekommen und diesen zu bewahren Product Backlog Die Verantwortung über das Product Backlog unterliegt wie bereits in Kapitel 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 Komplexitä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 Anforderungen sind nur grob beschrieben. Das Product Backlog muss ausreichend genau detailliert 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 kontinuierlich 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 Erscheinungsformen haben. Diese können beispielsweise eine einfache Sammlung von Story Cards sein oder auch mit unterschiedlichen Tool, wie einer Exel-Liste, realisiert werden. 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.) 21

27 3 Scrum 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 Entwicklungsteam 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 ausgearbeitet 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 weiterentwickelt. (vgl. Sutherland & Schwaber, 2013, S. 15) Inkrement Als Inkrement werden die einzelnen Ergebnisse des Sprints bezeichnet. Diese enthalten 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 gelten. Es entsteht ein potentielles auslieferbares Produktinkrement. Die Summe der einzelnen Produktinkremente bildet am Ende eines Projekts das fertige Produkt Definition of Done Damit festgestellt werden kann, ob die Anforderungen an die Qualität eines Produktinkrements erreicht wurden, muss ein gemeinsames Verständnis geschaffen werden. Deshalb wird zu Beginn eines Projekts oder Sprints eine Definition of Done festgelegt. 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 realisiert werden. Eine Definition of Done entwickelt sich meist iterativ zu dem Produktinkrement. 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.) 22

28 4 Iterativ-inkrementelle Vorgehensmodelle 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 mehrere Risikoanalysen über den Projektverlauf hinweg vor. Auf Änderungen bezüglich der Ergebniserwartungen oder auch Änderungen bezüglich der eventuellen Risiken eines 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,

29 4 Iterativ-inkrementelle Vorgehensmodelle 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); Festlegung von Alternativen (u.a. Lösungsvarianten, Wiederverwendung, Zukauf); Bestimmung der Einschränkungen (u.a. Kosten, Termine, Schnittstellen) Entwicklungsrisiken (Quadrant II): Bewertung von Alternativen; Aufdeckung von Risikoquellen (Produktrisiko: Aufgabenstellung, 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ötigte Ressourcen) Diese vier Quadranten werden während eines Projekts immer wieder durchlaufen. Die nächste Entwicklungsstufe darf jedoch erst begonnen werden, wenn die Ergebnisse der Vorstufe abgenommen wurden. Konnten alle Risiken in mehreren Durchlä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. Einer 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 24

30 4 Iterativ-inkrementelle Vorgehensmodelle 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 Abbildung 7: Extreme Programming Prozess-Ablauf, Quelle: Franz, 2011 In der zweiten Phase, der Iterationsphase, die ebenfalls 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 nennen: 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 Ressourcen, Kosten, Zeitpläne, um damit eine optimale Qualität zu erreichen. (Rumpe, 2001, S. 8) 25

31 4 Iterativ-inkrementelle Vorgehensmodelle 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änderung, Veränderung wollen, Qualitätsarbeit, lernen lehren, geringe Anfangsinvestition, auf Sieg spielen, gezielte Experimente, offene und aufrichtige Kommunikation, Instinkte 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 Programming 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 Folgenden 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 Methode läuft in fünf Phasen ab, die sich in Planung und Entwurf aufteilen, wie die Abbildung 8 zeigt. Bei einer Projektdauer von 6 Monaten ist der Zeitrahmen für die ersten 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. 26

32 4 Iterativ-inkrementelle Vorgehensmodelle Abbildung 8: Feature Driven Develeopment Phasenablauf Erste Phase: Erstelle das Gesamtmodell In der Phase von FDD nehmen ausgewählte Experten teil, die von Seiten des Projektleiters 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 Systementwurf 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 Umsetzung der ausgewählten Features innerhalb von zwei Wochen achtet. Es werden Se- 27

33 4 Iterativ-inkrementelle Vorgehensmodelle quenzdiagramme erstellt, die Klassenmodelle verfeinert und Klassenbesitzer bestimmt, wodurch sich die Features Teams bilden. Fünfte Phase: Entwickle je Feature In dieser Phase erfolgt die Implementierung der bestimmten Klassen durch ihre Besitzer. Damit die Qualität der Features bestimmt werden kann, werden in dieser Phase 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.) 28

34 5 Scrum im Vergleich zu iterativen Vorgehensmodellen 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 unterschiedlichen 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 vorhergegangenen 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. 29

35 5 Scrum im Vergleich zu iterativen Vorgehensmodellen Transparenz Auch das Spiralmodel hat wie Scrum eine gute Transparenz. Aufgrund der Iterationen können am Ende jeder Iteration Anpassungen an den Anforderungen vorgenommen werden. Der Kunde hat die Möglichkeit am Ende der Iteration, das Produkt zu begutachten. Dadurch ist ihm der Fortschritt der Produktentwicklung ständig bekannt. 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 Voriteration 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 Iterationsdauerkann entsprechend flexibel reagiert werden. Analog zum Spiralmodell können bei 30

36 5 Scrum im Vergleich zu iterativen Vorgehensmodellen 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 maximal eine Woche dauert. Am Ende beider Methoden entsteht ein Inkrement des Gesamtprodukts. Aus der Summe der Teilprodukte ergibt sich am Ende das Gesamtprodukt. Meetings Bei XP wird das Standup-Meeting definiert. Die Scrum-Methode hat im Vergleich dazu deutlich mehr Meetings definiert. Das Standup-Meeting ist mit dem Daily Scrum vergleichbar. Beide Meetings finden täglich statt und dienen dazu die geleistete Arbeit 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- 31

37 5 Scrum im Vergleich zu iterativen Vorgehensmodellen den als eine festgelegte Rolle. Bei Scrum wird der Kunde durch die Rolle des Product 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 Methoden 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, Einfachheit 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 Unterschieden. Extreme Programming erfordert nur einen geringen Dokumentationsaufwand. Die Anforderungen des Kunden werden hier lediglich auf Story User Card dokumentiert. Bei Scrum hingegen ist die Dokumentation ein wichtiges Merkmal und entscheidend für den Scrum Prozess. Wie in Kapitel 3.5 beschrieben gibt es mehrere Artefakte, 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 Programming dem Kunden an, eng mit dem Entwicklungsteam zusammenzuarbeiten, was bei Scrum nicht vorgesehen ist. 32

38 5 Scrum im Vergleich zu iterativen Vorgehensmodellen Einarbeitungszeit Extreme Programming ist ein sehr umfangreiches und kompliziertes Vorgehensmodell. 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, sondern 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 Retrospektive 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 Vorfeld, welche Bedingungen das Produkt erfüllen muss. Außerdem kommen verschiedene Arten von Integrationstests und Unit-Test zum Einsatz. Ergänzend dazu spielen ebenfalls die Akzeptanztests eine wichtige Rolle. Die XP-Methode stellt viele Praktiken 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 Auslieferung eines ausgiebig getesteten Produkts gefordert. Demzufolge werden die einzelnen Inkremente ausgiebig getestet, um eine hohe Qualität voraussetzen zu können. 33

39 5 Scrum im Vergleich zu iterativen Vorgehensmodellen 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 Rolle 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 begutachten. 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 Gesamtprodukts. Meeting Im Gegensatz zur Scrum-Methode definiert Feature-Driven-Development keine Meetings. 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. 34

40 5 Scrum im Vergleich zu iterativen Vorgehensmodellen 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 Rollen. Die Schlüsselrollen wurden bereits in Kapitel 4.3 dargelegt. Die Anzahl des gesamten 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 Dokumentationsaufwand. Besonders die FDD-Methode besitzt viele unterschiedliche Artefakte, die mit Inhalten gefüllt werden müssen. Durch die Dokumentation können alle Mitglieder über Änderungen oder den aktuellen Stand informiert werden. Das ist insbesondere bei FDD wichtig, da aufgrund des hierarchischen Rollenmodells nur die oberen Rollen genau informiert werden. Bis auf den hohen Dokumentationsaufwand sind die Artefakte ansonsten kaum vergleichbar. Die Feature-Liste bei FDD kann gleichgesetzt werden mit dem Sprint Backlog oder Project Backlog von Scrum. Eine Definition 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 Produkt. Mithilfe von festgelegten Meilensteinen während der Planungs- und Entwurfsphase bleibt der Status des Projekts dauerhaft präsent. Allerdings wird die Transparenz aufgrund des hierarchischen Rollenmodels im Vergleich zu Scrum stark eingeschränkt, da untergeordnete Rollen nicht direkt mit Informationen ausgestattet werden. Einarbeitungszeit FDD kann im Vergleich zu Scrum in ausgewählten Unternehmen besser und schneller eingeführt werden. Bei klassisch ausgerichteten Unternehmen kann FDD deshalb sehr schnell eingeführt werden, weil die Rollenmodelle und die Methoden sehr ähnlich sind. Bei agilen Unternehmen ist die Einführung allerdings aufwendiger. Aufgrund der hierarchischen Rollenstruktur ist eine Selbstorganisation des Teams nicht 35

41 5 Scrum im Vergleich zu iterativen Vorgehensmodellen 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 fungiert. 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önnen Verbessrungspotentiale erarbeitet werden, um sie im nächsten Sprint umzusetzen. Qualitätssicherungsmaßnahmen Durch qualifizierte Schlüsselrollen und eine ausgiebige Planung sowie Entwurfsphase 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 Inspektionen 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 beschrieben, 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 Iterationsphasen von maximal zwei Wochen ermöglichen eine schnelle Reaktionszeit auf Änderungen. Dennoch ist dieses Vorgehen deutlich schwergewichtiger als andere Modelle. 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 Planungsphase einbezogen. Zum Abschluss hat er noch die Aufgabe das Ergebnis zu bewer- 36

42 5 Scrum im Vergleich zu iterativen Vorgehensmodellen ten, kann aber während der Entwurfsphase nicht in den Entwicklungsprozess eingreifen. 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 Produktinkrement, 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 Ereignisse 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 Weiterentwicklung des Prozesses ist bei den hier aufgelisteten Modellen nicht genau definiert. 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 crossfunktional zusammengestellt. Dadurch wird gewährleistet, dass alle Fähigkeiten vorhanden sind, um das Produkt zu entwickeln. Außerdem zeichnen sich die Entwicklungsteams 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 37

43 5 Scrum im Vergleich zu iterativen Vorgehensmodellen 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 einzelnen Techniken angewandt werden. Ein weiteres Merkmal von Scrum sind die vorhandenen Artefakte, wodurch sich die Dokumentation bei Scrum als aufwendig beschreiben 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 reagiert werden. Die Anforderungen können sich im Laufe des Projekts außerdem entwickeln und verfeinern. Spezifische Merkmale von Scrum Meeting: Sprint Planning, Retrospektive Timeboxing Cross-Funktionale Teams Selbstorganisierte Teams Rollen Kein hierarchisches Rollenmodell Nicht spezifische Merkmale von Scrum Meeting: Daily Scrum, Sprint Review Sehr gute Transparenz Artefakte: Product Backlog, Inkrement, Sprint Backlog Coaching der Mitglieder Sehr gute Flexibilität 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 38

44 6 Zusammenfassung 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 Ergebnis in mehreren Iterationsschleifen zu erarbeiten. Dabei findet in jeder Iteration zum selben Zeitpunkt ein Meeting statt, bei dem die Ergebnisse 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. 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 Methode versucht daher durch seine Vorgehensweise, diese Komplexität durch die Annahmen 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 Kunden. Das Entwicklungsteam ist für die Umsetzung der geplanten Backlog Items zustä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 maximal 15 Minuten statt. Am Ende eines Sprints wird das Sprint Review durchgeführt, wobei die Ergebnisse des vorhergegangenen Sprints vorgestellt und bei Bedarf Anpassungen am Product Backlog vorgenommen werden. Abschließend findet die Retrospektive 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 iterativinkrementellen 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. 39

45 7 Fazit 7 Fazit Das Ziel der vorliegenden Arbeit lag darin, herauszufinden, welche typischen Merkmale 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 grundlegendes Verständnis zu schaffen. Die Scrum-Methode wurde in Kapitel 3 ausführlich dargelegt. Es wurden typische Merkmale, speziell beim Rollenmodell, den stattfindenden Ereignissen oder den vorhandenen Artefakten aufgezeigt. Anhand der recherchierten Merkmale wurde in Kapitel 5 ein Vergleich zu verschiedenen Vorgehensmodellen 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 Unterschiede, aber auch Parallelen zu anderen Modellen. Während der Recherche zu iterativen 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 Vorgehensmodellen wurden aus diesem Grund ebenfalls Modelle herangezogen, die iterative und inkrementelle Ansätze besitzen. Abschließend lässt sich sagen, dass sich iterative Modelle vor allem durch ihr hohe Flexibilität sowie Transparenz auszeichnen. Die wesentlichen Unterschiede zeigten sich im Rollenmodell, bei dem die Scrum- Methode auf interdisziplinäre Teams setzt und sich alle Teammitglieder auf Augenhö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. 40

46 Literaturverzeichnis Literaturverzeichnis Broy, M. & Gronau, N., Gestaltung interorganisationaler Software- Entwicklung. Berlin: GITO-Verlag. Bunse, C. & Knethen, A., Vorgehensmodelle kompakt. Berlin: Spektrum Akademischer Verlag. Dräther, R., Koschek, H. & Sahling, C., Scrum kurz& gut. 1. Auflage Heidelberg: O`Reilly Verlag GmbH & Co. KG. Hense, A., Evaluierung agiler Vorgehnsmodelle in der Softwareentwicklung, Hamburg: Hochschule für Angewandte Wissenschaften. Gessler, M., Kompetenzbasiertes Projektmanagement (PM3). 6. Auflage Nürnberg: GPM Deutesche Gesellschaft für Projektmanagement. Linz, T., Testen in Scrum-Projekten Leitfaden für Softwarequalität in der agilen Welt. 1. Auflage Heidelberg: dpunkt.verlag. Roock, S. & Wolf, H., Scrum verstehen und erfolgreich einsetzten. 1. Auflage Heidelberg: dpunkt.verlag. Oestereich, B. & Weiss, C., Agiles Projektmanagement: Erfolgreiches Timeboxing für IT-Projekte. 1. Auflage Heidelberg: dpunkt. Internetquellen Angermeier, G., Projekt Magazin. [Online] [Zugriff am 5. September 2016]. V

47 Literaturverzeichnis Franz, B., RWTH - Aachen. [Online] [Zugriff am 19. September 2016]. Fritsche, M., In Tum. [Online] [Zugriff am 18. September 2016]. Hörger, M., Iterative Prozessmodelle/SCRUM. [Online] 09ausarbeitung.pdf [Zugriff am 2. September 2016]. Lieder, T., setzweinblog. [Online] [Zugriff am 18. September 2016]. Rumpe, B., TU München - Fakultät für Informatik. [Online] [Zugriff am 20. September 2016]. Schilling, A., projectcafe24. [Online] [Zugriff am 19. September 2016]. Sutherland, J. & Schwaber, K., Der Scrum Guide. [Online] [Zugriff am 25. August 2016]. VI

48 Anhang: VII