Agile Softwareentwicklung mit

Scrum

Scrum - Agile Softwareentwicklung - � von � - 1 21 Andy Shek & Simon Wüllhorst

Präambel 4 Autoren 4

Überblick 5 Namensgebung 5 Lean-Prinzipien 5 Agile Manifesto 5 Grundprinzipien der Verbesserung 6 3x3-Regel 7

Rollen innerhalb von Scrum 8 Product Owner 8 Scrum Master 8 Entwicklerteam 8 Stakeholder 9

Customer 9 Anwender 9 Management 9

Die Scrum Artefakte 10 Artefakte 10

Product Backlog 10 Sprint Backlog 10 Product Increment 10

Anforderungen 10 Definition of Done 10

Ergänzende Techniken 11 User Stories 11 Taskboard 11 Burndown Chart 12

Scrum Meetings 13 Begriffsklärung Sprint 13 Vor dem Sprint 13

Sprint Planning 1 14 Sprint Planning 2 14

Während des Sprints 14 Daily Scrum 14

Nach dem Sprint 15 Sprint Review 15

Scrum - Agile Softwareentwicklung - � von � - 2 21 Andy Shek & Simon Wüllhorst

Retrospektive 15 Product Backlog Refinement 16

Scrumbuts 17 Vor- & Nachteile 18

Vorteile 18 Nachteile 18

Fazit 19 Quellen 20

Textquellen 20 Wikipedia 20 Slides 20 Diverse 20

Bilder 21

Scrum - Agile Softwareentwicklung - � von � - 3 21 Andy Shek & Simon Wüllhorst

PräambelDieser Aufsatz behandelt das Thema der agilen Softwareentwicklung mit Scrum. Es wurde von Andy Shek und Simon Wüllhorst im Rahmen des Moduls Softskills des Studiengangs Informatik an der Fachhochschule Münster verfasst.

Vorangegangen ist dieser Ausarbeitung ein Vortrag über das hier behandelte Thema. Der Fokus dieser Ausarbeitung liegt, wie schon im Vortrag, auf der Struktur und der Funktionsweise von Scrum.

Bei den in diesem Text enthaltenen englischsprachigen Fachbegriffen handelt es sich zumeist um generische Begriffe. Nach sorgfältiger Überlegung wurden sie daher nicht übersetzt. Dieses vereinfacht die Rezeption weiterführender Literatur. Dennoch wurde großer Wert darauf gelegt, sämtliche Fachbegriffe innerhalb dieses Textes zu erklären. Dabei erfolgt dieses jedoch nicht immer bei ihrer erstmaligen Erwähnung. Um diese Tatsache zu verdeutlichen, werden diese Fachbegriffe im Folgenden kursiv dargestellt.

AutorenAndy ShekStudent der Informatik (FH Münster)andy.shek@fh-muenster.deMatrikelnummer: 830135

Simon WüllhorstStudent der Informatik (FH Münster)s.wuellhorst@fh-muenster.deMatrikelnummer: 817199

Scrum - Agile Softwareentwicklung - � von � - 4 21 Andy Shek & Simon Wüllhorst

ÜberblickBei Scrum handelt es sich um ein Projektmanagement Ansatz, welcher die dynamische Entwicklung während der Realisierung eines Softwareprojekts berücksichtigt. Dabei ist Scrum nicht auf Softwareprojekte beschränkt, es wurde bereits in vielen anderen Bereichen adaptiert.

Im Gegensatz zum klassischen Projektmanagement, dem sogenannten Wasserfallmodell, werden bei Scrum nicht bereits im Vorfeld detaillierte Anforderungen und Arbeitsanweisungen definiert. Vielmehr wird die detaillierte Ausgestaltung dieser Anforderungen bei Scrum als kontinuierlicher Prozess verstanden.

Damit trotz anfänglich nur sehr grob formulierter Zielvorgaben die Projektentwicklung nicht planlos erfolgt, gibt es bei Scrum eine Reihe wiederkehrender Rituale, die die kontinuierliche Weiterentwicklung der Projektziele sicherstellen.

Des weiteren wird bei Scrum die Entwicklung im Team forciert, weitere Rituale fördern daher den Erkenntnis- und Erfahrungsaustausch und dienen der Konfliktbewältigung.

Namensgebung

Scrum bedeutet übersetzt Gedränge und kommt aus dem Englischen. Es wird beim Rugby verwendet, um das Vorgehen des Teams zu beschreiben.

Es wird als Analogie verwendet, um ein selbstorganisiertes Team zu beschrieben, welches mit viel Kraft und in einheitlicher Linie auf die Herausforderungen zugeht. So kann es auch die höchsten Ansprüche und Herausforderungen stemmen.

Lean-Prinzipien

Die Lean-Prinzipien stellen die Grundsätze für agile Software Entwicklung dar. Folglich baut auch Scrum auf ihnen auf.

Die Lean-Prinzipien, auch bekannt als Lean-Production entstanden in der japanischen Automobilindustrie, sind jedoch mittlerweile weltweit adaptiert worden. Ziel ist es, Verschwendung möglichst zu eliminieren oder zumindest zu verringern. Dabei wird zwischen den drei folgenden Arten der Verschwendung unterschieden:

• Muda - Arbeit, die keinen Wert für das Produkt hat• Muri - Überlastung von Maschinen und Mitarbeitern• Mura - Unregelmäßiger Ablauf von Prozessen

Agile Manifesto

Das Agile Manifesto wurde im Jahr 2001 von einigen bekannten Programmierern verfasst und beinhaltet zwölf Prinzipien, denen agile Entwicklungskonzepte folgen sollten. Somit sind diese Prinzipien auch ein Grundstein für Scrum.

Die folgenden Prinzipien sind im originalen Wortlaut dem agilen Manifest entnommen:Scrum - Agile Softwareentwicklung - � von � - 5 21 Andy Shek & Simon Wüllhorst

•Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

•Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

•Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.

•Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.•Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die

Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.•Die effizienteste und effektivste Methode, Informationen an und innerhalb eines

Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.•Funktionierende Software ist das wichtigste Fortschrittsmaß.•Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und

Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.•Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.•Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell.•Die besten Architekturen, Anforderungen und Entwürfe entstehen durch

selbstorganisierte Teams.•In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und

passt sein Verhalten entsprechend an. Quelle: http://www.agilemanifesto.org/iso/de/principles.html

Aus diesen zwölf Prinzipien lassen sich vereinfacht die folgenden vier Grundwerte agiler Softwareentwicklung ableiten:

•Individuen und Interaktionen mehr als Prozesse und Werkzeuge.•Funktionierende Software mehr als umfassende Dokumentation.•Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung.•Reagieren auf Veränderung mehr als das Befolgen eines Plans.Quelle: http://www.agilemanifesto.org/iso/de/

Die aufgeführten Prinzipien und Grundwerte lassen erkennen, dass die agile Softwareentwicklung vor allem versucht ein Problem klassischer Entwicklung zu eliminieren. In der klassischen Entwicklung findet die Softwareentwicklung häufig isoliert statt und Programmierer sind größtenteils auf sich selbst gestellt. Der agile Ansatz hingegen forciert Entwicklung und Erkenntnisaustausch im Team.

Grundprinzipien der Verbesserung

Damit eine agile Entwicklung im Team nennenswerte Vorteile gegenüber der klassischen Entwicklung erreicht, sollten dabei folgende Grundprinzipien berücksichtigt werden:

• TransparenzDer Fortschritt und Probleme werden kontinuierlich festgehalten.

• ÜberprüfungIn festen Abständen werden Teilprodukte (Increments) geliefert und validiert.

Scrum - Agile Softwareentwicklung - � von � - 6 21 Andy Shek & Simon Wüllhorst

• AnpassungDie Anforderungen an das Projekt werden kontinuierlich verfeinert und angepasst.

Nur die konsequente Befolgung dieser Grundprinzipien ermöglicht einen Erfolg agiler Entwicklungsmethoden.

3x3-Regel

Mit der 3x3-Regel lassen sich die Bestandteile von Scrum stark vereinfacht, aber dafür sehr kompakt darstellen:

• Drei Zeremonien• Daily Scrum - Tägliche Besprechung des Fortschritts• Sprint Planning - Planung einer Integration/eines Arbeitszyklusses• Sprint Review - Nachbesprechung eines Arbeitszyklusses

• Drei Artefakte• Product Backlog - Die priorisierte Sammlung aller Produktanforderungen• Sprint Backlog - Anforderungen, die während eines Sprints erledigt werden sollen• Increment - Ein in sich geschlossenes und lauffähiges Teilstück des Produkts

• Drei Rollen• Product Owner - Verantwortlich für wirtschaftliche Aspekte und Endprodukt• Scrum Master - Überwacht den Arbeitsprozess und steht dem Team zur Seite• Team - Ein selbstorganisierendes Entwicklungsteam, (teil-)autonom

Es handelt sich hierbei um eine grobe Beschreibung. In der Praxis definiert man häufig weitere Zeremonien, Artefakte und Rollen. Diese lassen sich jedoch zu den oben Aufgeführten zuordnen.

Anmerkung: Bei einem Sprint handelt es sich um das zentrale Element von Scrum und beschreibt einen iterativen Arbeitsschritt. (Siehe Begriffsklärung Sprint)

Visualisierung des iterativen ScrumprozessesQuelle: https://commons.wikimedia.org/wiki/File:Scrum_process-de.svgAutor: Sebastian Wallroth (CC-BY-SA)

Scrum - Agile Softwareentwicklung - � von � - 7 21 Andy Shek & Simon Wüllhorst

Rollen innerhalb von ScrumGenerell gibt es bei Scrum nur wenige Rollen und Vorgaben. Damit jedoch keine Unordnung entsteht, ist es wichtig, dass diese auch entsprechend eingehalten werden. Die drei Schlüsselrollen in Scrum sind:

• Product Owner• Scrum Master• Entwicklerteam

Product Owner

Der Product Owner ist für den Gesamterfolg des Projektes verantwortlich. Er dirigiert die Produktentwicklung und repräsentiert den Kunden mit seinen Anforderungen.

Außerdem trägt er die Verantwortung dafür, dass die richtigen Anforderungen im Product Backlog stehen und dass sie in einer sinnvollen Reihenfolge abgearbeitet werden.

Häufig erhält der Product Owner nicht die Vollmacht, um die notwendigen Entscheidungen verbindlich zu treffen - abweichend von der Rollenkompetenz, die eigentlich in Scrum vorgesehen ist. Der Product Owner wird auch oft mit fremden Aufgaben überlastet.

Scrum Master

Die Aufgaben des Scrum Master sind vielseitig. Agile Prozesse zeichnen sich durch eine hohe Dynamik aus. Damit der Prozess zielgerichtet verläuft und aus Dynamik nicht Chaos wird, existiert ein Scrum Master. Er ist sozusagen „die Seele des Prozesses“ und sorgt dafür, dass die Scrum Regeln eingehalten werden.

Eine Aufgabe des Scrum Masters ist die Vermittlung zwischen Product Owner und Entwicklungsteam und er muss dafür sorgen, dass Scrum gelingt und eingehalten wird. Dazu arbeitet er mit dem Entwicklungsteam zusammen.

Entwicklerteam

Das Entwicklerteam ist für die Implementierung von Funktionalitäten, die im Product Backlog stehen, zuständig. Das Team bildet sich aus Mitgliedern, die zur Erreichung und Fertigstellung des Projektes notwendig sind. Die Größe eines Teams besteht in der Regel aus drei bis neun Akteuren, kann aber je nach Größe und Aufwand variieren.

Aufgaben eines Entwicklerteams sind die Schätzung des Umfangs der Einträge im Product Backlog und wie oben schon genannt, auch deren Umsetzung. Das Team bricht in der Sprint Planung, die für einen Sprint ausgewählten Einträge aus dem Product Backlog in Tasks, deren Bearbeitung in der Regel nicht länger als einen Tag dauert, herunter. Das Ergebnis ist das Sprint Backlog.

Scrum - Agile Softwareentwicklung - � von � - 8 21 Andy Shek & Simon Wüllhorst

Stakeholder

Die Stakeholder (engl. für Teilhaber) werden als eine Person oder Gruppe bezeichnet, die ein berechtigtes Interesse am Verlauf bzw. Ergebnis eines Projektes hat. Häufig werden Stakeholder in drei verschiedene Gruppen unterteilt: Customer, Anwender oder Management.

Customer

Nach der Fertigstellung des Produkts wird es dem oder den Kunden zur Verfügung gestellt. Es ist die Aufgabe des Product Owner den Customer bei der Lieferung des Wunschprodukt zu begeistern. Deshalb sollte der Product Owner und der Customer immer im engen Kontakt zueinander stehen. Customer sollten nach den ersten Sprints die Gelegenheit haben, sich die jeweiligen Funktionalitäten anzuschauen und ihr Feedback dazu zu geben.

Anwender

Die Anwender haben aus der Sicht des Scrum-Team eine große Bedeutung, denn nur sie können das finale Produkt aus der Nutzerperspektive beurteilen. Anwender und Customer sollten beim Sprint Review und beim Product Backlog Refinement beteiligt sein, um das Produkt zu testen und ihr Feedback zu geben.

Management

Das Management ist dafür Verantwortlich, dass die Rahmenbedingungen stimmen. Die Bereitstellung von Räumen und Arbeitsmitteln gehört dazu.

Scrum - Agile Softwareentwicklung - � von � - 9 21 Andy Shek & Simon Wüllhorst

Die Scrum ArtefakteArtefakte

Product Backlog

Das Product Backlog ist eine priorisierte und rein nutzerorientierte Liste mit Anforderungen, die der Product Owner zum Projekterfolg festgelegt hat. Es werden auf grober Ebene Merkmale und Eigenschaften notiert. Die Liste beinhaltet eine Dokumentation der Aufwandsschätzung. Für die Aktualisierung der Einträge in der Liste ist der Product Owner verantwortlich.

Die gesamte Anzahl der Anforderungen, die im Product Backlog stehen, bilden die Grundlage für den nächsten Sprint, die vom Product Owner gewählt und zusammengestellt werden.

Bei sehr großen Projekten wird der Product Owner vom Entwicklungsteam unterstützt.

Sprint Backlog

Das Sprint Backlog wird im Gegensatz zum Product Backlog jeden Tag aktualisiert. Es werden von jedem Mitglied des Entwicklungsteam aufgezeichnet, an welcher und wie weit der Akteur bereits mit der zugeteilten Aufgabe ist.

Ein Sprint Backlog kann viele unterschiedliche Formen haben, häufig wird dafür aber ein sogernanntes Taskboard verwendet.

Product Increment

Product-Backlog-Einträge als Summe werden als das Increment bezeichnet, die während des aktuellen und vorangegangenen Sprints festgelegt wurden. Beim Ende eines Sprints muss das neue Increment in einem nutzbaren Zustand sein und der Definition of Done entsprechen.

Anforderungen

Definition of Done

Die Definition of Done (DoD) gilt als gemeinsames Verständnis des Scrum-Teams, unter welchen Bedingungen eine Arbeit als fertig gekennzeichnet werden kann. Gewöhnlich enthält die Definition of Done Qualitätskriterien, Einschränkungen und allgemeine nicht-funktionale Anforderungen.

Die DoD wird am Anfang eines Projektes von allen Mitgliedern des Scrum-Teams festgelegt und kontinuierlich erweitert. Am Ende eines Sprints dient die DoD der Überprüfung, ob jeder Product Backlog Eintrag den Akzeptanzkriterien entspricht und entscheidet, ob ein Product Backlog Eintrag als fertig gekennzeichnet wird.

Scrum - Agile Softwareentwicklung - � von � - 10 21 Andy Shek & Simon Wüllhorst

Ergänzende Techniken

Häufig werden diese Techniken in Verbindung mit Scrum gebracht, gehören jedoch nicht zum Kern von Scrum und können durch andere Techniken ersetzt werden.

User Stories

User Stories sind Items aus dem Product Backlog. Eine Story lässt sich relativ einfach definieren. Sie beschreibt anhand einer Geschichte ein ganz bestimmtes Bedürfnis eines Anwenders. Das Gesamte User Story wird in einer sehr einfachen Sprache verfasst. Idealerweise in einer Ausdrucksweise ganz ohne Fachbegriffe, sodass die Stackholder die User Stories ohne Probleme verstehen können. Üblicherweise besteht eine Story aus einer aussagekräftigen Überschrift, ist kurz gehalten und zielorientiert.

User Story Kriterien nach dem INVEST Prinzip:• Independent (I)

Sie ist nicht von einer anderen User Story abhängig.• Negotiable (N)

Sie dient als Gesprächsgrundlage und kann gemeinsam weiterentwickelt werden.• Valuable (V)

Sie stellt immer einen Vorteil für den User, Kunden oder Auftraggeber dar.• Estimable (E)

Sie ist schätzbar. Sie hat also soviel konkrete Details, dass ein erfahrenes Team deren Umfang schätzen kann.

• Small (S) Sie hat die richtige Größe.

• Testable (T) Sie kann getestet werden.

User Stories folgen im Allgemeinen diesem Muster:•Als Nutzer will ich Funktion oder Eigenschaft, damit nutzen.

Beispiel:•„Als User möchte ich einen geschützten Bereich, um betriebsinterne Dokumente zu

sichern.“

Taskboard

Zur Visualisierung eines Sprint Backlogs werden häufig sogenannte Taskboards genutzt.

Auf so einem Taskboard lässt sich leicht ablesen, wie der Fortschritt der Bearbeitung der Product Backlog Einträge ist.

Ein Taskboard besteht in der Regel aus vier Spalten. In der ersten Spalte stehen die Einträge aus dem Product Backlog, die das Entwicklungsteam für diesen Sprint ausgewählt hat – in der vom Product Owner priorisierten Reihenfolge. Die drei weiteren Spalten zeigen an, in welchem Zustand die einzelnen Einträge sind. Man unterscheidet typischerweise zwischen ToDo, der Spalte mit dem noch zu erledigen Aufgaben, dem In Progress, die

Scrum - Agile Softwareentwicklung - � von � - 11 21 Andy Shek & Simon Wüllhorst

Aufgaben, die gerade in Bearbeitung sind und zum Schluss dem Done, der Spalte mit den Aufgaben, die erledigt sind.

Burndown Chart

Ein Burndown Chart zeigt wie weit ein Sprint bereits fortgeschritten ist und ob die geplanten Ziele erfüllt worden sind.

Exemplarische Visualisierung eines Burndown ChartQuelle: https://en.wikipedia.org/wiki/File:SampleBurndownChart.png, Autor: Pablo Straub (Public Domain)

Diese Grafik kann für unterschiedliche Visualisierungen genutzt werden und soll dazu dienen, die Erreichung des Sprint-Ziels besser abschätzen zu können. Folgende Charts können unterschieden werden:

• Sprint Burndown Chart• Product Burndown Chart• Release Burndown Chart

Scrum - Agile Softwareentwicklung - � von � - 12 21 Andy Shek & Simon Wüllhorst

Scrum MeetingsEine der wichtigsten Ziele von Scrum ist die Forcierung der face-to-face Kommunikation innerhalb eines Projekts. Diese erweist sich meist als effizienter und zielführender als die Kommunikation über andere Kanäle.

Um zielführende und effiziente Kommunikation zu gewährleisten, gibt es in Scrum verschiedene wiederkehrende Meetings. Diese sollten stets eingehalten und so durchgeführt werden, wie sie von Scrum vorgesehen sind. Eine Modifikation dieser Meeting-Struktur sollte nur nach sorgfältiger Abwägung und ausreichender Erfahrung mit Scrum Projekten in Erwägung gezogen werden, da es sonst sehr schnell zu ScrumButs führen kann.

Begriffsklärung Sprint

Unter einem Sprint versteht man eine wiederkehrende (iterative) Einheit, in der ein Teil des Projekts auslieferungsfertig realisiert werden soll. Typischerweise dauert ein Sprint zwischen eine und maximal vier Wochen.

Das Ergebnis eines Sprints wird als Product Increment bezeichnet und erwartet einen lauffähigen Teil der Software. Dennoch kann die Dauer eines Sprints nicht verlängert werden, daher ist es wichtig, die einzelnen Sprintziele nach Priorität zu sortieren.

Projektteile, die innerhalb eines Sprints realisiert und getestet werden sollen, werden innerhalb des entsprechenden Meetings bestimmt.

Das Team, welches den Sprint durchführen sollte, in der Zeit des Sprints fokussiert an den Sprint Aufgaben arbeiten können und von störenden Einflüsse von außen oder weitere Aufgaben ferngehalten werden.

Hat der Sprint begonnen, sind keine Änderungen an den Sprint Zielen mehr zulässig. Änderungswünsche können erst in der nächsten Iteration bzw. im nächsten Sprint berücksichtigt werden. Das soll ebenfalls dazu beitragen, dass sich das Team voll und ganz auf das Product Increment konzentrieren kann.

Außerdem arbeitet das Team autark und trifft Entscheidungen eigenständig. Das heißt, weder der Product Owner noch der Scrum Master schreibt dem Team vor, wie Aufgaben zu erledigen sind.

Vor dem Sprint

Vor Beginn eines Sprints finden zwei Meetings statt, um die Ziele des Sprints zu definieren und die erforderlichen Aufgaben in Teilaufgaben zu gliedern. Diese beiden Meetings sollten zusammen maximal 2 Stunden je Sprint-Woche in Anspruch nehmen. Bei zweiwöchigen Sprints sind das beispielsweise 4 Stunden.

Scrum - Agile Softwareentwicklung - � von � - 13 21 Andy Shek & Simon Wüllhorst

Sprint Planning 1

Zusammengefasst soll im Sprint Planning 1 die Frage „Was kann im kommenden Sprint entwickelt werden?“ geklärt werden. Der Product Owner stellt Produkteigenschaften aus dem Product Backlog vor, die im kommenden Sprint realisiert werden sollen. Die Strukturierung und Einteilung des Backlogs müssen vorher im Product Backlog Refinement erfolgt sein.

Hierbei geht es primär darum, dem Entwicklungsteam zu vermitteln, was umgesetzt werden soll. Es sollen Missverständnisse und Unklarheiten beseitigt werden. Hierzu kann es auch vorteilhaft sein, wenn ein User dem Meeting beiwohnt, um so auf etwaige Fragen der Entwickler detailliert einzugehen.

Abschließend wird vom Entwicklungsteam prognostiziert, wie viele der Vorgestellten Produkteigenschaften im kommenden Sprint realisiert werden können und es wird eine Zielvorgabe (Definition of Done) vereinbart. Diese Zielvorgabe definiert, wann ein Product Backlog Eintrag als erledigt gilt bzw. der Sprint erfolgreich ist.

Sprint Planning 2

Zusammengefasst soll im Sprint Planning 2 die Frage „Wie werden die Ziele im folgenden Sprint umgesetzt?“ geklärt werden. Dabei geht es um eine detaillierte Planung der Ziele. Dazu werden diese in kleine Aufgaben (Tasks) unterteilt, die während des Sprints sequenziell von den einzelnen Teammitgliedern abgearbeitet werden sollen. Ein Task sollte nicht länger als einen Tag in Anspruch nehmen.

Das Ergebnis des Sprint Planning 2 wird im Sprint Backlog festgehalten. Außerdem empfiehlt es sich die Tasks auf einem Taskboard zu visualisieren.

Während des Sprints

Daily Scrum

Das Daily Scrum findet zu Beginn jedes Arbeits- / Projekttags statt. Es sollte nicht länger als 15 Minuten andauern und wird daher häufig auch im Stehen direkt im Eintwicklerraum abgehalten.

Während des Daily Scrums sollte jedes Teammitglied drei Fragen beantworten:• Was hast du gestern/seit dem letzten Meeting getan?

• Hast du erreicht, was du dir vorgenommen hast?• Was wirst du heute/bis zum nächsten Meeting tun?• Gibt es störende Einflüsse?

• Was hat dich bei deiner Aufgabe blockiert?• Gibt es störende Einflüsse von außen?

Die maximale Dauer von 15 Minuten sollte strikt eingehalten werden. Daraus folgt, dass während des Daily Scrums eher festgestellt werden soll, ob es Probleme gibt und ob der

Scrum - Agile Softwareentwicklung - � von � - 14 21 Andy Shek & Simon Wüllhorst

Zeitplan eingehalten werden kann, anstatt detailliert auf die einzelnen Probleme einzugehen.

Gibt es Probleme, die einer Klärung bedürfen, kann dieses nach dem Daily Scrum gesondert mit den Betroffenen geklärt werden.

Falls während des Daily Scrums auffällt, das ein Task nicht innerhalb eines Tages realisiert werden konnte, muss geprüft werden, wie dieser in mehrere kleinere Tasks aufgeteilt werden kann. Diese Anpassung sollte anschließend vom Scrum Master im Sprint Backlog festgehalten werden.

Nach dem Sprint

Sprint Review

Im Sprint Review wird der Erfolg des Sprints im Bezug auf das Produkt Increment besprochen. Dazu stellt das Entwicklungsteam dem Product Owner und den im Sprint Planning 1 involvierten Usern die Tasks bzw. realisierten Lösungen zu den im Sprint Planning erstellten Anforderungen vor.

Der Product Owner entscheidet anhand von den zuvor definierten Kriterien, ob das Sprint Ziel erreicht wurde.

Es kann passieren, dass das Sprint Ziel zwar mit allen zuvor definierten Kriterien erreicht wurde, doch der User dennoch mit dem Ergebnis unzufrieden ist bzw. das Ergebnis als unbrauchbar erachtet. Daher ist die Beteiligung der User im Sprint Review von großem Nutzen, um im Diskurs die Gründe für die Unzufriedenheit zu erörtern und in die weiteren Sprints einfließen zu lassen.

Wenn das Sprint Ziel nicht zu 100% erreicht wurde, ist es ein wichtiger Indiz, um spätere Sprints in Punkto Zielvorgabe verbessern zu können.

Die Ergebnisse des Sprint Reviews fließen in das nächste Product Backlog Refinement ein, um das Product Backlog kontinuierlich zu verbessern.

Der Sprint Review sollte nicht mehr als eine Stunde je Sprint Woche in Anspruch nehmen.

Retrospektive

Die Retrospektive fokussiert nicht das Projekt wie im Sprint Review, sondern die Arbeitsweise innerhalb des Sprints bzw. Projektteams.

Es soll reflektiert werden, was während des Sprints gut funktioniert hat und wo Probleme aufgetreten sind. Zu Problemen gehören störende Einflüsse von außen, kommunikative und organisatorische Probleme, sowie ausbleibender Lernerfolg.

Es sollen auch persönliche Empfindungen und Probleme angesprochen werden, daher sollte die Retrospektive in einem geschlossenen Raum ausschließlich mit Scrum Master und Entwicklungsteam stattfinden.

Scrum - Agile Softwareentwicklung - � von � - 15 21 Andy Shek & Simon Wüllhorst

Ziel ist es Verbesserungsmaßnahmen zu definieren, die im Impediment Backlog festgehalten werden und bei den folgenden Sprint Interaktionen angewandt werden können.

Die Retrospektive sollte nicht mehr als 45 Minuten je Sprint Woche in Anspruch nehmen.

Product Backlog Refinement

Das Product Backlog Refinement ist ein kontinuierlicher Prozess, um das Product Backlog anzupassen und zu verbessern.

Es verarbeitet die Ergebnisse des Sprint Reviews. Zusätzlich können auch hier von Stakeholdern (z. B. Anwender) hilfreiche Informationen geliefert werden, um frühzeitig Fehlentwicklungen zu erkennen.

Daher sind an den meisten Product Backlog Refinement Sitzungen neben dem Entwicklungsteam und dem Product Owner auch Stakeholder beteiligt.

Ziele des Product Backlog Refinements sind unter anderem:• Priorisieren der Einträge.• Entfernen von Einträgen, die obsolet geworden sind.• Hinzufügen von neuen Einträgen (z. B. aufgrund der Sprint Review Ergebnisse)• Detaillieren von Einträgen• Zeitliche Beurteilung/Schätzung der Einträge• Planung von Releases

Entwickler sollten nicht mehr als 10% ihrer Zeit in das Product Backlog Refinement investieren.

Scrum - Agile Softwareentwicklung - � von � - 16 21 Andy Shek & Simon Wüllhorst

ScrumbutsAls Scrumbuts bezeichnet man Einflüsse, die negative Folgen auf den Scrum Prozess haben. Dabei kann der Ursprung dieser störenden Einflüsse sowohl intern im Scrum Team sein, als auch von externer Quelle. Scrumbuts werden häufig durch Veränderungen der vorgegebenen Scrum-Struktur hervorgerufen, weil die Bedeutung einzelner Scrum-Elemente noch nicht verstanden wurde und als überflüssig wahrgenommen werden.

Im Folgenden werden exemplarisch Scrumbuts aufgeführt, die gerade in der Anfangszeit häufig auftreten:

• Auf den Scrum Master wird verzichtet, weil das Team zu klein ist.• Die Schätzung des Zeitaufwands einzelner Aufgaben wird vernachlässigt, da es zu

zeitaufwändig ist.• Die Sprints werden verlängert, bis das Sprintziel erreicht wurde.• Retrospektiven werden nicht durchgeführt, da es vermeintlich überflüssig und zu

zeitaufwändig ist.

Diese und weitere Scrumbuts zeigen, dass das Konzept von Scrum noch nicht verstanden wurde und folglich der Erfolg des Scrumprojekts nicht sichergestellt werden kann.

Scrum - Agile Softwareentwicklung - � von � - 17 21 Andy Shek & Simon Wüllhorst

Vor- & NachteileVorteile

• Hohe KommunikationIn Scrum legt man viel Wert auf Kommunikation, somit bietet Scrum auch Verbesserungspotentiale innerhalb des Teams.

• Hohe Flexibilität Änderungen und Planung von Projekten können in Scrum jederzeit durchführt werden.

• Hohe Transparenz Transparenz ist bei Scrum groß geschrieben. Es liefert überschaubare Arbeitsabschnitte und klare Abläufe. Die Beteiligten von Scrum haben jederzeit ein Überblick des aktuellen Fortschritt.

Nachteile

• Keine ErfolgsgarantieEgal was für ein Vorgehensmodell man nutzt, so bietet Scrum auch keine Erfolgsgarantie für des Gesamtprojekt.

• Erhöhte Kommunikation Aufgrund der erhöhten Kommunikation innerhalb des Teams, ist mehr Arbeitsaufwand erforderlich und damit sind höhere Kosten verbunden.

• Entfall von HierarchienDie Hierarchien im Scrum-Team entfallen. Mitglieder, die nicht bereit sind, ihre bisherige Position innerhalb des Entwicklungsteams aufzugeben, können daher Konflikte erzeugen.

• Genaue Kostenkalkulation Im Vorfeld ist keine genaue Kostenkalkulation möglich, da viele Faktoren eine Rolle spielen. Folglich kann dem Kunden kein genauer Kostenvoranschlag vorgelegt werden.

Scrum - Agile Softwareentwicklung - � von � - 18 21 Andy Shek & Simon Wüllhorst

FazitResümierend ist die Softwareentwicklung mit Scrum sehr vielversprechend. Vielen Problemen im klassischen Management begegnet Scrum mit seiner dynamischen und dennoch wohl organisierten Struktur.

Auch größere Projekte lassen sich mit Scrum realisieren, indem man das sogenannte „Scrum-of-Scrums“ verwendet. Hierbei werden mehrere Teams gebildet, die jeweils für einen Teilaspekt der Software verantwortlich sind und je in einem eigenen Scrum abgebildet werden. Diese Scrums werden dann durch ein weiteres, übergeordnetes (Meta-)Scrum Team koordiniert. Durch diese hierarchische Verkettung von Scrum Teams, lassen sich auch ganze Firmen, samt Verwaltung und Buchhaltung, in Scrum organisieren.

Entwicklungsprojekte, die über einen langen Zeitraum immer nur sporadisch weiterentwickelt werden, eignen sich hingegen nicht für die Organisation in Scrum, da die Strukturen von Scrum auf eine Vollzeitentwicklung ausgelegt sind.

Ein weiteres Problem kann die Akzeptanz von Scrum bei den Mitarbeitern darstellen. Abgesehen von Mitarbeitern, die an ihrer erworbenen Position festhalten wollen und mit der flachen Hierarchie von Scrum nicht einverstanden sind, fordert Scrum von jedem Teammitglied hohe interdisziplinäre Fähigkeiten. Diesem Problem kann mit der Schaffung eines Scrum Teams außerhalb der sonstigen Unternehmensstrukturen entgegen, welches nur aus ausgewählten und motivierten Mitarbeitern besteht. Dieses vorgehen eignet sich jedoch zumeist nur für neue Projekte bzw. Projektfelder.

Einer der größten Vorteile von Scrum ist die Möglichkeit ein Projekt stets an neue Erkenntnisse anzupassen oder auch aufgrund dieser vorzeitig beenden zu können. Bei Problemstellungen, die mit heuten Rechensystemen nicht oder nur in ungewünschter Weise lösbar sind, wird auf diese Weise der investierte Arbeitsaufwand möglichst gering gehalten.

Frei nach dem Motto „Erfolg heißt nicht seltener zu scheitern, sondern eher zu erkennen, dass man scheitert“, halten wir die Softwareentwicklung mit Scrum daher für erstrebenswert.

Scrum - Agile Softwareentwicklung - � von � - 19 21 Andy Shek & Simon Wüllhorst

QuellenTextquellen

Wikipedia

• Scrum (deutsche Wikipedia) http://de.wikipedia.org/wiki/Scrum• Scrum (software development, englische Wikipedia) http://en.wikipedia.org/wiki/

Scrum_%28software_development%29• ISO13407 http://de.wikipedia.org/wiki/ISO_13407• Taskboard/Kanban-Tafel, http://de.wikipedia.org/wiki/Kanban-Tafel

Slides

• Scrum Einleitung Präsentation, http://de.slideshare.net/6footplus/scrum-prsentation• Agiles Projektmanagement mit Scrum - Einführung, http://de.slideshare.net/

atillawohllebe/scrum-vorstellung-43730874• Scrum vs Wasserfall - Ein Vergleich und Erfahrungen aus der Praxis, http://

de.slideshare.net/axxessio/scrum-vs-wasserfall• Anleitung zum Ruinieren eines Scrum Teams, http://de.slideshare.net/

udowiegaertner/anleitung-zum-ruinieren-eines-scrum-teams• Scrum-Einführung bei mobile.de, http://de.slideshare.net/mandrezak/

scrumeinfhrung-bei-mobilede• Traditionelles Projektmanagement und SCRUM http://de.slideshare.net/

agilenearshoring/20110928traditionelles-pmscrum-final• Scrum & Kanban im Agenturgeschäft, http://de.slideshare.net/pherwarth/scrum-

kanban-im-agenturgeschft

Diverse

• Video2Brain, Agile Softwareentwicklung mit Scrum, Udo Wiegärtner, https://www.video2brain.com/de/videotraining/agile-softwareentwicklung-mit-scrum

• Agile Manifesto (12 Punkte), http://agilemanifesto.org/• Scrum Alliance Code of Ethics, https://www.scrumalliance.org/code-of-ethics• Einstiegszertifizierung https://www.scrum.org/• Kanban vs. Scrum: How to Make the Most of Both, http://www.infoq.com/resource/

minibooks/kanban-scrum-minibook/en/pdf/KanbanAndScrumInfoQVersionFINAL.pdf and http://www.infoq.com/minibooks/kanban-scrum-minibook

• Scrum Papers, http://jeffsutherland.com/ScrumPapers.pdf• Alles, was Sie über agile Projektentwicklung mit Scrum wissen sollten; Techdivision,

https://www.techdivision.com/_Resources/Persistent/624e1be2c28a73dea5fdac16a66088de6933fc07/2012-02-Whitepaper-Scrum.pdf

Scrum - Agile Softwareentwicklung - � von � - 20 21 Andy Shek & Simon Wüllhorst

• Agiles Projectmanagement; Techdivision, https://www.techdivision.com/_Resources/Persistent/355a9fe9b55a78968620237a90fbd347c54e479d/Agiles-Projektmanagement.pdf

• Agiles Projektmanagement: Scrum, Kanban und Scrumbuts im Einsatz; t3n, http://t3n.de/magazin/praxisbericht-scrum-kanban-scrumbuts-agiles-232822/ (gleiches Bild)

• Scrum im Schnelldurchlauf V2.0 https://www.youtube.com/watch?v=0Nuj-GgEW6o (4:30 min)

• Scrum, https://www.youtube.com/watch?v=OOdAwUXmL3E (17:25 min)• IT Agile, http://www.it-agile.de/• Scrum Essentials: Die sieben Fragen der User Story, https://blog.borisgloger.com/

2011/06/20/scrum-essentials-die-sieben-fragen-der-user-story/

Bilder• Burn Down Chart, https://en.wikipedia.org/wiki/Burn_down_chart#/media/

File:SampleBurndownChart.png• Scrum Process, https://commons.wikimedia.org/wiki/File:Scrum_process-de.svg

Scrum - Agile Softwareentwicklung - � von � - 21 21 Andy Shek & Simon Wüllhorst