Skip to Content

Changes for page Scrum

Last modified by pmeyer on 2025/09/12 04:57
From version arrow_back 7.1 arrow_forward
edited by Pascal Meyer
on 2025/07/29 03:54
Change comment: There is no comment for this version
To version arrow_back 13.1 arrow_forward
edited by Pascal Meyer
on 2025/07/30 18:03
Change comment: There is no comment for this version

Summary

Details

insert_drive_file Page properties
Content
... ... @@ -1,5 +1,7 @@
1 -= Scrum - Ein kurzer Überblick =
1 +{{toc/}}
2 2  
3 += Ein kurzer Überblick =
4 +
3 3  **Was ist Scrum und warum brauchen wir das im SWP?**
4 4  
5 5  * Scrum ist einer von mehreren agilen Projektmanagement-Ansätzen und insbesondere für die Softwareentwicklung geeignet
... ... @@ -58,7 +58,7 @@
58 58  *** Das Team präsentiert, was es während eines Sprints erreicht hat
59 59  *** Typischerweise in Form einer Demo mit neuen Features oder der zugrunde liegenden Architektur
60 60  *** Das ganze Team nimmt teil!
61 -** **Sprint Retrospektive​​​​​​​**
63 +** **Sprint Retrospektive**
62 62  *** Regelmäßig prüfen, was gut und was nicht so gut funktioniert
63 63  *** ca. 15-30 min lang
64 64  *** Nach jedem Sprint
... ... @@ -65,7 +65,7 @@
65 65  *** Das gesamte Team kommt zusammen und diskutiert, wie es sich verbessern möchte
66 66  *** Methode hierfür bspw: Starfish (siehe Bild)
67 67  *** Weitere Methoden für die Retrospektiven finden sich z.B. hier: [[https:~~/~~/retromat.org/>>url:https://retromat.org/]]
68 -** **Tägliches Scrum-Meeting (Daily)​​​​​​​​​**
70 +** **Tägliches Scrum-Meeting (Daily)​​**
69 69  *** Wöchentliches Treffen startet mit Scrum-Meeting
70 70  *** Am Ende der Sitzung Verteilung neuer Aufgaben (jeder hat mindestens ein Ticket)
71 71  *** Im Weekly werden keine Lösungen diskutiert, dies kann im weiteren Verlauf der Sitzung passieren
... ... @@ -89,7 +89,7 @@
89 89  
90 90  **[[image:Scrum-Prozess.JPG]]**
91 91  
92 -= Scrum - im Detail =
94 += Im Detail =
93 93  
94 94  == Scrum-Prozess ==
95 95  
... ... @@ -236,8 +236,106 @@
236 236  
237 237  [[image:Unbenannt2.JPG]]
238 238  
239 -
240 240  
241 -
242 242  
243 -
243 += User Stories =
244 +
245 +== Was sind User Stories? ==
246 +
247 +Ein Werkzeug, das häufig im agilen Projektmanagement eingesetzt wird, sind User
248 +Stories. Eine User Story ist eine Beschreibung einer Anforderung an ein Softwareprodukt.
249 +Sie ist aus der Sicht eines Nutzers //(hier: Spielteilnehmer)// formuliert. Außerdem
250 +wird in einer User Story immer ein Mehrwert und eine Bedeutung für den Nutzer
251 +erwähnt, welchen dieser durch die Funktionalität hat. Diese Funktionalität wird in
252 +das zu erstellende Produkt implementiert und erhöht somit den Wert des Produkts.
253 +Eine User Story liefert also immer einen Mehrwert. Der Titel der User Story beschreibt
254 +knapp die Hauptaussage der gesamten Story, welche immer das Ziel des Nutzers ist. In
255 +den meisten Fällen wird eine User Story in der folgenden Form geschrieben:
256 +
257 +
258 +"Als [Rolle] möchte ich [Tätigkeit], um [Nutzen]."
259 +
260 +
261 +Im Rahmen des Softwareprojekts könnte eine User Story beispielsweise wie folgt aussehen:
262 +//"Als Nutzer dieses Systems möchte ich mich einloggen können, um ein Spiel zu//
263 +//starten."// Die explizite Erwähnung der [Rolle] ist wichtig, weil der Anwendungsfall von
264 +Rolle zu Rolle variieren kann. Die [Tätigkeit] ist der Vorgang, welchen die Rolle bei
265 +Nutzung des vom Team zu implementierenden Produkts ausführt. Der [Nutzen] dient
266 +zur Einordnung der Wichtigkeit und hilft, eine Priorisierung der zu implementierenden
267 +Features vorzunehmen. Außerdem hilft es dem Team zu verstehen, warum sie dieses
268 +Feature implementieren sollen.
269 +
270 +== Mehrwert von User Stories ==
271 +
272 +Da User Stories so formuliert werden sollten, dass sie jeder versteht, kann eine intensive
273 +Zusammenarbeit mit dem Auftraggeber //(hier: intensive Zusammenarbeit mit dem//
274 +//gesamten Team)// entstehen. Hierdurch wird die Beziehung untereinander gestärkt und
275 +sowohl Entwickler als auch Auftraggeber verstehen die Ziele der User Stories gleicherma-
276 +ßen. Ein weiterer Vorteil ist die Anpassbarkeit, weil sich die Wünsche des Auftraggebers
277 +jederzeit ändern können. Aus diesem Grund implementieren die Entwickler im schlimmsten
278 +Fall nur für eine sehr kurze Zeit etwas, was in der nächsten Iteration hinfällig ist,
279 +da sich der Wunsch des Auftraggebers jederzeit ändern kann. Außerdem werden nur
280 +die Stories detaillierter beschrieben, die in der Iteration erledigt werden sollen. So wird
281 +keine Zeit für die Planung von etwas aufgewendet, das sich im Nachhinein eventuell als
282 +obsolet herausstellt.
283 +
284 +== Der Nutzen von Akzeptanzkriterien ==
285 +
286 +Da die Entwickler eventuell unterschiedliche Vorstellungen davon haben, wann eine
287 +bestimmte User Story fertig bearbeitet ist, hat sie bestimmte Akzeptanzkriterien. Diese
288 +bestimmen die Vollständigkeit der in der Story gewünschten Funktion. Sobald diese
289 +Akzeptanzkriterien erfüllt sind, ist die User Story vollständig umgesetzt und liefert nur
290 +dann den gewünschten Mehrwert für den Auftraggeber //(hier: für das Team)//.
291 +
292 +== INVEST-Prinzip ==
293 +
294 +Es gibt bestimmte Eigenschaften, die eine gute User Story ausmachen. Mit dem INVEST-
295 +Prinzip lassen sich diese Eigenschaften beschreiben. Dabei ist das Wort INVEST ein
296 +Akronym für die folgenden Eigenschaften einer guten User Story:
297 +
298 +**Independent** Diese Eigenschaft meint, dass eine gute User Story unabhängig von
299 +anderen ist. Sind Stories voneinander abhängig, können Probleme entstehen, die eine
300 +Priorisierung erschweren.
301 +
302 +**Negotiable** Verhandelbare User Stories bedeuten, dass während des Entwicklungsprozesses
303 +bestimmte Akzeptanzkriterien angepasst werden können, wenn diese mit dem
304 +Auftraggeber //(hier: mit dem gesamten Team)// verhandelt wurden.
305 +
306 +**Valuable** Wertvolle User Stories meinen, dass sie einen bestimmten Mehrwert für
307 +den Auftraggeber und den Nutzer darstellen.
308 +
309 +**Estimatable** Eine gute User Story soll schätzbar sein, das bedeutet, dass die Story
310 +von anderen abgegrenzt wird, sodass sie gut unterscheidbar ist.
311 +
312 +**Small** Damit eine User Story gut schätzbar ist, muss sie klein sein. Außerdem können
313 +zu große User Stories nicht in einem Sprint bearbeitet werden.
314 +
315 +**Testable** Eine testbare User Story hat gut strukturierte Akzeptanzkriterien, die
316 +getestet werden können.
317 +
318 +=== Ausreichend beschriebene User Story mit dem INVEST-Prinzip ===
319 +
320 +[[image:Unbenannt.JPG]]
321 +
322 +=== Unzureichend beschriebene User Story mit dem INVEST-Prinzip ===
323 +
324 +[[image:Unbenannt1.JPG]]
325 +
326 += Scrum Workshop =
327 +
328 +Im Winter 2020/21 wurde zum ersten Mal mit den Scrum-Mastern ein Scrum Workshop durchgeführt. Die dort verwendeten Materialen sind unter dem folgenden Link zu finden:
329 +
330 +[[https:~~/~~/cloud.uni-oldenburg.de/s/XKi2PiW4H5yazzW>>url:https://cloud.uni-oldenburg.de/s/XKi2PiW4H5yazzW]]
331 +
332 +Die Quelldateien sind unter
333 +
334 +[[https:~~/~~/git.swl.informatik.uni-oldenburg.de/projects/SPB/repos/scrumworkshop/browse>>url:https://git.swl.informatik.uni-oldenburg.de/projects/SPB/repos/scrumworkshop/browse]]
335 +
336 +zu finden.
337 +
338 +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).
339 +
340 +
341 +Anforderungen - Gruppensitzungen: [[Anforderungen Gruppensitzungen>>doc:.Anforderungen-an-die-Gruppe.WebHome||anchor="HAnforderungen:Gruppensitzungen"]]
342 +
343 +Anforderungen - Gruppensitzungen: [[Anforderungen Gruppensitzungen>>doc:.Anforderungen%20an%20die%20Gruppe.WebHome||anchor="HAnforderungen:Gruppensitzungen"]]
attach_file Unbenannt.JPG
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.PascalMeyer
Size
... ... @@ -1,0 +1,1 @@
1 +178.6 KB
Content info
attach_file Unbenannt1.JPG
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.PascalMeyer
Size
... ... @@ -1,0 +1,1 @@
1 +163.8 KB
Content info