Changes for page Scrum

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

arrow_back From 20.1 to 21.1 From 27.1 to 27.2 arrow_forward

From version arrow_back 21.1 arrow_forward

edited by Pascal Meyer
on 2025/07/30 18:26

Change comment: There is no comment for this version

To version arrow_back 27.1 arrow_forward

edited by pmeyer
on 2025/08/28 20:32

Change comment: There is no comment for this version

Raw
Rendered

Summary

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

Details

insert_drive_file Page properties

Author

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

Content

@@ -1,3 +1,5 @@
++[[image:Main.Organisatorisches.WebHome@softwareprojekt_logo_transparent.png||alt="SoftwareprojektLogo.png" data-xwiki-image-style-alignment="end" height="136" width="309"]]
++
  {{toc/}}
  = Ein kurzer Überblick =
@@ -95,14 +95,15 @@
  == 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.
++Nachdem die Produktvision definiert wurde, wird das Product Backlog (in GitLab: [[Product-Backlog>>doc:Main.GitLab.WebHome||anchor="HProduct-Backlog"]]) erstellt und vom Product Owner //(hier: gesamtes Team im Softwareprojekt)// verwaltet. Aus dem Sprint Planning resultiert das Sprint Backlog (in Gitlab: [[Sprint-Backlog>>doc:Main.GitLab.WebHome||anchor="HSprint-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.
++Ein Product Backlog (in GitLab: [[Product-Backlog>>doc:Main.GitLab.WebHome||anchor="HProduct-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** ===
++In Gitlab: [[Pflege und Priorisierung>>doc:Main.GitLab.WebHome||anchor="HPflege2FPriorisierungdesProduct-Backlogs"]]
  Priorisiert:
  * Um die für das Projekt wertvollsten Stories am Anfang zu bearbeiten
@@ -133,7 +133,7 @@
  ✓ 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
++✓ Sprint starten (in GitLab: [[Erstellung eines Sprints in GitLab>>doc:Main.GitLab.WebHome||anchor="HErstellungeinesSprints"]])
  === **Die dazugehörigen Elemente eines Sprint Plannings** ===
@@ -144,7 +144,7 @@
  == 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".
++Es sollte aus mehreren Gründen geschätzt werden (in GitLab: [[Schätzung>>doc:Main.GitLab.WebHome||anchor="HSchE4tzungen"]]). 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". Die Schätzung kann bspw. auf der Seite: [[https:~~/~~/www.scrumpoker-online.org/en/>>url:https://www.scrumpoker-online.org/en/]] durchgeführt werden.
  === **Ablauf der Aufwandsschätzung (Checkliste)** ===
@@ -244,76 +244,35 @@
  == 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:
++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.
--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.
++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)//.
++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:
++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.
++**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.
++**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.
++**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.
++**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.
++**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.
++**Testable** Eine testbare User Story hat gut strukturierte Akzeptanzkriterien, die getestet werden können.
  === Ausreichend beschriebene User Story mit dem INVEST-Prinzip ===
@@ -335,12 +335,4 @@
  zu finden.
--Ich würde mich über einen kurzen Hinweis darüber, dass die Materialien woanders verwendet worden sind, freuen. Änderungsvorschläge gerne per PR im Git-Projekt (Zugangsdaten können ggf. bei mir angefordert werden).
--
--Anforderungen - Gruppensitzungen: [[Anforderungen Gruppensitzungen>>doc:.Anforderungen-an-die-Gruppe.WebHome||anchor="HAnforderungenGruppensitzungen"]]
--Anforderungen - Gruppensitzungen: [[Anforderungen Gruppensitzungen>>doc:.AnforderungenGruppen.WebHome||anchor="HAnforderungenGruppensitzungen"]]
--
--
--Siehe [[AnforderungenGruppensitzungen>>doc:.Anforderungen%20an%20die%20Gruppe.WebHome||anchor="HAnforderungenGruppensitzungen"]]
--
--Siehe [[AnforderungenGruppensitzungen>>doc:.AnforderungenGruppen.WebHome||anchor="HAnforderungenGruppensitzungen"]]
++Ich würde mich über einen kurzen Hinweis darüber, dass die Materialien woanders verwendet worden sind, freuen. Änderungsvorschläge gerne per PR im Git-Projekt (Zugangsdaten können ggf. bei [[Marco Grawunder>>https://uol.de/marco-grawunder]] angefordert werden).

Changes for page Scrum

Summary

Details

Applications

Navigation