Wiki source code of Scrum
Version 5.1 by Pascal Meyer on 2025/07/29 03:51
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
1.5 | 1 | = Scrum - Ein kurzer Überblick = |
| |
1.1 | 2 | |
| |
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 | |||
| |
1.8 | 22 | * **Rollen:** |
| |
1.7 | 23 | ** **Product Owner** |
| |
1.5 | 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 | ||
| |
1.7 | 28 | ** **Scrum Master** |
| |
1.6 | 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 | ||
| |
1.7 | 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 | ||
| |
1.8 | 43 | * **Meetings:** |
| |
1.7 | 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 | ||
| |
3.2 | 57 | ** **Sprint Review** |
| |
1.8 | 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:** | ||
| |
1.9 | 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]]) | ||
| |
3.2 | 88 | ** **Produktinkrement** |
| |
1.5 | 89 | |
| |
3.2 | 90 | = Scrum - im Detail = |
| |
1.5 | 91 | |
| 92 | == Scrum-Prozess == | ||
| 93 | |||
| 94 | Nachdem die Produktvision definiert wurde, wird das Product Backlog erstellt und vom | ||
| 95 | Product Owner //(hier: gesamtes Team im Softwareprojekt)// verwaltet. Aus dem Sprint | ||
| 96 | Planning resultiert das Sprint Backlog, welches im Sprint durch das Entwicklungsteam | ||
| 97 | //(hier: Scrum Master gehört zum Entwicklungsteam und programmiert mit)// abgearbeitet | ||
| 98 | wird. Der Scrum Master sorgt dafür, dass das Entwicklungsteam ungestört arbeiten | ||
| 99 | kann. Täglich //(hier: wöchentlich)// trifft er sich im Daily Scrum mit dem Team. Nach | ||
| 100 | dem Sprint wird ein Produktinkrement an den Auftraggeber //(hier: an das gesamte// | ||
| 101 | //Team)// ausgeliefert und in einem Sprint Review näher erläutert. Anschließend wird eine | ||
| 102 | Sprint Retrospektive durchgeführt, in der das Team die Zusammenarbeit reflektieren kann. | ||
| 103 | |||
| 104 | == Product Backlog == | ||
| 105 | |||
| 106 | Ein Product Backlog ist eine priorisierte Anforderungsliste für das von dem Auftraggeber | ||
| 107 | gewünschte Softwareprodukt. Diese ist nie vollständig und zu jederzeit anpassbar. Der | ||
| 108 | Product Owner //(hier: das gesamte Team)// ergänzt das Backlog stetig und hat in den | ||
| 109 | meisten Fällen bereits User Stories für den nächsten Sprint geplant. Aus diesem Grund | ||
| 110 | sind in dem Backlog nicht alle für das komplette Produkt relevanten Anforderungen | ||
| 111 | zu finden, weil sich von Sprint zu Sprint immer wieder neue Anforderungen ergeben | ||
| 112 | oder alte verworfen werden. Es ist auch möglich, dass sich die Prioritäten ändern. Der | ||
| 113 | Product Owner //(hier: das gesamte Team)// verwaltet das Backlog, allerdings muss es für | ||
| 114 | alle Mitglieder des Scrum Teams ersichtlich sein. | ||
| 115 | |||
| 116 | === **Der Nutzen eines gepflegten/priorisierten Product Backlogs** === | ||
| 117 | |||
| 118 | Priorisiert: | ||
| 119 | |||
| 120 | * Um die für das Projekt wertvollsten Stories am Anfang zu bearbeiten | ||
| 121 | * So kann schnell ein funktionierendes Spiel entwickelt werden | ||
| 122 | * Am Ende ist dann noch genug Zeit für feinere Anpassungen | ||
| 123 | * Kann die Arbeit im Projekt erleichtern | ||
| 124 | |||
| 125 | Gepflegt: | ||
| 126 | |||
| 127 | * Wichtig für ein effizientes, übersichtliches Arbeiten | ||
| 128 | |||
| 129 | === **Unterschiede Product Backlog vs. Sprint Backlog** === | ||
| 130 | |||
| 131 | * Product Backlog ist nie vollständig und zu jederzeit anpassbar | ||
| 132 | * Sprint Backlog kann nur unter bestimmten Voraussetzungen angepasst werden | ||
| 133 | |||
| 134 | == Sprint Planning == | ||
| 135 | |||
| 136 | Nachdem das Product Backlog initial gefüllt und das Sprint-Ziel festgelegt wurde, kann | ||
| 137 | das Planning beginnen. Das Sprint Planning ist wichtig, weil der Product Owner und | ||
| 138 | das Entwicklungsteam //(hier: das gesamte Team)// sich so einig über die zu bearbeitenden | ||
| 139 | User Stories werden können. In diesem Meeting wird gemeinsam mit dem Team, dem | ||
| 140 | Scrum Master und dem Product Owner der Sprint vorbereitet. | ||
| 141 | |||
| 142 | === **Ablauf eines Plannings (Checkliste)** === | ||
| 143 | |||
| 144 | ✓ Sprint-Ziel festlegen | ||
| 145 | ✓ Anhand des Sprint-Ziels die passenden User Stories aus dem Product Backlog suchen | ||
| 146 | ✓ Die vorhandenen Schätzungen der User Stories überprüfen und ggf. anpassen | ||
| 147 | ✓ Nicht geschätzte User Stories schätzen | ||
| 148 | ✓ (nicht im ersten Sprint) Velocity heranziehen und schauen, wie viele Story Points im letzten Sprint erledigt wurden | ||
| 149 | ✓ Die gleiche Anzahl an Story Points in das Sprint Backlog ziehen | ||
| 150 | ✓ User Stories in Tasks aufsplitten | ||
| 151 | ✓ Alle Teammitglieder suchen sich Aufgaben aus, die sie bearbeiten möchten | ||
| 152 | ✓ Sprint starten | ||
| 153 | |||
| 154 | === **Die dazugehörigen Elemente eines Sprint Plannings** === | ||
| 155 | |||
| 156 | * Sprint-Ziel | ||
| 157 | * Schätzen von Aufwänden | ||
| 158 | * Product Backlog | ||
| 159 | * Velocity | ||
| 160 | |||
| 161 | == Schätzen von Aufwänden == | ||
| 162 | |||
| 163 | Es sollte aus mehreren Gründen geschätzt werden. Zum einen bekommen alle Teammitglieder | ||
| 164 | einen Einblick in den Inhalt aller User Stories, bevor angefangen wird, sie | ||
| 165 | umzusetzen. Dies schärft das Verständnis für das Produkt. Zum anderen findet das | ||
| 166 | Schätzen im besten Fall mit dem gesamten Team statt, wodurch dieses Meeting eine | ||
| 167 | teamgeistfördernde Aktivität ist. Ein weiterer Vorteil ist, dass jede Person im Team weiß, | ||
| 168 | worum es in der Story geht, sodass jede Person jede Aufgabe bearbeiten kann. Außerdem | ||
| 169 | können so in Diskussionen Probleme oder zusätzliche Informationen identifiziert werden, | ||
| 170 | wenn eine User Story beispielsweise in kleinere sinnvolle Einheiten aufgeteilt werden | ||
| 171 | kann. Die Einheit, in der zumeist geschätzt wird, nennt sich "Story Points". | ||
| 172 | |||
| 173 | === **Ablauf der Aufwandsschätzung (Checkliste)** === | ||
| 174 | |||
| 175 | ✓ Auf eine Werteskala einigen (Fibonacci oder T-Shirt Größen) (siehe Abschnitt "Vorschlag für eine Werteskala zum Schätzen") | ||
| 176 | ✓ Auf eine Schätzmethode einigen (siehe Abschnitt "Der Ablauf vom Planningpoker") | ||
| 177 | ✓ Eine Referenzstory bestimmen, anhand dessen geschätzt werden soll | ||
| 178 | ✓ Definition of Done bei der Schätzung mit einbeziehen | ||
| 179 | ✓ Geschätzte Story Points den jeweiligen Stories hinzufügen | ||
| 180 | |||
| 181 | === **Der Ablauf vom Planningpoker** === | ||
| 182 | |||
| 183 | * Jedes Teammitglied hat einen Satz Karten, auf dem eine zuvor bestimmte Werteskala abgebildet ist (online abwandelbar, siehe Abschnitt "Tools, um online zu schätzen") | ||
| 184 | * Stories werden vorgestellt | ||
| 185 | * Es dürfen Fragen zu den Stories gestellt werden, falls etwas unklar ist | ||
| 186 | * Danach legt jedes Teammitglied eine Karte mit einem Wert verdeckt auf den Tisch | ||
| 187 | * Hat jede Person eine Karte abgelegt, werden diese umgedreht | ||
| 188 | * Ziel: Team einigt sich auf einen Wert | ||
| 189 | * Weichen die Werte auf den Karten stark voneinander ab, besteht offenbar Diskussionsbedarf | ||
| 190 | * 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 | ||
| 191 | |||
| 192 | === **Vorschlag für eine Werteskala zum Schätzen** === | ||
| 193 | |||
| 194 | * Nur wenige Zahlen auswählen (bspw. 1,2,3,5,8) | ||
| 195 | * 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 | ||
| 196 | |||
| |
3.2 | 197 | [[image:tshirtfibo.JPG]] |
| |
1.5 | 198 | |
| 199 | === **Definition eines Velocity Charts** === | ||
| 200 | |||
| 201 | Hat das Team schon mindestens einen Sprint hinter sich, kann der nächste Sprint auf | ||
| 202 | Basis der Velocity aufgebaut werden. Die Velocity steht für die Geschwindigkeit des | ||
| 203 | Teams. Das bedeutet, dass ermittelt wird, wie viele Story Points das Entwicklungsteam | ||
| 204 | in dem vorherigen Sprint geschafft hat. Aufgrund dieser Information kann der darauf | ||
| 205 | folgende Sprint genauer geplant werden, indem sich das Team nur auf die Anzahl der | ||
| 206 | vorher erledigten Story Points committet. Die Abbildung zeigt ein solches Velocity Chart. | ||
| 207 | Die x-Achse zeigt die bisherige Anzahl an Sprints und die y-Achse die Story Points, die | ||
| 208 | in einem Sprint erledigt wurden. Es ist zu sehen, dass beispielsweise im zweiten Sprint | ||
| 209 | 15 Story Points geschafft wurden, jedoch im dritten Sprint nur fünf. Ab dem dritten | ||
| 210 | Sprint kann eine Verbesserung der Geschwindigkeit des Teams wahrgenommen werden. | ||
| 211 | |||
| |
3.2 | 212 | [[image:velo.JPG]] |
| |
1.5 | 213 | |
| 214 | === **Definition eines Burndown Charts** === | ||
| 215 | |||
| 216 | Eine Möglichkeit zur Überprüfung des Fortschritts während eines Sprints ist die Erstellung | ||
| 217 | eines Burndown Charts. Es zeigt die bereits erledigten Story Points auf Basis | ||
| 218 | der verbleibenden Zeit an. Somit kann schnell gesehen werden, ob Verzögerungen oder | ||
| 219 | Probleme auftreten und falls dies der Fall ist, kann ein Meeting einberufen werden, | ||
| 220 | damit über die Probleme gesprochen wird. Die Abbildung zeigt ein | ||
| 221 | Burndown Chart. Auf der x-Achse sind die Arbeitstage zu sehen und auf der y-Achse | ||
| 222 | die noch zu erledigenden Story Points für den Sprint. Es ist zu sehen, dass das Team | ||
| 223 | bisher einen guten Fortschritt hat, weil der Graph bisher stetig abfällt. | ||
| 224 | |||
| |
3.2 | 225 | |
| |
1.5 | 226 | |
| 227 | == Daily Scrum == | ||
| 228 | |||
| 229 | Täglich //(hier: wöchentlich)// treffen sich das Entwicklungsteam und der Scrum Master | ||
| 230 | zu einem Meeting. Es ist ein sehr kurzes Treffen, welches immer zur gleichen Zeit am | ||
| 231 | gleichen Ort stehend stattfindet. Zumeist stehend, damit es bewusst kurz gehalten wird. | ||
| 232 | Das Treffen sollte nicht länger als 15 Minuten dauern. Jedes Teammitglied beantwortet | ||
| 233 | drei Fragen: | ||
| 234 | |||
| 235 | 1. Was habe ich gestern gemacht? | ||
| 236 | 1. Was werde ich heute tun? | ||
| 237 | 1. Gibt es Hindernisse, die mir im Weg stehen? | ||
| 238 | |||
| 239 | Durch das Daily Scrum werden Probleme sichtbar, die für den Scrum Master von großer | ||
| 240 | Bedeutung sind, da er hierdurch eventuelle Impediments wahrnehmen und anschließend | ||
| 241 | beseitigen kann. Außerdem ist dieses Treffen für das Team wichtig, um sich gegenseitig | ||
| 242 | zu informieren und nach eventuell benötigter Hilfe zu suchen. Damit dieses Treffen | ||
| 243 | möglichst effektiv ist, sollten sich die Teammitglieder darauf vorbereiten und vorher | ||
| 244 | überlegen, was gestern bearbeitet wurde und was heute erledigt wird. Der Scrum | ||
| 245 | Master sorgt in diesem Meeting dafür, dass die anderen Teammitglieder nicht den Fokus | ||
| 246 | verlieren. Außerdem achtet er auf die Zeit, sodass diese eingehalten wird. | ||
| 247 | |||
| 248 | == Definition of Done/Definition of Ready == | ||
| 249 | |||
| 250 | === **Definition of Done** === | ||
| 251 | |||
| 252 | Während eines Sprints beginnen die Entwickler erst eine neue Story, wenn die vorherige | ||
| 253 | abgeschlossen ist. Damit alle Teammitglieder und der Product Owner //(hier: das gesamte// | ||
| 254 | //Team)// das gleiche Verständnis für "fertig" haben, gibt es die Definition of Done. Diese | ||
| 255 | umfasst eine Sammlung bestimmter Kriterien, die erfüllt sein müssen, damit eine | ||
| 256 | Story als "fertig" gilt. Sie ist eine Forderung seitens des Product Owners an das | ||
| 257 | Entwicklungsteam //(hier: seitens des Teams)//, welche, ebenso wie die Definition of Ready, | ||
| 258 | verhandelt wird. Die Kriterien der Definition of Done sammelt das Team gemeinsam | ||
| 259 | mit dem Product Owner //(hier: ohne den Product Owner)// bei einem separaten Treffen. | ||
| 260 | |||
| 261 | ==== **Nutzen einer Definition of Done** ==== | ||
| 262 | |||
| 263 | * Wenn keine Definition of Done vorhanden ist, kann es schnell zu einem Impediment führen, da kein klares Ende einer Story in Sicht ist | ||
| 264 | * Jedes Teammitglied ist dazu verpflichtet, diese Definition of Done einzuhalten | ||
| 265 | * 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 | ||
| 266 | * Sollte direkt am Anfang erstellt werden, damit das Team sich dahingehend weiterentwickeln und lernen kann | ||
| 267 | |||
| 268 | === **Definition of Ready** === | ||
| 269 | |||
| 270 | Eine Definition of Ready ist eine Sammlung von Forderungen von dem Entwicklungsteam | ||
| 271 | an den Product Owner //(hier: innerhalb des Teams)//, wie eine User Story beschrieben | ||
| 272 | sein muss, damit das Entwicklungsteam ungestört und ohne Hindernisse arbeiten kann. | ||
| 273 | Über diese Forderungen verhandelt das Team mit dem Product Owner //(hier: das Team// | ||
| 274 | //handelt die Punkte untereinander aus)// und das Ergebnis ist die Definition of Ready. | ||
| 275 | Beispielsweise kann das Team eine Form vorgeben, wie der Titel der Story geschrieben | ||
| 276 | sein soll oder dass Akzeptanzkriterien enthalten sein müssen und in welcher Form. | ||
| 277 | Das Team muss überprüfen, ob die Kriterien in den User Stories eingehalten wurden. | ||
| 278 | Wurden sie nicht eingehalten, können große Verzögerungen entstehen. | ||
| 279 | |||
| 280 | === **Unterschiede zwischen Definition of Done und Definition of Ready** === | ||
| 281 | |||
| 282 | * Definition of Done beschreibt, wann eine User Story fertig bearbeitet wurde | ||
| 283 | * Definition of Ready beschreibt, wann eine User Story fertig beschrieben wurde | ||
| 284 | |||
| 285 | == Sprint Review == | ||
| 286 | |||
| 287 | 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 | ||
| 288 | die Sprint-Ergebnisse allen Interessierten präsentiert. Dazu gehören beispielsweise der | ||
| 289 | Auftraggeber oder andere Stakeholder //(hier: mit dem gesamten Team und ggf. dem// | ||
| 290 | //Tutor)//. Der Scrum Master bereitet dieses Meeting vor, indem er die Interessenten über | ||
| 291 | dieses Treffen informiert, des Weiteren moderiert er die Sitzung. Die Vorstellung der | ||
| 292 | Ergebnisse wird von den Teammitgliedern //(hier: inkl. dem Scrum Master, da auch// | ||
| 293 | //der Scrum Master im Softwareprojekt programmiert)// vorbereitet. Nachdem der Scrum | ||
| 294 | Master das Meeting eröffnet hat, erklärt er kurz das Sprint-Ziel und die User Stories, | ||
| 295 | die abgeschlossen wurden. Dann präsentiert das Entwicklungsteam die Ergebnisse. | ||
| 296 | |||
| 297 | === **Mehrwert eines Reviews** === | ||
| 298 | |||
| 299 | * Dient dazu, allen Teammitgliedern zu zeigen, was in dem Sprint bearbeitet wurde | ||
| 300 | * Alle Teammitglieder bleiben auf dem neuesten Stand | ||
| 301 | * Es kann dadurch verhindert werden, dass Teammitglieder abgehängt werden, sollte deshalb regelmäßig durchgeführt werden | ||
| 302 | * 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 | ||
| 303 | |||
| 304 | == Sprint Retrospektive == | ||
| 305 | |||
| 306 | Während einer Retrospektive kann das Entwicklungsteam die Zusammenarbeit reflektieren, | ||
| 307 | Missmut äußern und Vorschläge für Verbesserungen sammeln. Das Ziel einer | ||
| 308 | Retrospektive ist der kontinuierliche Verbesserungsprozess innerhalb des Teams. Ein | ||
| 309 | gut funktionierendes Team kann qualitativ hochwertige Produkte liefern. Eine Retrospektive | ||
| 310 | muss von einem Scrum Master gut vorbereitet werden. Der Scrum Master | ||
| 311 | moderiert dieses Treffen | ||
| 312 | |||
| 313 | 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]] | ||
| 314 | |||
| 315 | Video zur Sprintretrospektive und die Verwendung in Jira [[1080p>>url:https://swl.informatik.uni-oldenburg.de/swp/video/Jira/Sprint-Retrospektive.mp4]] | ||
| 316 | |||
| 317 | [[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/26a515caf8f128ae250a0240aea01531/Unbenannt2.JPG~|~|alt="Unbenannt2.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/26a515caf8f128ae250a0240aea01531/Unbenannt2.JPG]] | ||
| 318 | |||
| |
1.4 | 319 |