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