Changes for page Scrum

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

arrow_back From 6.3 to 6.2 From 10.1 to 9.2 arrow_forward

From version arrow_back 9.2 arrow_forward

edited by Pascal Meyer
on 2025/07/30 17:42

Change comment: There is no comment for this version

To version arrow_back 6.3 arrow_forward

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

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, 0 added, 1 removed)
- attach_file Unbenannt.JPG

Details

insert_drive_file Page properties

Content

@@ -1,5 +3,3 @@
--{{toc/}}
--
  = Scrum - Ein kurzer Überblick =
  **Was ist Scrum und warum brauchen wir das im SWP?**
@@ -60,7 +60,7 @@
  *** 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**
++** **Sprint Retrospektive**
  *** Regelmäßig prüfen, was gut und was nicht so gut funktioniert
  *** ca. 15-30 min lang
  *** Nach jedem Sprint
@@ -67,7 +67,7 @@
  *** 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)**
++** **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
@@ -195,13 +195,22 @@
 . Was werde ich heute tun?
 . 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.
++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.
++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** ====
@@ -212,7 +212,15 @@
  === **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.
++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** ===
@@ -221,7 +221,15 @@
  == Sprint Review ==
--Am Ende eines Sprints findet das Sprint Review statt. 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.
++Am Ende eines Sprints findet das Sprint Review statt. 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** ===
@@ -232,89 +232,19 @@
  == 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
++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]]
  [[image:Unbenannt2.JPG]]
++
++
--= User-Stories =
--
--== Was sind User Stories? ==
--
--Ein Werkzeug, das häufig im agilen Projektmanagement eingesetzt wird, sind User
--Stories. Eine User Story ist eine Beschreibung einer Anforderung an ein Softwareprodukt.
--Sie ist aus der Sicht eines Nutzers //(hier: Spielteilnehmer)// formuliert. Außerdem
--wird in einer User Story immer ein Mehrwert und eine Bedeutung für den Nutzer
--erwähnt, welchen dieser durch die Funktionalität hat. Diese Funktionalität wird in
--das zu erstellende Produkt implementiert und erhöht somit den Wert des Produkts.
--Eine User Story liefert also immer einen Mehrwert. Der Titel der User Story beschreibt
--knapp die Hauptaussage der gesamten Story, welche immer das Ziel des Nutzers ist. In
--den meisten Fällen wird eine User Story in der folgenden Form geschrieben:
--
--
--"Als [Rolle] möchte ich [Tätigkeit], um [Nutzen]."
--
--
--Im Rahmen des Softwareprojekts könnte eine User Story beispielsweise wie folgt aussehen:
--//"Als Nutzer dieses Systems möchte ich mich einloggen können, um ein Spiel zu//
--//starten."// Die explizite Erwähnung der [Rolle] ist wichtig, weil der Anwendungsfall von
--Rolle zu Rolle variieren kann. Die [Tätigkeit] ist der Vorgang, welchen die Rolle bei
--Nutzung des vom Team zu implementierenden Produkts ausführt. Der [Nutzen] dient
--zur Einordnung der Wichtigkeit und hilft, eine Priorisierung der zu implementierenden
--Features vorzunehmen. Außerdem hilft es dem Team zu verstehen, warum sie dieses
--Feature implementieren sollen.
--
--== Mehrwert von User Stories ==
--
--Da User Stories so formuliert werden sollten, dass sie jeder versteht, kann eine intensive
--Zusammenarbeit mit dem Auftraggeber //(hier: intensive Zusammenarbeit mit dem//
--//gesamten Team)// entstehen. Hierdurch wird die Beziehung untereinander gestärkt und
--sowohl Entwickler als auch Auftraggeber verstehen die Ziele der User Stories gleicherma-
--ßen. Ein weiterer Vorteil ist die Anpassbarkeit, weil sich die Wünsche des Auftraggebers
--jederzeit ändern können. Aus diesem Grund implementieren die Entwickler im schlimmsten
--Fall nur für eine sehr kurze Zeit etwas, was in der nächsten Iteration hinfällig ist,
--da sich der Wunsch des Auftraggebers jederzeit ändern kann. Außerdem werden nur
--die Stories detaillierter beschrieben, die in der Iteration erledigt werden sollen. So wird
--keine Zeit für die Planung von etwas aufgewendet, das sich im Nachhinein eventuell als
--obsolet herausstellt.
--
--== Der Nutzen von Akzeptanzkriterien ==
--
--Da die Entwickler eventuell unterschiedliche Vorstellungen davon haben, wann eine
--bestimmte User Story fertig bearbeitet ist, hat sie bestimmte Akzeptanzkriterien. Diese
--bestimmen die Vollständigkeit der in der Story gewünschten Funktion. Sobald diese
--Akzeptanzkriterien erfüllt sind, ist die User Story vollständig umgesetzt und liefert nur
--dann den gewünschten Mehrwert für den Auftraggeber //(hier: für das Team)//.
--
--== INVEST-Prinzip ==
--
--Es gibt bestimmte Eigenschaften, die eine gute User Story ausmachen. Mit dem INVEST-
--Prinzip lassen sich diese Eigenschaften beschreiben. Dabei ist das Wort INVEST ein
--Akronym für die folgenden Eigenschaften einer guten User Story:
--
--**Independent** Diese Eigenschaft meint, dass eine gute User Story unabhängig von
--anderen ist. Sind Stories voneinander abhängig, können Probleme entstehen, die eine
--Priorisierung erschweren.
--
--**Negotiable** Verhandelbare User Stories bedeuten, dass während des Entwicklungsprozesses
--bestimmte Akzeptanzkriterien angepasst werden können, wenn diese mit dem
--Auftraggeber //(hier: mit dem gesamten Team)// verhandelt wurden.
--
--**Valuable** Wertvolle User Stories meinen, dass sie einen bestimmten Mehrwert für
--den Auftraggeber und den Nutzer darstellen.
--
--**Estimatable** Eine gute User Story soll schätzbar sein, das bedeutet, dass die Story
--von anderen abgegrenzt wird, sodass sie gut unterscheidbar ist.
--
--**Small** Damit eine User Story gut schätzbar ist, muss sie klein sein. Außerdem können
--zu große User Stories nicht in einem Sprint bearbeitet werden.
--
--**Testable** Eine testbare User Story hat gut strukturierte Akzeptanzkriterien, die
--getestet werden können.
--
--=== Ausreichend beschriebene User Story mit dem INVEST-Prinzip ===
--
--[[image:Unbenannt.JPG]]
++

attach_file Unbenannt.JPG

Author

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

Size

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

Content info

Changes for page Scrum

Summary

Details

Applications

Navigation