Ziel dieser Arbeit ist, die Entwicklung einer Software mit Hilfe der agilen Methode Scrum zu demonstrieren. Da es sich in dieser Arbeit um ein theoretisches Model handelt, wird am Ende keine fertige Software präsentiert, sondern es wird die Durchführung eines Sprints aus der Sicht des Scrum-Teams erläutert.
Agile Methoden im Projektmanagement werden immer beliebter und werden fast von jedem Unternehmen implementiert, denn mithilfe dieser werden hochwertige Produkte ressourcenschonend und in kürzerer Zeit auslieferungsfähig. Agil zu arbeiten, bedeutet auf Situationen zu reagieren, die sich während des Projekts immer wieder ändern oder anpassen müssen. Heutzutage gestaltet sich die Ausführung von Projekten viel komplexer, da viele Komponente berücksichtigt werden müssen. Dies hat zur Folge, dass es innerhalb des Projektes sehr schnell unübersichtlich werden kann. Aus diesem Grund reichen die klassischen Projektmethoden wie bspw. die Wasserfall-Methode nicht aus, um dieser Komplexität standzuhalten. Für die Softwareentwicklung eignet sich SCRUM sehr gut, da Änderungen der Anforderungen im Laufe des Projektes erlaubt sind. In Scrum gibt es wenige Regeln, die schon klar definiert sind. Innerhalb des Teams besteht keine Hierarchie und es finden zahlreiche Meetings statt, diese mögen zwar störend sein, aber für den Erfolg eines Scrum-Projektes sind sie unentbehrlich, denn nur durch Feedback kann das Projekt sein volles Potenzial entfalten
Inhaltsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Abkürzungsverzeichnis
1. Einleitung
2. Definition von SCRUM
3. Die Rollen
3.1 Product Owner
3.2 Entwicklungsteam
3.3 Scrum Master
4. Artefakte
4.1 Product Backlog
4.2 Sprint Backlog
5. Ereignisse
5.1 Sprint
5.2 Sprint Planning
5.3 Daily Scrum
5.4 Sprint Review
5.5 Sprint Retrospective
6. Projekt „ChargeTime App“ entwickeln
7. Kritische Betrachtung
8. Fazit
9. Ausblick
10. Literaturverzeichnis
Abbildungsverzeichnis
Abbildung 1: Scrum-Prozess
Abbildung 2: User Story
Abbildung 3: Sprint Backlog
Abbildung 4: Segelboot-Methode
Tabellenverzeichnis
Tabelle 1: Product Backlog
Tabelle 2: Definition of Done
Tabelle 3: Sprint Backlog
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1. Einleitung
Agile Methoden im Projektmanagement werden immer beliebter und werden fast von jedem Unternehmen implementiert, denn mithilfe dieser werden hochwertige Produkte ressourcenschonend und in kürzerer Zeit auslieferungsfähig. Agil zu arbeiten, bedeutet auf Situationen zu reagieren, die sich während des Projekts immer wieder ändern oder anpassen müssen. Heutzutage gestaltet sich die Ausführung von Projekten viel komplexer, da viele Komponente berücksichtigt werden müssen. Dies hat zur Folge, dass es innerhalb des Projektes sehr schnell unübersichtlich werden kann. Aus diesem Grund reichen die klassischen Projektmethoden wie bspw. die Wasserfall-Methode nicht aus, um dieser Komplexität standzuhalten. Für die Softwareentwicklung eignet sich SCRUM sehr gut, da Änderungen der Anforderungen im Laufe des Projektes erlaubt sind.1 In Scrum gibt es wenige Regeln, die schon klar definiert sind. Innerhalb des Teams besteht keine Hierarchie und es finden zahlreiche Meetings statt, diese mögen zwar störend sein, aber für den Erfolg eines Scrum-Projektes sind sie unentbehrlich, denn nur durch Feedback kann das Projekt sein volles Potenzial entfalten.2
Ziel dieser Arbeit ist, die Entwicklung einer Software mit Hilfe der agilen Methode-Scrum zu demonstrieren. Da es sich in dieser Arbeit um ein theoretisches Model handelt, wird am Ende keine fertige Software präsentiert, sondern es wird die Durchführung eines Sprints aus der Sicht des Scrum-Teams erläutert.
2. Definition von SCRUM
SCRUM ist ein Framework für agiles Projektmanagement. Durch regelmäßiges Feedback und agile Methoden ist eine frühzeitige Auslieferung eines Produktinkrements möglich, das dem Kunden während des Entwicklungsprozesses präsentiert werden kann. Das Ziel eines Projektes mit SCRUM ist, eine kürzere Zeitspanne zwischen Produktidee und Produktauslieferung zu schaffen. Die Grundlagen einer Software mit SCRUM basieren auf der Erstellung der Anforderungen und der Scrum-Rollen: Scrum Master, Product Owner und Entwicklungsteam.3 In der Abbildung 1 kann die Skizze eines Scrum-Prozesses angesehen werden:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Scrum-Prozess
Quelle: https://www.integrata-cegos.de/leistungsangebot-informationstechnologie/scrum-und-agilitaet, Zugriff am 04.05.2020.
3. Die Rollen
Um ein Projekt mit Scrum zu beginnen, werden drei Rollen (Scrum Master, Product Owner, Development-Team) benötigt. In der Praxis kann es sein, dass weitere Rollen ins Spiel kommen, etwa das Management oder die Kunden, die manchmal auch Stakeholder genannt werden. Das Development-Team besteht aus Experten, die über das fachliche Wissen verfügen, um das Produkt entwickeln zu können, der Scrum Master sorgt für einen einwandfreien Prozessablauf im gesamten Projekt und der Product Owner hat die Vorstellung über das Produkt und erarbeitet Aufgaben, die erledigt werden müssen. Alle drei Rollen sind für die erfolgreiche Entwicklung des Produkts verantwortlich.4
3.1 Product Owner
Der Product Owner hat eine besondere Rolle in SCRUM-Projekten. Er ist für das zu entstehende Produkt verantwortlich. Er trifft fachliche Entscheidungen über sein Produkt, bereitet Aufgaben vor, betreut Kunden, unterstützt den Vertrieb, erstellt strategische Maßnahmen, konzipiert Anforderungen und führt Analysen über den Markt und Wettbewerb.5
In seiner Rolle agiert er als Produktmanager, der seine Kunden sehr gut kennt. Idealerweise sollte er am besten seine Rolle als Product Owner ausüben, und nicht direkt an der Entwicklung des Produkts arbeiten, sonst überfordert er sich und kann seiner eigentlichen Tätigkeit nicht mehr nachgehen, wie gesollt. Von ihm wird eine ausgezeichnete Kommunikationsfähigkeit gefordert, da er kontinuierlich mit dem Kunden in Kontakt bleibt. Er soll teamfähig sein und sein Team immer wieder motivieren können.6 Seine wichtigste Aufgabe ist die Erstellung des Backlogs, in diesem werden die Anforderungen an das zukünftige Produkt in priorisierter Form festgelegt.7
3.2 Entwicklungsteam
Idealerweise sollte ein Entwicklungsteam aus 5 oder 7 Personen bestehen. Die Teammitglieder sollten im besten Fall keine externen Aufgaben übernehmen, sondern überwiegend für die Entwicklung des Produkts zuständig sein, damit am Ende die Qualität des Produkts gewährleistet werden kann. Das Team organisiert sich selbst und entscheidet auch selbständig über die Umsetzung des Ergebnisses. Diese Art der Selbstorganisation kommt dem Team zugute und liefert durch die Motivation und Kreativität von Teammitgliedern ein besseres Lieferergebnis.8
3.3 Scrum Master
Der Scrum Master ist in jedem Scrum-Projekt anwesend. Er steht für die Einhaltung der Regeln in SCRUM und sorgt dafür, dass alle Meetings ordnungsgemäß stattfinden und keine Hindernisse im Weg des Entwicklungsteams stehen.9
Die Aufgaben des Scrum Masters beschränken sich auf den Managementbereich und sehen wie folgt aus:10
- Mitarbeiter schulen
- Das Team motivieren
- Probleme und Hindernisse aus dem Weg des Teams räumen
- Kommunikation mit allen Beteiligten
- Sicherstellung von Scrum-Prozessen
- Events moderieren
- Produktivität der Prozesse steigern
Er ist in der Lage die Entwicklersprache in die Kundensprache zu übersetzen. Idealerweise soll der Scrum Master in einem Projekt die Führungskraft sein und nicht direkt an der technischen Entwicklung des Produkts arbeiten.11 Zu seiner Kernaufgabe gehört die Beseitigung der Hindernisse. Ob kleine oder große Hindernisse, sie können das Entwicklungsteam jederzeit in seiner Arbeit beeinträchtigen. Ein typisches Problem kann sich manchmal auch von der Seite des Product Owners ergeben, wenn er vom Entwicklungsteam schnellere Ergebnisse verlangt und dabei das Team unter Druck setzt. Dann ist der Scrum Master gefordert, einen Kompromiss zwischen Product Owner und Entwicklungsteam zu finden, damit der Prozess weiterhin ungestört ablaufen kann.12
4. Artefakte
Ein Scrum Projekt besteht aus Artefakten wie Product Backlog, Sprint Backlog und Produktinkrement. Sie helfen den Projektmitgliedern sich im gesamten Prozess zu orientieren.13 Im folgenden Kapitel werden die genannten Artefakten erläutert.
4.1 Product Backlog
Das Product Backlog wird von dem Product Owner erstellt. In diesem werden Aufgaben priorisiert und Anforderungen an das zukünftige Produkt gestellt, die dann durch das Entwicklungsteam bearbeitet werden.14 Ein Product Backlog wird kontinuierlich durch den Product Owner gepflegt. Dabei handelt es sich um eine dynamische Liste, da dem Backlog immer wieder neue Einträge hinzugefügt werden können. Die Qualität des Backlogs spielt eine wesentlich wichtige Rolle für den Erfolg des Projektes.15 Die Einträge in dem Product Backlog müssen so formuliert werden, dass sie von dem Entwicklungsteam auch verstanden werden können.16
Folgende Einträge gehören laut www.projektmagazin.de zu einem Product Backlog:17
- User Stories
- Fehlerbehebungen
- Qualitätsanforderungen (Backlog Items)
- Verbesserungen
- Eigenschaften und Funktionen des Produkts
User Story
User Storys beschreiben alle Funktionen und Eigenschaften eines Produkts aus der Sicht des Kunden, die im Laufe der Sprints realisiert werden müssen. Eine User Story soll für alle Teammitglieder und Stakeholder leicht zu verstehen sein, damit der Leser schnell erkennen kann, was die Story beschreibt, warum sie wichtig ist und auf was dies zielt.18 Die User Storys werden von dem Product Owner in Form von Karteikarten erstellt und im Product Backlog in priorisierter Form eingetragen.19 Eine User Story kann wie in der Abbildung 2 aussehen:
Abbildung 2 : User Story
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Eid, P., (2019), S. 38.
Storyboard
Das Storyboard gibt einen Überblick über die Reihenfolge der erstellten User Storys. Der Product Owner und das Entwicklungsteam einigen sich über die Vorgehensweise, wie die Funktionalitäten bearbeitet werden sollen. Auch während der Entwicklungsarbeit entstehende Veränderungen können ins Storyboard aufgenommen werden.20 Ein Storyboard kann ein echtes Board oder ein digitales Board sein. Die User Storys werden auf Karteikarten geschrieben und auf dem Board über die Spalten „To Do“, „Work in Progress“ und „Done“ bewegt.21 Das Board ist ein wichtiges Werkzeug, um den Stand des Sprints nachvollziehbar für alle Projektbeteiligten zu machen. Um den Sprint beenden zu können, müssen alle Aufgaben in der Spalte „Done“ aufgeführt sein, bevor der Sprint als abgeschlossen betrachtet wird.22
4.2 Sprint Backlog
In einem Sprint Backlog werden Aufgaben und Elemente aus dem Product Backlog übernommen. Die übernommenen Aufgaben müssen durch das Entwicklungsteam bis zum Ende des Sprints erledigt werden. Sind die Aufgaben nicht erledigt, kehren diese entweder ins Product Backlog zurück oder müssen im nächsten Sprint Backlog erledigt werden.23 Die Abbildung 3 zeigt, wie das Sprint Backlog in der Praxis aussehen kann.
Abbildung 3 : Sprint Backlog
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Pfeffer, J., (2019), S. 87.
Definition of Done
Die Definition of Done, auch DoD genannt, ist ein zwischen dem Product Owner und dem Entwicklungsteam festgehaltenes Dokument, das die Mission hat, die Qualität des Produktinkrements zu steigern. Das Dokument beinhaltet alle Maßnahmen, die für jede Anforderung erfüllt sein müssen, damit diese als „Done“ gelten können. Der Product Owner ist für die Festlegung des Qualitätsniveaus des Produkts zuständig, während das Entwicklungsteam sich Gedanken macht, mit welchen Maßnahmen das entsprechende Qualitätsniveau zu erreichen ist. Alle Maßnahmen, die in der Vereinbarung festgehalten sind, müssen eingehalten werden, damit sie die Bezeichnung „Done“ erhalten können. Jedes Element aus der Definition of Done muss erfüllt sein, damit die Story aus dem Product Backlog abnahmereif ist. Sind die Elemente nicht erfüllt, müssen sie im nächsten Sprint erfüllt werden. Laut Dominik Maximini enthält eine „Definition of Done“ die folgenden Elemente:24
- „Alle Aufgaben sind erledigt bzw. es sind keine Reste mehr übrig“
- „Jede Aufgabe wurde nach dem vier Augen Prinzip geprüft“
- „Alle Akzeptanzkriterien sind erfüllt“
- „Alle Akzeptanzkriterien sind durch automatische Tests abgesichert“
- „Der Code ist vollständig integriert“
- „Alle Tests der Software laufen fehlerfrei durch“
- „Die Dokumentation ist angepasst“
- „Die Codierrichtlinien wurden eingehalten“
Definition of Ready
Definition of Ready ist eine Angabe, die die Aufnahme eines Product Backlog-Items in das Sprint Planning ermöglicht. Das Entwicklungsteam und der Product Owner vereinbaren eine Checkliste mit verschiedenen Kriterien.25 Sind die Kriterien festgelegt, kann das Entwicklungsteam darüber entscheiden, ob die Items für die Aufnahme ins Sprint Planning bereit sind. Das Ziel dieser Vereinbarung ist, dass die Items mit der höchsten Priorität so schnell wie möglich fertig an die Kunden ausgeliefert werden.26
Laut dem Autor Kenneth S. Rubin können folgende Einträge in einer Checkliste stehen:27
- Das Team hat die Aufgaben richtig verstanden und ist in der Lage Entscheidungen zu treffen, ob es das Product Backlog Item abschließen kann.
- Es gibt keine externen Abhängigkeiten, die die Fertigstellung des Product Backlog-Item hindern können.
- Das Team verfügt über ausreichend Mitarbeiter, damit das Product Backlog-Item abgeschlossen werden kann.
- Das Product Backlog-Item kann aufgrund seiner kleinen Größe in einem Sprint fertiggestellt werden.
- Die Kriterien sind testbar und definiert.
- Das Team weiß, wie das Product Backlog-Item beim Sprint Review präsentiert werden kann.
Eine ähnliche Checkliste hilft dem Team bei der Erreichung der Sprint-Ziele.28
Inkrement
Am Ende eines Sprints entstehen in SCRUM Produktinkremente. Diese sind kleine nutzbare Versionen der zu entwickelnden Software, die den Kunden im Sprint Review vorgestellt werden. Das eigentliche Produkt wird durch das Produktinkrement ergänzt und erzielt schon während des Sprints eine Wertschöpfung auf dem Markt.29
5. Ereignisse
5.1 Sprint
Ein Sprint sollte eine maximale Dauer von vier Wochen haben und in der Lage sein, am Ende dieses Zeitabschnitts ein Produktinkrement zu erzeugen. Die Dauer des Sprints ist auf die Größe des Entwicklungsteams oder auf die Komplexität von Anforderungen zurückzuführen.30 Laut dem Autor Dominik Maximini sollen folgende Punkte bei der Anpassung der Sprintlänge beachtet werden:31
- Die Sprintlänge über viele Sprints soll stabil bleiben, um eine gute Produktivität und eine Planungsgrundlage zu erreichen.
- Mindestlänge von Sprints sind in Scrum nicht definiert, sollen aber erfahrungsgemäß minimal eine Woche lang sein.
- Möglichst versuchen, Zeitdruck zu vermeiden.
- Sprints mit einer Länge von zwei bis drei Wochen einplanen, da Sprints mit einer Woche zu anstrengend und Sprints mit vier Wochen zu lang sein können.
- Die Lerngeschwindigkeit ist entscheidend für die Sprintlänge. Lernt das Team schnell, kann die Länge des Sprints auch kürzer sein.
5.2 Sprint Planning
In einem Sprint Planning werden die Aufgaben festgelegt, die im aktuellen Sprint erledigt werden müssen. Diese Aufgaben stammen aus dem Product Backlog und werden je nach Priorisierung durch das Team im Laufe des Sprints umgesetzt. Ein Sprint Planning wird in 2 Blöcken, in Sprint Planning 1 und Sprint Planning 2 aufgeteilt.32 Im ersten Block findet ein Treffen zwischen Product Owner und Entwicklungsteam statt, in diesem stellt der Product Owner dem Team seine Pläne und Ziele vor. Das Team bespricht mit seinen Mitgliedern die von Product Owner vorgegebenen Pläne und versucht eine Prognose zu treffen, um die Sprintziele im gegebenen Zeitraum erreichen zu können. Im zweiten Block wird das Sprintziel bis ins kleinste Detail durch das Entwicklungsteam geplant.33 Hier werden Aufgaben in Teil-Aufgaben (Tasks) verteilt. Tasks sind wichtig, um die Arbeit und den Fortschritt des Teams beobachten zu können. Das Team erstellt eine Liste mit allen Aufgaben, die in dem aktuellen Sprint umgesetzt werden sollen und werden danach unter der Einhaltung der priorisierten User Storys dem Product Owner zur Verfügung gestellt. Erst wenn alles vorbereitet ist, kann mit dem Sprint offiziell begonnen werden. Die Dauer des Meetings soll circa acht Stunden bei einer Sprintlänge von bis zu vier Wochen sein.34
[...]
1 Vgl. Nyamsi, E., (2019), S.V.
2 Vgl. Eid, P., (2019), S. 1.
3 Vgl. Nyamsi, E., (2019), S.V.
4 Vgl. Eid, P., (2019), S. 14.
5 Vgl. Maximini, D., (2013), S. 183-184.
6 Vgl. Maximini, D., (2013), S. 184.
7 Vgl. Eid, P., (2019), S. 24.
8 Vgl. Böhm, J., (2019), S. 37.
9 Vgl. Böhm, J., (2019), S. 38.
10 Vgl. Maximini, D., (2013), S. 186-187.
11 Vgl. Maximini, D., (2013), S. 186-187.
12 Vgl. Eid, P., (2019), S. 22.
13 Vgl., https://www.dasscrumteam.com/de/blog/scrum-guide-und-skalierung-teil-4-scrum-artefakte, Zugriff am 16.04.2020.
14 Vgl. Eid, P., (2019), S. 67.
15 Vgl., https://www.inloox.de/unternehmen/blog/artikel/scrum-grundlagen-einfach-erklaert-der-product-backlog/, Zugriff am 16.04.2020.
16 Vgl. Maximini, D., (2013), S. 193-194.
17 Vgl., https://www.projektmagazin.de/glossarterm/product-backlog, Zugriff am 17.04.2020.
18 Vgl. Eid, P., (2019), S. 37.
19 Vgl. Nyamsi, E., (2019), S. 9.
20 Vgl. Nyamsi, E., (2019), S. 9.
21 Vgl. Böhm, J., (2019), S. 48.
22 Vgl., https://agilescrumgroup.de/scrum-board/, Zugriff am 12.05.2020.
23 Vgl. Eid, P., (2019), S. 78.
24 Maximini, D., (2013), S. 195.
25 Vgl., https://scrumkurs24.de/definition-of-ready/, Zugriff am 27.04.2020.
26 Vgl., https://agilescrumgroup.de/definition-of-ready/, Zugriff am 13.05.2020.
27 Vgl. Kenneth, S., (2014), S. 147-148.
28 Vgl. Kenneth, S., (2014), S. 148.
29 Vgl. Böhm, J., (2019), S. 48.
30 Vgl. Eid, P., (2019), S. 30.
31 Vgl. Maximini, D., (2013), S. 197-198.
32 Vgl., https://www.ingenieur.de/karriere/arbeitsleben/alltag/scrum-so-funktioniert-agiles-projektmanagement-im-sprint/, Zugriff am 20.04.2020.
33 Vgl. Maximini, D., (2013), S. 198.
34 Vgl. Eid, P., (2019), S. 42-44.