From version 17.1
edited by Pascal Meyer
on 2025/07/30 18:09
on 2025/07/30 18:09
Change comment:
There is no comment for this version
To version 22.1
edited by Pascal Meyer
on 2025/07/30 21:30
on 2025/07/30 21:30
Change comment:
There is no comment for this version
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -244,76 +244,35 @@ 244 244 245 245 == Was sind User Stories? == 246 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: 247 +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: 256 256 257 - 258 258 "Als [Rolle] möchte ich [Tätigkeit], um [Nutzen]." 259 259 251 +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. 260 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 270 == Mehrwert von User Stories == 271 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. 255 +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. 283 283 284 284 == Der Nutzen von Akzeptanzkriterien == 285 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)//. 259 +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)//. 291 291 292 292 == INVEST-Prinzip == 293 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: 263 +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: 297 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. 265 +**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. 301 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. 267 +**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. 305 305 306 -**Valuable** Wertvolle User Stories meinen, dass sie einen bestimmten Mehrwert für 307 -den Auftraggeber und den Nutzer darstellen. 269 +**Valuable** Wertvolle User Stories meinen, dass sie einen bestimmten Mehrwert für den Auftraggeber und den Nutzer darstellen. 308 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. 271 +**Estimatable** Eine gute User Story soll schätzbar sein, das bedeutet, dass die Story von anderen abgegrenzt wird, sodass sie gut unterscheidbar ist. 311 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. 273 +**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. 314 314 315 -**Testable** Eine testbare User Story hat gut strukturierte Akzeptanzkriterien, die 316 -getestet werden können. 275 +**Testable** Eine testbare User Story hat gut strukturierte Akzeptanzkriterien, die getestet werden können. 317 317 318 318 === Ausreichend beschriebene User Story mit dem INVEST-Prinzip === 319 319 ... ... @@ -336,11 +336,3 @@ 336 336 zu finden. 337 337 338 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 -Anforderungen - Gruppensitzungen: [[Anforderungen Gruppensitzungen>>doc:.Anforderungen-an-die-Gruppe.WebHome||anchor="HAnforderungenGruppensitzungen"]] 341 -Anforderungen - Gruppensitzungen: [[Anforderungen Gruppensitzungen>>doc:.AnforderungenGruppen.WebHome||anchor="HAnforderungenGruppensitzungen"]] 342 - 343 - 344 -[[Anforderungen Gruppensitzungen>>doc:.AnforderungenGruppen.WebHome||anchor="HAnforderungenGruppensitzungen"]] 345 - 346 -[[Anforderungen Gruppensitzungen>>doc:.A.WebHome||anchor="HAnforderungenGruppensitzungen"]]