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