Wiki source code of Scrum
Version 6.2 by Pascal Meyer on 2025/07/29 03:52
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 | *** 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** | ||
| 89 | |||
| 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 |