Product Backlog: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
K Änderungen von Langenfeld (Diskussion) wurden auf die letzte Version von Dietsch zurückgesetzt Markierung: Zurücksetzung |
||
| (8 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
Der erste Schritt in [[Scrum]] ist das Festhalten der Produktfeatures. Dies geschieht anfangs in Form einer priorisierten Liste von Anforderungen ([[Item|Items]]), die im Softwarepraktikum aus dem [[GDD]] extrahiert werden können. Diese Liste ist das [[Product Backlog]], welches über die gesamte Projektzeit existiert und sich auch im Projektverlauf noch iterativ weiterentwickeln kann. Das [[Product Backlog]] hält, in priorisierter Reihenfolge, alles fest, was das Team machen sollte. Im Verlauf der Entwicklung sollten die einzelnen [[Item]]s nach und nach (d.h. im Verlauf eines [[Sprint]]s) verfeinert werden, wodurch sich aus den anfänglichen Anforderungen konkretere Beschreibungen bis hin zu Spezifikationen entwickeln. Das [[Product Backlog]] umfasst in seinem Endzustand alle Inhalte des Produkts, z.B. Features ("der Spieler kann ein Auto steuern"), Entwicklungsanforderungen ("[[Menü|Menüs]] überarbeiten um sie flexibler zu gestalten"), Untersuchungen ("Konzepte untersuchen um die Kollisionsabfragen zu beschleunigen") oder bekannte Fehler ("Fehler in der Wegpunkt-Befahrung der [[KI]] diagnostizieren und beheben"). | |||
Der erste Schritt in [[Scrum]] ist das Festhalten der Produktfeatures. Dies geschieht anfangs in Form einer priorisierten Liste von Anforderungen ([[Item|Items]]). Diese Liste ist das [[Product Backlog]], welches über die gesamte Projektzeit existiert und sich auch im Projektverlauf noch iterativ weiterentwickeln kann. Das [[Product Backlog]] hält, in priorisierter Reihenfolge, alles fest, was das Team machen sollte. Im Verlauf der Entwicklung sollten die einzelnen [[Item]]s nach und nach (d.h. im Verlauf eines [[Sprint]]s) verfeinert werden, wodurch sich aus den anfänglichen Anforderungen konkretere Beschreibungen bis hin zu Spezifikationen entwickeln. | |||
[[Item]]s sollten entsprechend ihrer aktuellen Abstraktion strukturiert verfasst werden. Das kann z.B. in Anlehnung an User Stories<ref>[http://de.wikipedia.org/wiki/User_Story User Story bei Wikipedia]</ref> oder Anwendungsfälle<ref>[http://de.wikipedia.org/wiki/Anwendungsfall Anwendungsfall bei Wikipedia]</ref> geschehen. Die Struktur sollte für Ihr Team und Ihr Produkt sinnvoll sein. Ihr Tutor bzw. die [[Sopra-Crew]] kann Sie dabei unterstützen. Mindestens jedoch sollte jedes [[Item]] eine Priorität besitzen. Das [[Product Backlog]] sollte kontinuierlich aktualisiert werden, um Änderungen in den Anforderungen, neue Ideen oder Erkenntnisse, technische Hürden etc. zu erfassen. | |||
[[Item]]s sollten entsprechend ihrer aktuellen Abstraktion strukturiert verfasst werden. Das kann z.B. in Anlehnung an User Stories<ref>[http://de.wikipedia.org/wiki/User_Story User Story bei Wikipedia]</ref> oder Anwendungsfälle<ref>[http://de.wikipedia.org/wiki/Anwendungsfall Anwendungsfall bei Wikipedia]</ref> geschehen. Mindestens jedoch sollte jedes [[Item]] eine Priorität besitzen. Das [[Product Backlog]] sollte kontinuierlich aktualisiert werden, um Änderungen in den Anforderungen, neue Ideen oder Erkenntnisse, technische Hürden etc. zu erfassen. | |||
Neben der Priorität wird jedes [[Item]] im [[Product Backlog]] mit einer groben Abschätzung des erforderlichen Aufwands versehen. Diese Werte können auch für die Priorisierung der einzelnen [[Item|Items]] hilfreich sein. Da die Abschätzungen relativ sind, könnten sie in einer beliebigen Einheit angegeben werden, anstatt "echte" Zeiten für Aufwand wie Personenstunden zu verwenden. Jedoch ist es meistens sinnvoll, konkrete Zeitangaben zu haben, da sich diese besser zur Verfeinerung der Selbsteinschätzung eignen. Wir empfehlen daher, [[ETC]] als Einheit zu verwenden. | Neben der Priorität wird jedes [[Item]] im [[Product Backlog]] mit einer groben Abschätzung des erforderlichen Aufwands versehen. Diese Werte können auch für die Priorisierung der einzelnen [[Item|Items]] hilfreich sein. Da die Abschätzungen relativ sind, könnten sie in einer beliebigen Einheit angegeben werden, anstatt "echte" Zeiten für Aufwand wie Personenstunden zu verwenden. Jedoch ist es meistens sinnvoll, konkrete Zeitangaben zu haben, da sich diese besser zur Verfeinerung der Selbsteinschätzung eignen. Wir empfehlen daher, [[ETC]] als Einheit zu verwenden. | ||
| Zeile 13: | Zeile 9: | ||
Die generelle Richtlinie besagt, dass man das was wichtig ist auf dem kleinsten Raum zusammenfassen soll der benötigt wird. In anderen Worten muss man nicht jedes mögliche Detail eines [[Item|Items]] beschreiben, sondern nur klar machen, was benötigt wird um das [[Item]] als abgeschlossen ansehen zu können. | Die generelle Richtlinie besagt, dass man das was wichtig ist auf dem kleinsten Raum zusammenfassen soll der benötigt wird. In anderen Worten muss man nicht jedes mögliche Detail eines [[Item|Items]] beschreiben, sondern nur klar machen, was benötigt wird um das [[Item]] als abgeschlossen ansehen zu können. | ||
Im Softwarepraktikum sollte das [[Product Backlog]] wie auch das [[Sprint Backlog]] im | Im Softwarepraktikum sollte das [[Product Backlog]] wie auch das [[Sprint Backlog]] im [[Gitea]] geführt werden (siehe auch [[Scrum und Gitea]]) | ||
<noinclude> | |||
== Referenzen und Quellen == | |||
<references/></noinclude> | <references/></noinclude> | ||
Aktuelle Version vom 19. Oktober 2021, 08:39 Uhr
Der erste Schritt in Scrum ist das Festhalten der Produktfeatures. Dies geschieht anfangs in Form einer priorisierten Liste von Anforderungen (Items), die im Softwarepraktikum aus dem GDD extrahiert werden können. Diese Liste ist das Product Backlog, welches über die gesamte Projektzeit existiert und sich auch im Projektverlauf noch iterativ weiterentwickeln kann. Das Product Backlog hält, in priorisierter Reihenfolge, alles fest, was das Team machen sollte. Im Verlauf der Entwicklung sollten die einzelnen Items nach und nach (d.h. im Verlauf eines Sprints) verfeinert werden, wodurch sich aus den anfänglichen Anforderungen konkretere Beschreibungen bis hin zu Spezifikationen entwickeln. Das Product Backlog umfasst in seinem Endzustand alle Inhalte des Produkts, z.B. Features ("der Spieler kann ein Auto steuern"), Entwicklungsanforderungen ("Menüs überarbeiten um sie flexibler zu gestalten"), Untersuchungen ("Konzepte untersuchen um die Kollisionsabfragen zu beschleunigen") oder bekannte Fehler ("Fehler in der Wegpunkt-Befahrung der KI diagnostizieren und beheben").
Items sollten entsprechend ihrer aktuellen Abstraktion strukturiert verfasst werden. Das kann z.B. in Anlehnung an User Stories[1] oder Anwendungsfälle[2] geschehen. Die Struktur sollte für Ihr Team und Ihr Produkt sinnvoll sein. Ihr Tutor bzw. die Sopra-Crew kann Sie dabei unterstützen. Mindestens jedoch sollte jedes Item eine Priorität besitzen. Das Product Backlog sollte kontinuierlich aktualisiert werden, um Änderungen in den Anforderungen, neue Ideen oder Erkenntnisse, technische Hürden etc. zu erfassen.
Neben der Priorität wird jedes Item im Product Backlog mit einer groben Abschätzung des erforderlichen Aufwands versehen. Diese Werte können auch für die Priorisierung der einzelnen Items hilfreich sein. Da die Abschätzungen relativ sind, könnten sie in einer beliebigen Einheit angegeben werden, anstatt "echte" Zeiten für Aufwand wie Personenstunden zu verwenden. Jedoch ist es meistens sinnvoll, konkrete Zeitangaben zu haben, da sich diese besser zur Verfeinerung der Selbsteinschätzung eignen. Wir empfehlen daher, ETC als Einheit zu verwenden.
Die Items im Product Backlog können, was ihre Komplexität angeht, stark variieren. Daher werden größere Items bei der Planung eines Sprints in kleinere Items unterteilt.
Die generelle Richtlinie besagt, dass man das was wichtig ist auf dem kleinsten Raum zusammenfassen soll der benötigt wird. In anderen Worten muss man nicht jedes mögliche Detail eines Items beschreiben, sondern nur klar machen, was benötigt wird um das Item als abgeschlossen ansehen zu können.
Im Softwarepraktikum sollte das Product Backlog wie auch das Sprint Backlog im Gitea geführt werden (siehe auch Scrum und Gitea)
