Skip to Content

Changes for page Scrum

Last modified by pmeyer on 2025/09/12 04:57
From version arrow_back 27.3 arrow_forward
edited by pmeyer
on 2025/09/12 04:47
Change comment: There is no comment for this version
To version arrow_back 23.1 arrow_forward
edited by Pascal Meyer
on 2025/08/15 00:09
Change comment: There is no comment for this version

Summary

Details

insert_drive_file Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.pmeyer
1 +XWiki.PascalMeyer
Content
... ... @@ -1,5 +3,3 @@
1 -[[image:Main.Organisatorisches.WebHome@softwareprojekt_logo_transparent.png||alt="SoftwareprojektLogo.png" data-xwiki-image-style-alignment="end" height="136" width="309"]]
2 -
3 3  {{toc/}}
4 4  
5 5  = Ein kurzer Überblick =
... ... @@ -97,15 +97,14 @@
97 97  
98 98  == Scrum-Prozess ==
99 99  
100 -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.
98 +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.
101 101  
102 102  == Product Backlog ==
103 103  
104 -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.
102 +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.
105 105  
106 106  === **Der Nutzen eines gepflegten/priorisierten Product Backlogs** ===
107 107  
108 -In Gitlab: [[Pflege und Priorisierung>>doc:Main.GitLab.WebHome||anchor="HPflege2FPriorisierungdesProduct-Backlogs"]]
109 109  Priorisiert:
110 110  
111 111  * Um die für das Projekt wertvollsten Stories am Anfang zu bearbeiten
... ... @@ -136,7 +136,7 @@
136 136  ✓ Die gleiche Anzahl an Story Points in das Sprint Backlog ziehen
137 137  ✓ User Stories in Tasks aufsplitten
138 138  ✓ Alle Teammitglieder suchen sich Aufgaben aus, die sie bearbeiten möchten
139 -✓ Sprint starten (in GitLab: [[Erstellung eines Sprints in GitLab>>doc:Main.GitLab.WebHome||anchor="HErstellungeinesSprints"]])
136 +✓ Sprint starten
140 140  
141 141  === **Die dazugehörigen Elemente eines Sprint Plannings** ===
142 142  
... ... @@ -147,7 +147,7 @@
147 147  
148 148  == Schätzen von Aufwänden ==
149 149  
150 -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.
147 +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". Die Schätzung kann bspw. auf der Seite: [[https:~~/~~/www.scrumpoker-online.org/en/>>url:https://www.scrumpoker-online.org/en/]] durchgeführt werden.
151 151  
152 152  === **Ablauf der Aufwandsschätzung (Checkliste)** ===
153 153  
... ... @@ -241,15 +241,8 @@
241 241  
242 242  [[image:Unbenannt2.JPG]]
243 243  
244 -=== Hilfreiche Tools für die Durchführung einer Sprint Retrospektive ===
245 245  
246 -[[Retrotool.io>>https://retrotool.io/]]
247 247  
248 -* Auf der
249 -
250 -
251 -
252 -
253 253  = User Stories =
254 254  
255 255  == Was sind User Stories? ==
... ... @@ -304,4 +304,4 @@
304 304  
305 305  zu finden.
306 306  
307 -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).
297 +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).