Changes for page Scrum

Last modified by pmeyer on 2025/09/12 04:57

arrow_back From 1.3 to 1.2 From 2.1 to 1.9 arrow_forward

From version arrow_back 1.9 arrow_forward

edited by Pascal Meyer
on 2025/07/29 03:49

Change comment: There is no comment for this version

To version arrow_back 1.3 arrow_forward

edited by Pascal Meyer
on 2025/07/29 03:42

Change comment: There is no comment for this version

Raw
Rendered

Summary

insert_drive_file Page properties (1 modified, 0 added, 0 removed)

Details

insert_drive_file Page properties

Content

@@ -1,6 +1,6 @@
--= Scrum - Ein kurzer Überblick =
++= Scrum - Überblick =
--**Was ist Scrum und warum brauchen wir das im SWP?**
++**Was ist Scrum und warum brauchen wir das im SWP?**
  * Scrum ist einer von mehreren agilen Projektmanagement-Ansätzen und insbesondere für die Softwareentwicklung geeignet
  * Wird benötigt, um die Entwicklung des im SWP geforderten Produkts im Rahmen eines vernünftig strukturierten Projektmanagements umzusetzen
@@ -17,303 +17,20 @@
  * 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.)
  * Im SWP "kleine iterative Wasserfälle" → Anforderung, Design, Kodierung, Test
--**Rahmen:**
++**Rahmenbedingungen:**
--* **Rollen:**
--** **Product Owner**
--*** Definiert Product-Features
--*** Bestimmt Auslieferungsdatum und Inhalt
--*** Akzeptiert oder weist Arbeitsergebnisse zurück
--*** Im SWP der Tutor in Absprache mit Marco und das Team
--** **Scrum Master**
--*** Repräsentiert das Management gegenüber dem Projekt
--*** Verantwortlich für die Einhaltung von Scrum-Werten und -Techniken
--*** Beseitigt Hindernisse
--*** Stellt sicher, dass das Team vollständig, funktional und produktiv ist
--*** Unterstützt die enge Zusammenarbeit zwischen allen Rollen und Funktionen
--*** Schützt das Team vor äußeren Störungen
--*** Im SWP ein spezielles Mitglied der Gruppe, welches trotzdem auch mitentwickelt
--** **Entwicklungs-Team**
--*** Typischerweise 5-9 Personen
--*** Funktionsübergreifend
--**** QS, Programmierer, UI-Designer, etc.
--*** Mitglieder sollen Vollzeitmitglieder sein
--*** Teams organisieren sich selbst
--*** Mitgliedschaft kann nur zwischen Sprints verändert werden
--* **Meetings:**
--** **Sprint Planning**
--*** Sprint Priorisierung
--**** Product Backlog analysieren und auswerten
--**** Sprint-Ziel festlegen
--*** Planung
--**** Entscheiden, wie man das Sprint-Ziel erreichen kann (Design)
--**** Sprint Backlog (Tasks) aus Product Backlog (User Stories/Features) erstellen
--***** Team wählt Einheiten, zu deren Implementierung es sich verpflichten kann, aus dem Product Backlog aus
--*** Sprint Backlog schätzen (Planning Poker, Magic Estimation, etc.)
--*** Sprint-Ziel
--**** Kurze Angabe dessen, worauf sich die Arbeiten während des Sprints fokussieren
--**** Wichtig! Wird gerne unterschätzt
--**** Hilft, das Ziel im Auge zu behalten
--** **Sprint Review**
--*** Das Team präsentiert, was es während eines Sprints erreicht hat
--*** Typischerweise in Form einer Demo mit neuen Features oder der zugrunde liegenden Architektur
--*** Das ganze Team nimmt teil!
--** **Sprint Retrospektive**
--*** Regelmäßig prüfen, was gut und was nicht so gut funktioniert
--*** ca. 15-30 min lang
--*** Nach jedem Sprint
--*** Das gesamte Team kommt zusammen und diskutiert, wie es sich verbessern möchte
--*** Methode hierfür bspw: Starfish (siehe Bild)
--*** Weitere Methoden für die Retrospektiven finden sich z.B. hier: [[https:~~/~~/retromat.org/>>url:https://retromat.org/]]
--** **Tägliches Scrum-Meeting (Daily)**
--*** Wöchentliches Treffen startet mit Scrum-Meeting
--*** Am Ende der Sitzung Verteilung neuer Aufgaben (jeder hat mindestens ein Ticket)
--*** Im Weekly werden keine Lösungen diskutiert, dies kann im weiteren Verlauf der Sitzung passieren
--* **Artefakte:**
--** **Product Backlog**
--*** Die Anforderungen für das finale Produkt
--*** Eine Liste aller gewünschten Projektarbeiten
--*** Eigentlich immer mehr, als im aktuellen Sprint gebraucht wird
--*** Im SWP: Zu Beginn füllen und später ergänzen
--*** Vom Product Owner priorisiert
--*** Zu Beginn des Sprints repriorisiert
--** **Sprint Backlog**
--*** Team-Mitglieder wählen Tasks aus (Arbeit wird nie zugewiesen)
--*** Aber**:**
--**** Im SWP hat jeder am Ende einer Sitzung eine Aufgabe!
--**** Im Zweifelsfall durch Zuweisung...
--*** Jedes Team-Mitglied kann Tasks hinzufügen, löschen oder ändern (basierend auf dem aktuellen Ziel)
--*** Wenn Arbeit unklar ist, definieren Sie erstmal einen Task mit größerer Schätzung und erstelle Unteraufgaben, sobald die Arbeit klarer wird
--*** 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]])
--** **Produktinkrement**
++* Rollen
++** Product Owner
++** Scrum Master
++** Entwicklungs-Team
++* Meetings
++** Sprint Planning
++** Sprint Review
++** Sprint Retrospektive
++** Tägliches Scrum-Meeting (Daily)
++* Artefakte
++** Product Backlog
++** Sprint Backlog
++** Produktinkrement
--= Scrum im Detail =
--
--== Scrum-Prozess ==
--
--Nachdem die Produktvision definiert wurde, wird das Product Backlog erstellt und vom
--Product Owner //(hier: gesamtes Team im Softwareprojekt)// verwaltet. Aus dem Sprint
--Planning resultiert das Sprint Backlog, welches im Sprint durch das Entwicklungsteam
--//(hier: Scrum Master gehört zum Entwicklungsteam und programmiert mit)// abgearbeitet
--wird. Der Scrum Master sorgt dafür, dass das Entwicklungsteam ungestört arbeiten
--kann. Täglich //(hier: wöchentlich)// trifft er sich im Daily Scrum mit dem Team. Nach
--dem Sprint wird ein Produktinkrement an den Auftraggeber //(hier: an das gesamte//
--//Team)// ausgeliefert und in einem Sprint Review näher erläutert. Anschließend wird eine
--Sprint Retrospektive durchgeführt, in der das Team die Zusammenarbeit reflektieren kann.
--
--== Product Backlog ==
--
--Ein Product Backlog ist eine priorisierte Anforderungsliste für das von dem Auftraggeber
--gewünschte Softwareprodukt. Diese ist nie vollständig und zu jederzeit anpassbar. Der
--Product Owner //(hier: das gesamte Team)// ergänzt das Backlog stetig und hat in den
--meisten Fällen bereits User Stories für den nächsten Sprint geplant. Aus diesem Grund
--sind in dem Backlog nicht alle für das komplette Produkt relevanten Anforderungen
--zu finden, weil sich von Sprint zu Sprint immer wieder neue Anforderungen ergeben
--oder alte verworfen werden. Es ist auch möglich, dass sich die Prioritäten ändern. Der
--Product Owner //(hier: das gesamte Team)// verwaltet das Backlog, allerdings muss es für
--alle Mitglieder des Scrum Teams ersichtlich sein.
--
--=== **Der Nutzen eines gepflegten/priorisierten Product Backlogs** ===
--
--Priorisiert:
--
--* Um die für das Projekt wertvollsten Stories am Anfang zu bearbeiten
--* So kann schnell ein funktionierendes Spiel entwickelt werden
--* Am Ende ist dann noch genug Zeit für feinere Anpassungen
--* Kann die Arbeit im Projekt erleichtern
--
--Gepflegt:
--
--* Wichtig für ein effizientes, übersichtliches Arbeiten
--
--=== **Unterschiede Product Backlog vs. Sprint Backlog** ===
--
--* Product Backlog ist nie vollständig und zu jederzeit anpassbar
--* Sprint Backlog kann nur unter bestimmten Voraussetzungen angepasst werden
--
--== Sprint Planning ==
--
--Nachdem das Product Backlog initial gefüllt und das Sprint-Ziel festgelegt wurde, kann
--das Planning beginnen. Das Sprint Planning ist wichtig, weil der Product Owner und
--das Entwicklungsteam //(hier: das gesamte Team)// sich so einig über die zu bearbeitenden
--User Stories werden können. In diesem Meeting wird gemeinsam mit dem Team, dem
--Scrum Master und dem Product Owner der Sprint vorbereitet.
--
--=== **Ablauf eines Plannings (Checkliste)** ===
--
--✓ Sprint-Ziel festlegen
--✓ Anhand des Sprint-Ziels die passenden User Stories aus dem Product Backlog suchen
--✓ Die vorhandenen Schätzungen der User Stories überprüfen und ggf. anpassen
--✓ Nicht geschätzte User Stories schätzen
--✓ (nicht im ersten Sprint) Velocity heranziehen und schauen, wie viele Story Points im letzten Sprint erledigt wurden
--✓ Die gleiche Anzahl an Story Points in das Sprint Backlog ziehen
--✓ User Stories in Tasks aufsplitten
--✓ Alle Teammitglieder suchen sich Aufgaben aus, die sie bearbeiten möchten
--✓ Sprint starten
--
--=== **Die dazugehörigen Elemente eines Sprint Plannings** ===
--
--* Sprint-Ziel
--* Schätzen von Aufwänden
--* Product Backlog
--* Velocity
--
--== Schätzen von Aufwänden ==
--
--Es sollte aus mehreren Gründen geschätzt werden. Zum einen bekommen alle Teammitglieder
--einen Einblick in den Inhalt aller User Stories, bevor angefangen wird, sie
--umzusetzen. Dies schärft das Verständnis für das Produkt. Zum anderen findet das
--Schätzen im besten Fall mit dem gesamten Team statt, wodurch dieses Meeting eine
--teamgeistfördernde Aktivität ist. Ein weiterer Vorteil ist, dass jede Person im Team weiß,
--worum es in der Story geht, sodass jede Person jede Aufgabe bearbeiten kann. Außerdem
--können so in Diskussionen Probleme oder zusätzliche Informationen identifiziert werden,
--wenn eine User Story beispielsweise in kleinere sinnvolle Einheiten aufgeteilt werden
--kann. Die Einheit, in der zumeist geschätzt wird, nennt sich "Story Points".
--
--=== **Ablauf der Aufwandsschätzung (Checkliste)** ===
--
--✓ Auf eine Werteskala einigen (Fibonacci oder T-Shirt Größen) (siehe Abschnitt "Vorschlag für eine Werteskala zum Schätzen")
--✓ Auf eine Schätzmethode einigen (siehe Abschnitt "Der Ablauf vom Planningpoker")
--✓ Eine Referenzstory bestimmen, anhand dessen geschätzt werden soll
--✓ Definition of Done bei der Schätzung mit einbeziehen
--✓ Geschätzte Story Points den jeweiligen Stories hinzufügen
--
--=== **Der Ablauf vom Planningpoker** ===
--
--* Jedes Teammitglied hat einen Satz Karten, auf dem eine zuvor bestimmte Werteskala abgebildet ist (online abwandelbar, siehe Abschnitt "Tools, um online zu schätzen")
--* Stories werden vorgestellt
--* Es dürfen Fragen zu den Stories gestellt werden, falls etwas unklar ist
--* Danach legt jedes Teammitglied eine Karte mit einem Wert verdeckt auf den Tisch
--* Hat jede Person eine Karte abgelegt, werden diese umgedreht
--* Ziel: Team einigt sich auf einen Wert
--* Weichen die Werte auf den Karten stark voneinander ab, besteht offenbar Diskussionsbedarf
--* 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
--
--=== **Vorschlag für eine Werteskala zum Schätzen** ===
--
--* Nur wenige Zahlen auswählen (bspw. 1,2,3,5,8)
--* 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
--
--[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/78f387122adf2a44d3b92efa743d3446/tshirtfibo.JPG~|~|alt="tshirtfibo.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/78f387122adf2a44d3b92efa743d3446/tshirtfibo.JPG]]
--
--=== **Definition eines Velocity Charts** ===
--
--Hat das Team schon mindestens einen Sprint hinter sich, kann der nächste Sprint auf
--Basis der Velocity aufgebaut werden. Die Velocity steht für die Geschwindigkeit des
--Teams. Das bedeutet, dass ermittelt wird, wie viele Story Points das Entwicklungsteam
--in dem vorherigen Sprint geschafft hat. Aufgrund dieser Information kann der darauf
--folgende Sprint genauer geplant werden, indem sich das Team nur auf die Anzahl der
--vorher erledigten Story Points committet. Die Abbildung zeigt ein solches Velocity Chart.
--Die x-Achse zeigt die bisherige Anzahl an Sprints und die y-Achse die Story Points, die
--in einem Sprint erledigt wurden. Es ist zu sehen, dass beispielsweise im zweiten Sprint
--15 Story Points geschafft wurden, jedoch im dritten Sprint nur fünf. Ab dem dritten
--Sprint kann eine Verbesserung der Geschwindigkeit des Teams wahrgenommen werden.
--
--[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/3bb28351d712bbf3e9ad6360fd85bc6a/velo.JPG~|~|alt="velo.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/3bb28351d712bbf3e9ad6360fd85bc6a/velo.JPG]]
--
--=== **Definition eines Burndown Charts** ===
--
--Eine Möglichkeit zur Überprüfung des Fortschritts während eines Sprints ist die Erstellung
--eines Burndown Charts. Es zeigt die bereits erledigten Story Points auf Basis
--der verbleibenden Zeit an. Somit kann schnell gesehen werden, ob Verzögerungen oder
--Probleme auftreten und falls dies der Fall ist, kann ein Meeting einberufen werden,
--damit über die Probleme gesprochen wird. Die Abbildung zeigt ein
--Burndown Chart. Auf der x-Achse sind die Arbeitstage zu sehen und auf der y-Achse
--die noch zu erledigenden Story Points für den Sprint. Es ist zu sehen, dass das Team
--bisher einen guten Fortschritt hat, weil der Graph bisher stetig abfällt.
--
--[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/a5dbbbeddb36c2545d5748bfef5124c2/burnd.JPG~|~|alt="burnd.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/a5dbbbeddb36c2545d5748bfef5124c2/burnd.JPG]]
--
--== Daily Scrum ==
--
--Täglich //(hier: wöchentlich)// treffen sich das Entwicklungsteam und der Scrum Master
--zu einem Meeting. Es ist ein sehr kurzes Treffen, welches immer zur gleichen Zeit am
--gleichen Ort stehend stattfindet. Zumeist stehend, damit es bewusst kurz gehalten wird.
--Das Treffen sollte nicht länger als 15 Minuten dauern. Jedes Teammitglied beantwortet
--drei Fragen:
--
--1. Was habe ich gestern gemacht?
--1. Was werde ich heute tun?
--1. Gibt es Hindernisse, die mir im Weg stehen?
--
--Durch das Daily Scrum werden Probleme sichtbar, die für den Scrum Master von großer
--Bedeutung sind, da er hierdurch eventuelle Impediments wahrnehmen und anschließend
--beseitigen kann. Außerdem ist dieses Treffen für das Team wichtig, um sich gegenseitig
--zu informieren und nach eventuell benötigter Hilfe zu suchen. Damit dieses Treffen
--möglichst effektiv ist, sollten sich die Teammitglieder darauf vorbereiten und vorher
--überlegen, was gestern bearbeitet wurde und was heute erledigt wird. Der Scrum
--Master sorgt in diesem Meeting dafür, dass die anderen Teammitglieder nicht den Fokus
--verlieren. Außerdem achtet er auf die Zeit, sodass diese eingehalten wird.
--
--== Definition of Done/Definition of Ready ==
--
--=== **Definition of Done** ===
--
--Während eines Sprints beginnen die Entwickler erst eine neue Story, wenn die vorherige
--abgeschlossen ist. Damit alle Teammitglieder und der Product Owner //(hier: das gesamte//
--//Team)// das gleiche Verständnis für "fertig" haben, gibt es die Definition of Done. Diese
--umfasst eine Sammlung bestimmter Kriterien, die erfüllt sein müssen, damit eine
--Story als "fertig" gilt. Sie ist eine Forderung seitens des Product Owners an das
--Entwicklungsteam //(hier: seitens des Teams)//, welche, ebenso wie die Definition of Ready,
--verhandelt wird. Die Kriterien der Definition of Done sammelt das Team gemeinsam
--mit dem Product Owner //(hier: ohne den Product Owner)// bei einem separaten Treffen.
--
--==== **Nutzen einer Definition of Done** ====
--
--* Wenn keine Definition of Done vorhanden ist, kann es schnell zu einem Impediment führen, da kein klares Ende einer Story in Sicht ist
--* Jedes Teammitglied ist dazu verpflichtet, diese Definition of Done einzuhalten
--* 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
--* Sollte direkt am Anfang erstellt werden, damit das Team sich dahingehend weiterentwickeln und lernen kann
--
--=== **Definition of Ready** ===
--
--Eine Definition of Ready ist eine Sammlung von Forderungen von dem Entwicklungsteam
--an den Product Owner //(hier: innerhalb des Teams)//, wie eine User Story beschrieben
--sein muss, damit das Entwicklungsteam ungestört und ohne Hindernisse arbeiten kann.
--Über diese Forderungen verhandelt das Team mit dem Product Owner //(hier: das Team//
--//handelt die Punkte untereinander aus)// und das Ergebnis ist die Definition of Ready.
--Beispielsweise kann das Team eine Form vorgeben, wie der Titel der Story geschrieben
--sein soll oder dass Akzeptanzkriterien enthalten sein müssen und in welcher Form.
--Das Team muss überprüfen, ob die Kriterien in den User Stories eingehalten wurden.
--Wurden sie nicht eingehalten, können große Verzögerungen entstehen.
--
--=== **Unterschiede zwischen Definition of Done und Definition of Ready** ===
--
--* Definition of Done beschreibt, wann eine User Story fertig bearbeitet wurde
--* Definition of Ready beschreibt, wann eine User Story fertig beschrieben wurde
--
--== Sprint Review ==
--
--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
--die Sprint-Ergebnisse allen Interessierten präsentiert. Dazu gehören beispielsweise der
--Auftraggeber oder andere Stakeholder //(hier: mit dem gesamten Team und ggf. dem//
--//Tutor)//. Der Scrum Master bereitet dieses Meeting vor, indem er die Interessenten über
--dieses Treffen informiert, des Weiteren moderiert er die Sitzung. Die Vorstellung der
--Ergebnisse wird von den Teammitgliedern //(hier: inkl. dem Scrum Master, da auch//
--//der Scrum Master im Softwareprojekt programmiert)// vorbereitet. Nachdem der Scrum
--Master das Meeting eröffnet hat, erklärt er kurz das Sprint-Ziel und die User Stories,
--die abgeschlossen wurden. Dann präsentiert das Entwicklungsteam die Ergebnisse.
--
--=== **Mehrwert eines Reviews** ===
--
--* Dient dazu, allen Teammitgliedern zu zeigen, was in dem Sprint bearbeitet wurde
--* Alle Teammitglieder bleiben auf dem neuesten Stand
--* Es kann dadurch verhindert werden, dass Teammitglieder abgehängt werden, sollte deshalb regelmäßig durchgeführt werden
--* 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
--
--== Sprint Retrospektive ==
--
--Während einer Retrospektive kann das Entwicklungsteam die Zusammenarbeit reflektieren,
--Missmut äußern und Vorschläge für Verbesserungen sammeln. Das Ziel einer
--Retrospektive ist der kontinuierliche Verbesserungsprozess innerhalb des Teams. Ein
--gut funktionierendes Team kann qualitativ hochwertige Produkte liefern. Eine Retrospektive
--muss von einem Scrum Master gut vorbereitet werden. Der Scrum Master
--moderiert dieses Treffen
--
--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]]
--
--Video zur Sprintretrospektive und die Verwendung in Jira [[1080p>>url:https://swl.informatik.uni-oldenburg.de/swp/video/Jira/Sprint-Retrospektive.mp4]]
--
--[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/26a515caf8f128ae250a0240aea01531/Unbenannt2.JPG~|~|alt="Unbenannt2.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/26a515caf8f128ae250a0240aea01531/Unbenannt2.JPG]]
--
--
++= Scrum =

Changes for page Scrum

Summary

Details

Applications

Navigation