Changes for page Scrum

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

arrow_back From 1.4 to 1.5 From 3.2 to 4.1 arrow_forward

From version arrow_back 1.5 arrow_forward

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

Change comment: There is no comment for this version

To version arrow_back 3.2 arrow_forward

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

Change comment: There is no comment for this version

Raw
Rendered

Summary

insert_drive_file Page properties (1 modified, 0 added, 0 removed)
attach_file Attachments (0 modified, 2 added, 0 removed)
- attach_file tshirtfibo.JPG
- attach_file velo.JPG

Details

insert_drive_file Page properties

Content

@@ -19,121 +19,76 @@
  **Rahmen:**
--* Rollen
--** Product Owner
++* **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
--**
--** Entwicklungs-Team
--* Meetings
--** Sprint Planning
--** Sprint Review
--** Sprint Retrospektive
--** Tägliches Scrum-Meeting (Daily)
--* Artefakte
--** Product Backlog
--** Sprint Backlog
--** Produktinkrement
++** **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** ===
++= Scrum - im Detail =
--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
--
--           → Soll trotzdem auch mit entwickeln
--
--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
--
--           → Es kann helfen, einen Projektleiter zu bestimmen (ist nicht Scrum-Konform, aber im SWP kann es hilfreich sein)
--
--=== **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
--
--Daily Scrum //(hier: Weekly)//
--
--* 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
--
--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/]]
--
--[[~[~[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]]
--
--=== **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]])
--
--= Scrum im Detail =
--
  == Scrum-Prozess ==
  Nachdem die Produktvision definiert wurde, wird das Product Backlog erstellt und vom
@@ -239,7 +239,7 @@
  * 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]]
++[[image:tshirtfibo.JPG]]
  === **Definition eines Velocity Charts** ===
@@ -254,7 +254,7 @@
 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]]
++[[image:velo.JPG]]
  === **Definition eines Burndown Charts** ===
@@ -267,7 +267,7 @@
  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 ==

attach_file tshirtfibo.JPG

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.PascalMeyer

Size

...	...	@@ -1,0 +1,1 @@
	1	+20.8 KB

Content info

attach_file velo.JPG