Skip to Content

Wiki source code of Scrum

Version 1.5 by Pascal Meyer on 2025/07/29 03:45
Hide last authors
Pascal Meyer 1.5 1 = Scrum - Ein kurzer Überblick =
Pascal Meyer 1.1 2
Pascal Meyer 1.5 3 **Was ist Scrum und warum brauchen wir das im SWP?**
4
5 * Scrum ist einer von mehreren agilen Projektmanagement-Ansätzen und insbesondere für die Softwareentwicklung geeignet
6 * Wird benötigt, um die Entwicklung des im SWP geforderten Produkts im Rahmen eines vernünftig strukturierten Projektmanagements umzusetzen
7
8 **Charakteristika:**
9
10 * Selbst-organisierende Teams
11 * Scrum-Projekte schreiten in Serien von Sprints voran
12 * Typische Sprintdauer beträgt 2-4 Wochen → //Im SWP haben sich 2-3 Wochen bewährt//
13 * Konstante Dauer führt zu einem besseren Rhythmus
14 * Produkt wird während des Sprints entworfen, kodiert und getestet
15 * Es gibt Zeiten, in denen man in keinem Sprint ist, sondern einen neuen Sprint vorbereitet
16 * Anforderungsanalyse sollte grundsätzlich vor allen Sprints erfolgen
17 * Anforderungen sind als Listeneinträge im Product Backlog festgehalten (Hinweis: Das Backlog kann mehr als nur die Anforderungen enthalten, d.h. nicht jeder Eintrag im Backlog entspricht einer Anforderung.)
18 * Im SWP "kleine iterative Wasserfälle" → Anforderung, Design, Kodierung, Test
19
20 **Rahmen:**
21
22 * Rollen
23 ** Product Owner
24 *** Definiert Product-Features
25 *** Bestimmt Auslieferungsdatum und Inhalt
26 *** Akzeptiert oder weist Arbeitsergebnisse zurück
27 *** Im SWP der Tutor in Absprache mit Marco und das Team
28 ** Scrum Master
29 **
30 ** Entwicklungs-Team
31 * Meetings
32 ** Sprint Planning
33 ** Sprint Review
34 ** Sprint Retrospektive
35 ** Tägliches Scrum-Meeting (Daily)
36 * Artefakte
37 ** Product Backlog
38 ** Sprint Backlog
39 ** Produktinkrement
40
41 === **Rollen** ===
42
43 Product Owner:
44
45 * Definiert Product-Features
46 * Bestimmt Auslieferungsdatum und Inhalt
47 * Akzeptiert oder weist Arbeitsergebnisse zurück
48 * Im SWP der Tutor in Absprache mit Marco und das Team
49
50 Scrum Master:
51
52 * Repräsentiert das Management gegenüber dem Projekt
53 * Verantwortlich für die Einhaltung von Scrum-Werten und -Techniken
54 * Beseitigt Hindernisse
55 * Stellt sicher, dass das Team vollständig, funktional und produktiv ist
56 * Unterstützt die enge Zusammenarbeit zwischen allen Rollen und Funktionen
57 * Schützt das Team vor äußeren Störungen
58
59 → Im SWP ein spezielles Mitglied der Gruppe
60
61 → Soll trotzdem auch mit entwickeln
62
63 Entwicklungs-Team:
64
65 * Typischerweise 5-9 Personen
66 * Funktionsübergreifend
67 ** QS, Programmierer, UI-Designer, etc.
68 * Mitglieder sollen Vollzeitmitglieder sein
69 * Teams organisieren sich selbst
70 * Mitgliedschaft kann nur zwischen Sprints verändert werden
71
72 → Es kann helfen, einen Projektleiter zu bestimmen (ist nicht Scrum-Konform, aber im SWP kann es hilfreich sein)
73
74 === **Meetings** ===
75
76 Sprint Planning
77
78 * Sprint Priorisierung
79 ** Product Backlog analysieren und auswerten
80 ** Sprint-Ziel festlegen
81 * Planung
82 ** Entscheiden, wie man das Sprint-Ziel erreichen kann (Design)
83 ** Sprint Backlog (Tasks) aus Product Backlog (User Stories/Features) erstellen
84 *** Team wählt Einheiten, zu deren Implementierung es sich verpflichten kann, aus dem Product Backlog aus
85 * Sprint Backlog schätzen (Planning Poker, Magic Estimation, etc.)
86 * Sprint-Ziel
87 ** Kurze Angabe dessen, worauf sich die Arbeiten während des Sprints fokussieren
88 ** Wichtig! Wird gerne unterschätzt
89 ** Hilft, das Ziel im Auge zu behalten
90
91 Daily Scrum //(hier: Weekly)//
92
93 * Wöchentliches Treffen startet mit Scrum-Meeting
94 * Am Ende der Sitzung Verteilung neuer Aufgaben (jeder hat mindestens ein Ticket)
95 * Im Weekly werden keine Lösungen diskutiert, dies kann im weiteren Verlauf der Sitzung passieren
96
97 Sprint-Review
98
99 * Das Team präsentiert, was es während eines Sprints erreicht hat
100 * Typischerweise in Form einer Demo mit neuen Features oder der zugrunde liegenden Architektur
101 * Das ganze Team nimmt teil!
102
103 Sprint-Retrospektive
104
105 * Regelmäßig prüfen, was gut und was nicht so gut funktioniert
106 * ca. 15-30 min lang
107 * Nach jedem Sprint
108 * Das gesamte Team kommt zusammen und diskutiert, wie es sich verbessern möchte
109 * Methode hierfür bspw: Starfish (siehe Bild)
110 * Weitere Methoden für die Retrospektiven finden sich z.B. hier: [[https:~~/~~/retromat.org/>>url:https://retromat.org/]]
111
112 [[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/e505851f2237f527759101e71f2207f9/Retrospektive.png~|~|alt="Retrospektive.png" height="393" width="524"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/e505851f2237f527759101e71f2207f9/Retrospektive.png]]
113
114 === **Artefakte** ===
115
116 Product Backlog:
117
118 * Die Anforderungen für das finale Produkt
119 * Eine Liste aller gewünschten Projektarbeiten
120 * Eigentlich immer mehr, als im aktuellen Sprint gebraucht wird
121 * Im SWP: Zu Beginn füllen und später ergänzen
122 * Vom Product Owner priorisiert
123 * Zu Beginn des Sprints repriorisiert
124
125 Sprint Backlog:
126
127 * Team-Mitglieder wählen Tasks aus (Arbeit wird nie zugewiesen)
128 * **Aber:**
129 ** Im SWP hat jeder am Ende einer Sitzung eine Aufgabe!
130 ** Im Zweifelsfall durch Zuweisung...
131 * Jedes Team-Mitglied kann Tasks hinzufügen, löschen oder ändern (basierend auf dem aktuellen Ziel)
132 * Wenn Arbeit unklar ist, definieren Sie erstmal einen Task mit größerer Schätzung und erstelle Unteraufgaben, sobald die Arbeit klarer wird
133 * Definieren Sie für die Tickets eine Definition of Done ([[https:~~/~~/www.scrum-events.de/was-ist-die-definition-of-done-dod.html>>url:https://www.scrum-events.de/was-ist-die-definition-of-done-dod.html]])
134
135 = Scrum im Detail =
136
137 == Scrum-Prozess ==
138
139 Nachdem die Produktvision definiert wurde, wird das Product Backlog erstellt und vom
140 Product Owner //(hier: gesamtes Team im Softwareprojekt)// verwaltet. Aus dem Sprint
141 Planning resultiert das Sprint Backlog, welches im Sprint durch das Entwicklungsteam
142 //(hier: Scrum Master gehört zum Entwicklungsteam und programmiert mit)// abgearbeitet
143 wird. Der Scrum Master sorgt dafür, dass das Entwicklungsteam ungestört arbeiten
144 kann. Täglich //(hier: wöchentlich)// trifft er sich im Daily Scrum mit dem Team. Nach
145 dem Sprint wird ein Produktinkrement an den Auftraggeber //(hier: an das gesamte//
146 //Team)// ausgeliefert und in einem Sprint Review näher erläutert. Anschließend wird eine
147 Sprint Retrospektive durchgeführt, in der das Team die Zusammenarbeit reflektieren kann.
148
149 == Product Backlog ==
150
151 Ein Product Backlog ist eine priorisierte Anforderungsliste für das von dem Auftraggeber
152 gewünschte Softwareprodukt. Diese ist nie vollständig und zu jederzeit anpassbar. Der
153 Product Owner //(hier: das gesamte Team)// ergänzt das Backlog stetig und hat in den
154 meisten Fällen bereits User Stories für den nächsten Sprint geplant. Aus diesem Grund
155 sind in dem Backlog nicht alle für das komplette Produkt relevanten Anforderungen
156 zu finden, weil sich von Sprint zu Sprint immer wieder neue Anforderungen ergeben
157 oder alte verworfen werden. Es ist auch möglich, dass sich die Prioritäten ändern. Der
158 Product Owner //(hier: das gesamte Team)// verwaltet das Backlog, allerdings muss es für
159 alle Mitglieder des Scrum Teams ersichtlich sein.
160
161 === **Der Nutzen eines gepflegten/priorisierten Product Backlogs** ===
162
163 Priorisiert:
164
165 * Um die für das Projekt wertvollsten Stories am Anfang zu bearbeiten
166 * So kann schnell ein funktionierendes Spiel entwickelt werden
167 * Am Ende ist dann noch genug Zeit für feinere Anpassungen
168 * Kann die Arbeit im Projekt erleichtern
169
170 Gepflegt:
171
172 * Wichtig für ein effizientes, übersichtliches Arbeiten
173
174 === **Unterschiede Product Backlog vs. Sprint Backlog** ===
175
176 * Product Backlog ist nie vollständig und zu jederzeit anpassbar
177 * Sprint Backlog kann nur unter bestimmten Voraussetzungen angepasst werden
178
179 == Sprint Planning ==
180
181 Nachdem das Product Backlog initial gefüllt und das Sprint-Ziel festgelegt wurde, kann
182 das Planning beginnen. Das Sprint Planning ist wichtig, weil der Product Owner und
183 das Entwicklungsteam //(hier: das gesamte Team)// sich so einig über die zu bearbeitenden
184 User Stories werden können. In diesem Meeting wird gemeinsam mit dem Team, dem
185 Scrum Master und dem Product Owner der Sprint vorbereitet.
186
187 === **Ablauf eines Plannings (Checkliste)** ===
188
189 ✓ Sprint-Ziel festlegen
190 ✓ Anhand des Sprint-Ziels die passenden User Stories aus dem Product Backlog suchen
191 ✓ Die vorhandenen Schätzungen der User Stories überprüfen und ggf. anpassen
192 ✓ Nicht geschätzte User Stories schätzen
193 ✓ (nicht im ersten Sprint) Velocity heranziehen und schauen, wie viele Story Points im letzten Sprint erledigt wurden
194 ✓ Die gleiche Anzahl an Story Points in das Sprint Backlog ziehen
195 ✓ User Stories in Tasks aufsplitten
196 ✓ Alle Teammitglieder suchen sich Aufgaben aus, die sie bearbeiten möchten
197 ✓ Sprint starten
198
199 === **Die dazugehörigen Elemente eines Sprint Plannings** ===
200
201 * Sprint-Ziel
202 * Schätzen von Aufwänden
203 * Product Backlog
204 * Velocity
205
206 == Schätzen von Aufwänden ==
207
208 Es sollte aus mehreren Gründen geschätzt werden. Zum einen bekommen alle Teammitglieder
209 einen Einblick in den Inhalt aller User Stories, bevor angefangen wird, sie
210 umzusetzen. Dies schärft das Verständnis für das Produkt. Zum anderen findet das
211 Schätzen im besten Fall mit dem gesamten Team statt, wodurch dieses Meeting eine
212 teamgeistfördernde Aktivität ist. Ein weiterer Vorteil ist, dass jede Person im Team weiß,
213 worum es in der Story geht, sodass jede Person jede Aufgabe bearbeiten kann. Außerdem
214 können so in Diskussionen Probleme oder zusätzliche Informationen identifiziert werden,
215 wenn eine User Story beispielsweise in kleinere sinnvolle Einheiten aufgeteilt werden
216 kann. Die Einheit, in der zumeist geschätzt wird, nennt sich "Story Points".
217
218 === **Ablauf der Aufwandsschätzung (Checkliste)** ===
219
220 ✓ Auf eine Werteskala einigen (Fibonacci oder T-Shirt Größen) (siehe Abschnitt "Vorschlag für eine Werteskala zum Schätzen")
221 ✓ Auf eine Schätzmethode einigen (siehe Abschnitt "Der Ablauf vom Planningpoker")
222 ✓ Eine Referenzstory bestimmen, anhand dessen geschätzt werden soll
223 ✓ Definition of Done bei der Schätzung mit einbeziehen
224 ✓ Geschätzte Story Points den jeweiligen Stories hinzufügen
225
226 === **Der Ablauf vom Planningpoker** ===
227
228 * Jedes Teammitglied hat einen Satz Karten, auf dem eine zuvor bestimmte Werteskala abgebildet ist (online abwandelbar, siehe Abschnitt "Tools, um online zu schätzen")
229 * Stories werden vorgestellt
230 * Es dürfen Fragen zu den Stories gestellt werden, falls etwas unklar ist
231 * Danach legt jedes Teammitglied eine Karte mit einem Wert verdeckt auf den Tisch
232 * Hat jede Person eine Karte abgelegt, werden diese umgedreht
233 * Ziel: Team einigt sich auf einen Wert
234 * Weichen die Werte auf den Karten stark voneinander ab, besteht offenbar Diskussionsbedarf
235 * Nach der Diskussion geht es in eine zweite Runde, bis sich das Team einigen konnte und alle offenen Fragen zu der Story geklärt sind
236
237 === **Vorschlag für eine Werteskala zum Schätzen** ===
238
239 * Nur wenige Zahlen auswählen (bspw. 1,2,3,5,8)
240 * Wenn in T-Shirt-Größen geschätzt wird, dann jeder Größe eine Zahl zuweisen, sodass das Burndown- und Velocity-Chart genutzt werden kann
241
242 [[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/78f387122adf2a44d3b92efa743d3446/tshirtfibo.JPG~|~|alt="tshirtfibo.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/78f387122adf2a44d3b92efa743d3446/tshirtfibo.JPG]]
243
244 === **Definition eines Velocity Charts** ===
245
246 Hat das Team schon mindestens einen Sprint hinter sich, kann der nächste Sprint auf
247 Basis der Velocity aufgebaut werden. Die Velocity steht für die Geschwindigkeit des
248 Teams. Das bedeutet, dass ermittelt wird, wie viele Story Points das Entwicklungsteam
249 in dem vorherigen Sprint geschafft hat. Aufgrund dieser Information kann der darauf
250 folgende Sprint genauer geplant werden, indem sich das Team nur auf die Anzahl der
251 vorher erledigten Story Points committet. Die Abbildung zeigt ein solches Velocity Chart.
252 Die x-Achse zeigt die bisherige Anzahl an Sprints und die y-Achse die Story Points, die
253 in einem Sprint erledigt wurden. Es ist zu sehen, dass beispielsweise im zweiten Sprint
254 15 Story Points geschafft wurden, jedoch im dritten Sprint nur fünf. Ab dem dritten
255 Sprint kann eine Verbesserung der Geschwindigkeit des Teams wahrgenommen werden.
256
257 [[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/3bb28351d712bbf3e9ad6360fd85bc6a/velo.JPG~|~|alt="velo.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/3bb28351d712bbf3e9ad6360fd85bc6a/velo.JPG]]
258
259 === **Definition eines Burndown Charts** ===
260
261 Eine Möglichkeit zur Überprüfung des Fortschritts während eines Sprints ist die Erstellung
262 eines Burndown Charts. Es zeigt die bereits erledigten Story Points auf Basis
263 der verbleibenden Zeit an. Somit kann schnell gesehen werden, ob Verzögerungen oder
264 Probleme auftreten und falls dies der Fall ist, kann ein Meeting einberufen werden,
265 damit über die Probleme gesprochen wird. Die Abbildung zeigt ein
266 Burndown Chart. Auf der x-Achse sind die Arbeitstage zu sehen und auf der y-Achse
267 die noch zu erledigenden Story Points für den Sprint. Es ist zu sehen, dass das Team
268 bisher einen guten Fortschritt hat, weil der Graph bisher stetig abfällt.
269
270 [[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/a5dbbbeddb36c2545d5748bfef5124c2/burnd.JPG~|~|alt="burnd.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/a5dbbbeddb36c2545d5748bfef5124c2/burnd.JPG]]
271
272 == Daily Scrum ==
273
274 Täglich //(hier: wöchentlich)// treffen sich das Entwicklungsteam und der Scrum Master
275 zu einem Meeting. Es ist ein sehr kurzes Treffen, welches immer zur gleichen Zeit am
276 gleichen Ort stehend stattfindet. Zumeist stehend, damit es bewusst kurz gehalten wird.
277 Das Treffen sollte nicht länger als 15 Minuten dauern. Jedes Teammitglied beantwortet
278 drei Fragen:
279
280 1. Was habe ich gestern gemacht?
281 1. Was werde ich heute tun?
282 1. Gibt es Hindernisse, die mir im Weg stehen?
283
284 Durch das Daily Scrum werden Probleme sichtbar, die für den Scrum Master von großer
285 Bedeutung sind, da er hierdurch eventuelle Impediments wahrnehmen und anschließend
286 beseitigen kann. Außerdem ist dieses Treffen für das Team wichtig, um sich gegenseitig
287 zu informieren und nach eventuell benötigter Hilfe zu suchen. Damit dieses Treffen
288 möglichst effektiv ist, sollten sich die Teammitglieder darauf vorbereiten und vorher
289 überlegen, was gestern bearbeitet wurde und was heute erledigt wird. Der Scrum
290 Master sorgt in diesem Meeting dafür, dass die anderen Teammitglieder nicht den Fokus
291 verlieren. Außerdem achtet er auf die Zeit, sodass diese eingehalten wird.
292
293 == Definition of Done/Definition of Ready ==
294
295 === **Definition of Done** ===
296
297 Während eines Sprints beginnen die Entwickler erst eine neue Story, wenn die vorherige
298 abgeschlossen ist. Damit alle Teammitglieder und der Product Owner //(hier: das gesamte//
299 //Team)// das gleiche Verständnis für "fertig" haben, gibt es die Definition of Done. Diese
300 umfasst eine Sammlung bestimmter Kriterien, die erfüllt sein müssen, damit eine
301 Story als "fertig" gilt. Sie ist eine Forderung seitens des Product Owners an das
302 Entwicklungsteam //(hier: seitens des Teams)//, welche, ebenso wie die Definition of Ready,
303 verhandelt wird. Die Kriterien der Definition of Done sammelt das Team gemeinsam
304 mit dem Product Owner //(hier: ohne den Product Owner)// bei einem separaten Treffen.
305
306 ==== **Nutzen einer Definition of Done** ====
307
308 * Wenn keine Definition of Done vorhanden ist, kann es schnell zu einem Impediment führen, da kein klares Ende einer Story in Sicht ist
309 * Jedes Teammitglied ist dazu verpflichtet, diese Definition of Done einzuhalten
310 * Wenn sie nicht eingehalten wird, kann es am Ende des Projekts zu sehr viel Stress führen, wodurch viel Zeit verloren geht für bspw. Feinheiten
311 * Sollte direkt am Anfang erstellt werden, damit das Team sich dahingehend weiterentwickeln und lernen kann
312
313 === **Definition of Ready** ===
314
315 Eine Definition of Ready ist eine Sammlung von Forderungen von dem Entwicklungsteam
316 an den Product Owner //(hier: innerhalb des Teams)//, wie eine User Story beschrieben
317 sein muss, damit das Entwicklungsteam ungestört und ohne Hindernisse arbeiten kann.
318 Über diese Forderungen verhandelt das Team mit dem Product Owner //(hier: das Team//
319 //handelt die Punkte untereinander aus)// und das Ergebnis ist die Definition of Ready.
320 Beispielsweise kann das Team eine Form vorgeben, wie der Titel der Story geschrieben
321 sein soll oder dass Akzeptanzkriterien enthalten sein müssen und in welcher Form.
322 Das Team muss überprüfen, ob die Kriterien in den User Stories eingehalten wurden.
323 Wurden sie nicht eingehalten, können große Verzögerungen entstehen.
324
325 === **Unterschiede zwischen Definition of Done und Definition of Ready** ===
326
327 * Definition of Done beschreibt, wann eine User Story fertig bearbeitet wurde
328 * Definition of Ready beschreibt, wann eine User Story fertig beschrieben wurde
329
330 == Sprint Review ==
331
332 Am Ende eines Sprints findet das Sprint Review statt (siehe [[Sprint-Review mit Jira>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/691404828/Sprint-Review+mit+Jira]]). Bei diesem Treffen werden
333 die Sprint-Ergebnisse allen Interessierten präsentiert. Dazu gehören beispielsweise der
334 Auftraggeber oder andere Stakeholder //(hier: mit dem gesamten Team und ggf. dem//
335 //Tutor)//. Der Scrum Master bereitet dieses Meeting vor, indem er die Interessenten über
336 dieses Treffen informiert, des Weiteren moderiert er die Sitzung. Die Vorstellung der
337 Ergebnisse wird von den Teammitgliedern //(hier: inkl. dem Scrum Master, da auch//
338 //der Scrum Master im Softwareprojekt programmiert)// vorbereitet. Nachdem der Scrum
339 Master das Meeting eröffnet hat, erklärt er kurz das Sprint-Ziel und die User Stories,
340 die abgeschlossen wurden. Dann präsentiert das Entwicklungsteam die Ergebnisse.
341
342 === **Mehrwert eines Reviews** ===
343
344 * Dient dazu, allen Teammitgliedern zu zeigen, was in dem Sprint bearbeitet wurde
345 * Alle Teammitglieder bleiben auf dem neuesten Stand
346 * Es kann dadurch verhindert werden, dass Teammitglieder abgehängt werden, sollte deshalb regelmäßig durchgeführt werden
347 * Tutor wird über den Fortschritt informiert und kann bei Bedarf Tipps oder Hinweise geben, sodass verhindert werden kann, dass die Studierenden in eine komplett falsche Richtung laufen
348
349 == Sprint Retrospektive ==
350
351 Während einer Retrospektive kann das Entwicklungsteam die Zusammenarbeit reflektieren,
352 Missmut äußern und Vorschläge für Verbesserungen sammeln. Das Ziel einer
353 Retrospektive ist der kontinuierliche Verbesserungsprozess innerhalb des Teams. Ein
354 gut funktionierendes Team kann qualitativ hochwertige Produkte liefern. Eine Retrospektive
355 muss von einem Scrum Master gut vorbereitet werden. Der Scrum Master
356 moderiert dieses Treffen
357
358 Beispiele für Retrospektiven finden sich z.B. hier: [[https:~~/~~/dzone.com/articles/7-formats-for-great-team-retrospectives?edition=703410>>url:https://dzone.com/articles/7-formats-for-great-team-retrospectives?edition=703410]]
359
360 Video zur Sprintretrospektive und die Verwendung in Jira [[1080p>>url:https://swl.informatik.uni-oldenburg.de/swp/video/Jira/Sprint-Retrospektive.mp4]]
361
362 [[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/26a515caf8f128ae250a0240aea01531/Unbenannt2.JPG~|~|alt="Unbenannt2.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/26a515caf8f128ae250a0240aea01531/Unbenannt2.JPG]]
363
Pascal Meyer 1.4 364