Scrum. Max Jäger. Frankfurt, den 07. Juli 2012

Max Jäger Frankfurt, den 07. Juli 2012 I

Inhalt Inhalt Abkürzungen Abbildungen III IV 1 Scrum 1 1.1 Einführung............................. 1 1.2 Überblick über Scrum....................... 1 1.3 Rollen................................ 2 1.3.1 Product Owner....................... 3 1.3.2 Team............................. 3 1.3.3 ScrumMaster........................ 4 1.4 Product Backlog.......................... 5 1.4.1 User Stories......................... 5 1.4.2 Priorisierung........................ 6 1.4.3 Schätzen........................... 6 1.4.4 Release............................ 7 1.5 Sprints................................ 7 1.5.1 Planung........................... 8 1.5.2 Sprint Backlog....................... 9 1.5.3 Daily-Scrum......................... 10 1.5.4 Sprint-Review........................ 10 1.5.5 Sprint-Retrospektive.................... 11 2 Literatur 12 II

Abkürzungen Abkürzungen OOPSLA....... Object-Oriented Programming, Systems, Languages and Applications III

Abbildungen Abbildungen 1 Überblick über Scrum....................... 2 2 Burndown-Diagramm........................ 8 IV

1 Scrum 1.1 Einführung Scrum ist ein 1996 von Ken Schwaber und Jeff Sutherland auf der OOPSLA 96, einer Konferenz rund um Themen der objektorientierten Softwareentwicklung, vorgestelltes agiles Managementframework zur Entwicklung von Software. 1 Softwareentwicklung ist ein komplexer Prozess. Meistens steht zu Beginn ein großser Plan, welche Funktion der Software wann entwickelt wird und wann das gesamte Projekt abgeschlossen ist. Bei Projekten, deren Dauer drei, sechs oder noch mehr Monate beträgt, ist die genaue Einhaltung eines solchen Plans kaum möglich. Unvorhergesehene Ereignisse, Änderungen der Anforderungen und die Komplexität der Softwareprojekte erfordern ständige Anpassungen des ursprünglichen Plans. Und selbst wenn wir alle Eventualitäten einplanen könnten, und der Benutzer am Ende genau das erhalten würde, was am Anfang definiert wurde, so zeigt die Erfahrung, dass dies meistens nicht das ist, was der Kunde will. Dies lernt der Kunde oft erst im Laufe des Projektes. Hierbei ermöglicht Scrum dem Kunden die aktive Mitgestaltung bei der Entwicklung des Produktes. 2 1.2 Überblick über Scrum Scrum besteht aus wenigen klaren Regeln, Rollen und Artefakten. Kernelement von Scrum sind sogenannte Sprints. Dies sind Arbeitszyklen mit einer maximalen Dauer von bis zu 30 Tagen, die eine Reihe von Anforderungen in ein auslieferbares Produkt, also lauffähige, getestete und dokumentierte Software, umwandeln. In Scrum werden nacheinander immer wieder Sprints durchgeführt, bis alle Anforderungen umgesetzt sind. 3 Alle Anforderungen an die zu entwickelnde Software werden vom Product Owner erarbeitet und in einer Liste, dem Product Backlog, festgehalten und 1 Vgl. Wirdemann, (2011), S. 26. 2 Vgl. Wirdemann, (2011), S. 25. 3 Vgl. Pichler, (2008), S. 7. 1

priorisiert. Der Product Owner ist verantwortlich für die Erreichung der Projektziele. Der Umfang eines jeden Eintrages im Product Backlog wird vom Team abgeschätzt. Das Team besteht aus allen Personen, die für die Umsetzung der Anforderungen notwendig sind. 4 Zu Beginn eines jeden Sprints wird in der Sprint-Planungssitzung das Sprint Backlog mit Anforderungen aus dem Product Backlog befüllt. Das Team entscheidet, welche Anforderungen im nächsten Sprint umzusetzen sind. Danach startet das Team mit der Umsetzung. Eine tägliche Besprechung, Daily-Scrum, ermöglicht die Koordination der Arbeit und Identifizierung von Hindernissen. Die Arbeitsergebnisse am Ende eines Sprints werden im Sprint Review vom Team präsentiert und vom Product Owner abgenommen. In der Sprint-Retrospektive werden die Arbeitsprozesse analysiert und Verbesserungsmaßsnahmen erörtert. 5 Abbildung 1: In Anlehnung an: Schwaber, (2011), S. 117 Überblick über Scrum 1.3 Rollen Scrum kennt die drei Rollen Product Owner, Team und Scrum Master. Nur wenn alle drei Rollen adäquat besetzt sind und eng zusammenarbeiten, können Scrum-Projekte erfolgreich umgesetzt werden. Dafür steht die Aussage des 4 Vgl. Pichler, (2008), S. 10. 5 Vgl. Schwaber, (2011), S. 14. 2

agilen Manifests, dass Individuen und Interaktionen wichtiger sind als Prozesse und Werkzeuge. 6 Der Product Owner sorgt für die Verfolgung der Ziele, in dem er festlegt, welche Anforderungen in welcher Version umzusetzen sind und wann die Software ausgeliefert wird. Mit der Umsetzung der Anforderungen ist das Team betraut, das zuvor entscheidet, welche Anforderungen in welchem Sprint umgesetzt werden. Der Scrum Master unterstützt das Team, in dem er versucht, Hindernisse von ihm fernzuhalten und dabei hilft, die Produktivität ständig zu verbessern. 7 1.3.1 Product Owner Als zentrale Rolle in Scrum repräsentiert der Product Owner die Endkundenbedürfnisse. Er sollte ständig für das Team verfügbar sein, um für Fragen zu Anforderungen zur Verfügung zu stehen, da sowohl Anforderungsbeschreibung als auch Priorisierung zu seinen Aufgaben zählen. Hierzu erstellt und pflegt er das Product Backlog, nimmt Anforderungen auf, löscht und priorisiert sie. Dies setzt engen Kundenkontakt und Verständnis für die Bedürfnisse des Kunden voraus. 8 Neben dem Anforderungsmanagement ist es der Product Owner, der über Auslieferungszeitpunkt, Funktionalität und Kosten der Softwareversion entscheidet. Dafür obliegt ihm die Erstellung und Pflege des Releaseplans. Durch den engen Kundenkontakt und die Verantwortung über das Product Backlog sind dem Product Owner die Kundenbedürfnisse am besten vertraut, und er muss diese an das Team weitergeben und diesem ständig bei Fragen zur Verfügung stehen. Zudem prüft und gibt er die vom Team erzeugten Arbeitsergebnisse frei. 9 1.3.2 Team Das Team setzt die Anforderungen in auslieferbare Produktinkremente um. Da das Ergebnis eines Sprints eine voll funktionsfähige Software ist, besteht das 6 Vgl. Pichler, (2008), S. 9. 7 ebd. 8 Vgl. Pichler, (2008), S. 9-11. 9 ebd. 3

Team somit nicht nur aus Softwareentwicklern, sondern auch aus Architekten, Testern, Dokumentationsexperten, Oberflächenexperten, Datenbankexperten und so weiter. 10 Ein Team besteht idealerweise aus fünf bis neun Mitarbeitern. Ist ein Team größser als neun Personen, steigen die Kommunikationskosten rapide an, ist es kleiner als fünf Personen, so muss sichergestellt werden, dass die Mitarbeiter über alle Fähigkeiten verfügen, um verlässlich die Sprint-Ziele zu Erreichen. 11 Das Team hat sich selbst auf ein Sprint-Ziel verständigt, und somit wird das Team an diesem Ziel gemessen. Es entscheidet selbst, wie es das Ziel erreicht. Diese Freiheit der Selbstorganisation unterscheidet sich häufig von klassisch organisierten Softwareprojekten, bei denen dem Team relativ kleinteilig mitgeteilt wird, welche Aufgabe bis wann zu erledigen ist. Bei Scrum hingegen organisiert sich das Team für die gesamte Dauer des Sprints selbst und übernimmt somit auch die Verantwortung für die Erreichung der Sprint-Ziele. 12 1.3.3 ScrumMaster Der ScrumMaster hat zwei wesentliche Aufgaben: erstens muss er dafür sorgen, dass Scrum richtig eingesetzt wird. Zweitens muss er sich um optimale Arbeitsbedingungen für das Team kümmern. Dabei schützt er das Team vor negativen Einflüssen von Außsen und versucht, Hindernisse zu beseitigen. 13 Im Unterschied zu Projekt- oder Teamleitern hat ein ScrumMaster keine Weisungsbefugnis. Er kann weder Aufgaben verteilen, noch Wochenendarbeit anordnen. Er sorgt dafür, dass die Rollen richtig ausgeführt werden und jeder die ihm obliegende Verantwortung auch wahrnimmt. Er steht dem Team bei Fragen zur Verfügung und hilft den einzelnen Teammitgliedern, zu einem produktiven Team zusammenzuwachsen. 14 10 Vgl. Wirdemann, (2011), S. 38. 11 Vgl. Pichler, (2008), S. 16. 12 Vgl. Wirdemann, (2011), S. 38. 13 Vgl. Wirdemann, (2011), S. 39. 14 Vgl. Pichler, (2008), S. 20. 4

1.4 Product Backlog Bei traditionellen Vorgehensweisen werden Anforderungen zu Beginn des Projektes möglichst vollständig erfasst und beschrieben. Danach werden alle Anforderungen dem Entwicklerteam übergeben. Dieses setzt die Anforderungen nach bestem Verständnis um. Gerade hierbei kann es zu Fehlinterpretationen kommen, es werden Lücken oder Ungenauigkeiten in den Definitionen entdeckt und das Resultat entspricht nicht dem, was der Kunde sich vorgestellt hat. Zudem kann es zu Überproduktion und Fehlleistungen kommen: mit zunehmender Projektdauer werden Anforderungen hinzugefügt oder obsolet, und es kann zudem sein, dass das Endprodukt zu viel Funktionalität ausweist. 15 Scrum geht hier einen anderen Weg, indem zunächst alle Eigenschaften des Produktes durch den Product Owner priorisiert zusammengestellt, aber nicht im Detail beschrieben werden. Alle Details, die zur Umsetzung benötigt werden, werden erst später innerhalb der Sprint-Planung hinzugefügt. 16 Alle Anforderungen werden im Product Backlog festgehalten. Dieses Dokument ist sehr dynamisch, es ändert sich also ständig im Laufe des Projektes, indem Anforderungen hinzugefügt, entfernt oder verfeinert werden. Aktivitäten werden im Product Backlog nicht festgehalten, dies erfolgt im Sprint Backlog. 17 1.4.1 User Stories Eine gute Möglichkeit, Anforderungen zu Erfassen, sind User Stories. Hierbei wird ein Feature aus der Sicht der Person, die sich dieses Feature wünscht, in einem Satz auf eine Karteikarte geschrieben. Eine User Story liefert dabei einen Mehrwert für den Kunden. Die User Story Als Basisanwender möchte ich meine Kontaktdaten ändern liefert diesen Mehrwert, wohingegen die User Story Die Software soll in Java programmiert werden keinen Mehrwert im Sinne des Kunden liefert. 18 Neben der reinen Formulierung der Anforderung besteht eine User Story aus der Kommunikation zwischen Product Owner und Team und Akzeptanzkriterien. Sobald eine User Story umgesetzt werden soll, müssen 15 Vgl. Pichler, (2008), S. 26. 16 Vgl. Schwaber, (2011), S. 79. 17 Vgl. Pichler, (2008), S. 27. 18 Vgl. Wirdemann, (2011), S. 52. 5

Product Owner und Team alle Details ausarbeiten. Durch Akzeptanzkriterien wird festgelegt, wann eine User Story vollständig umgesetzt ist und als erledigt gilt. 19 Da sich User Stories schlecht zur Beschreibung von Oberflächen oder Komponenten eignen, muss der Product Owner meist mit unterschiedlichen Techniken arbeiten, um Anforderungen zu beschreiben, z. B. mit UML-Diagrammen. 20 1.4.2 Priorisierung Ist das Product Backlog mit allen Anforderungen aufgefüllt, müssen diese Priorisiert werden. Dies hat mehrere Gründe. Zum Einen wird dadurch sichergestellt, dass die wichtigsten Anforderungen bereits in einer frühen Phase des Projektes umgesetzt sind, um Product Owner und Endkunden frühzeitig prüfen zu lassen, ob die Anforderungen korrekt verstanden und umgesetzt wurden. Zum Anderen ist somit ersichtlich, welche Einträge des Product Backlog frühzeitig detaillierter beschrieben werden müssen, um die Verzögerung bis zum ersten Sprint zu minimieren. 21 1.4.3 Schätzen Die Bestimmung des Aufwandes aller Anforderungen ist bei der Projektplanung von entscheidender Bedeutung. Zu den Aufgaben des Product Owners gehört die Erstellung eines Releaseplans. Dieser gibt an, wann welche Funktionalität fertiggestellt wird. Um diesen Plan erstellen zu können, muss der Product Owner die Größse und Priorisierung aller Backlog Items und die Entwicklungsgeschwindigkeit, in Scrum Velocity genannt, des Teams kennen. 22 Der Product Owner stellt nacheinander die einzelnen Einträge aus dem Product Backlog vor, die alle durch das Team abgeschätzt werden. Die Schätzung erfolgt in der Regel in Punkten, wobei zunächst ein Product Backlog Item als Referenzgrößse und alle weiteren als relative Größse dazu abgeschätzt werden. 19 Vgl. Wirdemann, (2011), S. 53. 20 Vgl. Pichler, (2008), S. 48. 21 Vgl. Pichler, (2008), S. 38. 22 Vgl. Schwaber, (2011), S. 138. 6

Als Punktereihe eignen sich die Zahlen aus der Fibonacci-Reihe (0, 1, 2, 3, 5, 8, 13), da hier eine gute Auswahl an Aufwandsgrößsen vorliegt und Diskussionen, ob eine Anforderung nun eine 7, 8 oder 9 ist, minimiert werden. 23 Um die Entwicklungsgeschwindigkeit zu bestimmen, hängt es davon ab, an welchem Punkt im Projekt wir stehen. Stehen wir noch vor dem ersten Sprint, so muss das Team entscheiden, wie viele Einträge aus dem Product Backlog es glaubt, im ersten Sprint abarbeiten zu können. Hat das Team bereits einen Sprint abgeschlossen, wissen wir, wie viele Einträge und somit Punkte das Team im Sprint umgesetzt hat. 24 1.4.4 Release Scrum-Projekte sind eine Aneinanderreihung von Sprints. Bei sehr kurzen Projekten reicht es teilweise, von Sprint zu Sprint zu planen. Bei größseren Projekten wird in der Regel aber ein Releaseplan benötigt. Dieser hält fest, welche Anforderungen voraussichtlich in welchem Sprint umgesetzt werden. Hieraus ist dadurch ersichtlich, wie viele Sprints in etwa benötigt werden. Mit einem Releaseplan kann der Product Owner für den Arbeitsanfall optimal verteilen, Fertigstellungstermine und Kosten planen. 25 Nach jedem Sprint wird der tatsächliche Projektfortschritt mit dem im Releaseplan geplanten Fortschritt abgeglichen. Dadurch kann sehr schnell erkannt werden, ob das Projekt schneller oder langsamer vorankommt als geplant. Als visuelle Darstellung kann hier ein Burndown-Diagramm erzeugt werden, das auf der X-Achse die Anzahl an Tagen und auf der Y-Achse die Summe der noch offenen Aufwände. 26 1.5 Sprints Zwei zentrale Vorgänge in Scrum sind Sprints und Daily Scrums. Ein Sprint ist ein kurzer Arbeitszyklus fester Länge, dessen Ergebnis ein potenziell aus- 23 Vgl. Pichler, (2008), S. 59. 24 Vgl. Cohn, (2010), S. 332. 25 Vgl. Pichler, (2008), S. 50-51. 26 Vgl. Pichler, (2008), S.117. 7

Abbildung 2: In Anlehnung an: Pichler, (2008), S. 117 Burndown-Diagramm lieferbares Produktinkrement ist. Die maximale Dauer eines Sprints beträgt 30 Tage. Innerhalb des Sprints organisiert sich das Team selbst, und niemand außserhalb des Teams darf diesem nicht geplante Arbeit aufdrücken. Während des täglichen Standup-Meetings, dem Daily Scrum, synchronisiert sich das Team untereinander und mit dem Product Owner. 27 1.5.1 Planung Zu Beginn eines Sprints wird eine Sprint-Planungssitzung durchgeführt. In dieser Sitzung wird vom Team festgelegt, welche Anforderungen aus dem Product Backlog in dem Sprint umgesetzt werden, und es wird ein entsprechendes Sprint Backlog mit ebendiesen Anforderungen erstellt. Zunächst wird vom Product Owner das Sprint-Ziel sowie eine Vorauswahl an Anforderungen vorgestellt. Für die Festlegung der Anforderungen, die im Sprint umgesetzt werden, gibt es zwei Möglichkeiten: Bei der ersten Möglichkeit kann das Team die Anforderungen auswählen, die es glaubt, im Sprint umsetzen zu können. Danach werden für alle gewählten Anforderungen die benötigten Aktivitäten ermittelt. Bei der zweiten Möglichkeit iteriert das Team durch die Liste der Anforderungen, beginnend mit der am höchsten priorisierten. Für jede Anforderung werden die Aktivitäten ermittelt und abgeschätzt. Sind noch genügend Kapazitäten im Team vorhanden, um alle Aktivitäten umzusetzen, wird diese Anforderung Teil 27 Vgl. Wirdemann, (2011), S. 30. 8

des Sprint Backlogs. 28 Unter Aktivitäten versteht man typischerweise Design-, Implementierungs-, Test- und Dokumentationsaufgaben. 29 Die Moderation übernimmt der ScrumMaster. Product Owner, Team und ScrumMaster sind Pflichtteilnehmer der Sprint-Planungssitzung. Den Teilnehmern steht es offen, weitere Personen an der Sitzung teilhaben zu lassen, jedoch dürfen diese Personen keinerlei Einfluss auf die Planung des Teams nehmen. 30 1.5.2 Sprint Backlog Alle Aktivitäten, die zur Umsetzung der Anforderungen notwendig sind, werden im Sprint Backlog festgehalten. Es ist ein lebendes Dokument, welches täglich aktualisiert wird. Somit bietet es jederzeit einen genauen Überblick über den aktuellen Fortschritt des Sprints. Das Vorhalten des Sprint Backlogs auf einer Stellwand mit Karteikarten hat den Vorteil, dass es für alle Teammitglieder jederzeit sichtbar und ohne Hindernisse zugänglich ist. Hierzu empfiehlt es sich, das Sprint Backlog in folgende Spalten aufzuteilen: Priorisierung, Anforderung, zu erledigen, in Arbeit und erledigt. Die erste Spalte Priorisierung gibt die Wichtigkeit der Anforderung, die in der zweiten Spalte steht, an. In der dritten Spalte zu erledigen werden alle Aktivitäten der Anforderungen festgehalten. Beginnt ein Teammitglied mit der Ausführung einer Aktivität, setzt es diese Aktivität in die Spalte in Arbeit und versieht sie mit seinem Kürzel. Alle erledigten Aktivitäten werden in die letzte Spalte gesetzt. Somit ist zu jeder Zeit ersichtlich, welches Teammitglied mit welcher Aktivität beschäftigt ist und welche Aktivitäten und Anforderungen bereits erledigt sind. Werden während der Umsetzungsphase neue Aktivitäten identifiziert, so werden diese auf Karteikarten geschrieben und in die Spalte zu erledigen gehängt. Die Struktur kann bei Bedarf erweitert werden, z. B. um Spalten wie testbereit oder abnahmebereit. 31 28 Vgl. Pichler, (2008), S. 94. 29 Vgl. Pichler, (2008), S. 95. 30 Vgl. Pichler, (2008), S. 93. 31 Vgl. Pichler, (2008), S. 103. 9

1.5.3 Daily-Scrum Das Daily-Scrum ist eine auf 15 Minuten begrenzte Sitzung, an der alle Teammitglieder und der ScrumMaster verpflichtend teilnehmen und sich untereinander über den Projektfortschritt austauschen und mögliche Hindernisse zu identifizieren. Diese Sitzung findet jeden Tag zur selben Zeit am selben Ort statt. 32 Jedes Teammitglied beantwortet folgende Fragen: Was habe ich seit dem letzten Daily Scrum erledigen können? Was plane ich bis zum nächste Daily Scrum zu erledigen? Wo sehe ich Hindernisse bei meinen Aktivitäten? Während des Meetings sollen keine Probleme gelöst werden, sie sollen lediglich identifiziert werden. Die Lösung erfolgt dann gegebenenfalls in einem anderen Meeting. Neben den genannten Teilnehmern steht das Daily Scrum allen Interessierten offen, allerdings nur als Zuhörer. 33 1.5.4 Sprint-Review Am Ende eines Sprints werden vom Team die Arbeitsergebnisse im Sprint- Review präsentiert. Neben dem Team, dem Product Owner und dem Scrum- Master können weitere Personen wie Endanwender, Kunden oder Personen aus anderen Abteilungen, wie z. B. Marketing oder Vertrieb, teilnehmen und die Ergebnisse begutachten und bewerten. Der Product Owner überprüft die Erreichung der Sprint-Ziele und nimmt die Ergebnisse ab. 34 Die Vorbereitungen auf dieses Meeting sollten für jeden Einzelnen eine Stunde nicht überschreiten. Product Owner, Team und ScrumMaster sprechen sich ab, wer welche Funktionalitäten präsentiert. Es wird ausschließslich die erzeugte Software vorgeführt, sonstige Präsentationen, z. B. als PowerPoint, sind verboten. 35 32 Vgl. Pichler, (2008), S. 104. 33 Vgl. Schwaber, (2011), S. 168. 34 Vgl. Pichler, (2008), S. 107. 35 Vgl. Wirdemann, (2011), S. 31. 10

1.5.5 Sprint-Retrospektive Den Abschluss des Sprints stellt die Sprint-Retrospektive dar, in der das Team den Entwicklungsprozess und die Zusammenarbeit reflektiert und Verbesserungsvorschläge erarbeitet. Das Ziel ist eine stetige Verbesserung des Entwicklungsprozesses und damit der Produktivität des Teams. Die Verbesserungsvorschläge sollten in der nächsten Sprint-Planungssitzung berücksichtigt werden. 36 Um eine kontinuierliche Verbesserung der Zusammenarbeit sicherzustellen, endet jeder Sprint mit einer Retrospektive, auch wenn die Zusammenarbeit des Team bereits sehr gut und das Projekt erfolgreich ist. 37 36 ebd. 37 Vgl. Pichler, (2008), S. 112. 11

Literatur 2 Literatur 1. Cohn, Mike (2010): Agile Softwareentwicklung: Mit Scrum zum Erfolg. Addison-Wesley. isbn: 978-3827329875. 2. Pichler, Roman (2008): Scrum - agiles Projektmanagement erfolgreich einsetzen. dpunkt.verlag. isbn: 978-3898644785. 3. Schwaber, Ken (2011): Scrum: Produkte zuverlässig und schnell entwickeln. Carl Hanser Verlag GmbH & CO. KG. isbn: 978-3446425248. 4. Wirdemann, Ralf (2011): Scrum mit Userstories. Carl Hanser Verlag GmbH & CO. KG. isbn: 978-3446426603. 12