Skip to Content

Changes for page Scrum

Last modified by pmeyer on 2025/09/12 04:57
From version arrow_back 1.2 arrow_forward
edited by Pascal Meyer
on 2025/07/29 03:42
Change comment: There is no comment for this version
To version arrow_back 6.2 arrow_forward
edited by Pascal Meyer
on 2025/07/29 03:52
Change comment: There is no comment for this version

Summary

Details

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