Product Backlog: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
| Zeile 4: | Zeile 4: | ||
Das [[Product Backlog]] umfasst 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 [[Kollision|Kollisionsabfragen]] zu beschleunigen") oder bekannte Fehler ("Fehler in der Wegpunkt-Befahrung der [[KI]] diagnostizieren und beheben"). | Das [[Product Backlog]] umfasst 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 [[Kollision|Kollisionsabfragen]] zu beschleunigen") oder bekannte Fehler ("Fehler in der Wegpunkt-Befahrung der [[KI]] diagnostizieren und beheben"). | ||
[[Item]]s sollten strukturiert verfasst werden, z.B. als [[User Story|User Stories]] kombiniert mit Anwendungsfällen: prägnante, klare Beschreibung der Funktionalitäten aus der Sicht des Endbenutzers. | [[Item]]s sollten strukturiert verfasst werden, z.B. als [[User Story|User Stories]] kombiniert mit Anwendungsfällen<ref>[http://de.wikipedia.org/wiki/Anwendungsfall Anwendungsfall bei Wikipedia]</ref>: prägnante, klare Beschreibung der Funktionalitäten aus der Sicht des Endbenutzers. | ||
Das [[Product Backlog]] wird kontinuierlich geupdated um Änderungen in den Anforderungen, neue Ideen oder Erkenntnisse, technische Hürden etc. zu erfassen. | Das [[Product Backlog]] wird kontinuierlich geupdated um Änderungen in den Anforderungen, neue Ideen oder Erkenntnisse, technische Hürden etc. zu erfassen. | ||
Version vom 23. Mai 2011, 11:11 Uhr
Der erste Schritt in Scrum ist das Festhalten der Produktfeatures. Dies geschieht in Form einer priorisierten Liste von Anforderungen (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 jemals machen könnte bzw. sollte.
Das Product Backlog umfasst 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 strukturiert verfasst werden, z.B. als User Stories kombiniert mit Anwendungsfällen[1]: prägnante, klare Beschreibung der Funktionalitäten aus der Sicht des Endbenutzers. Das Product Backlog wird kontinuierlich geupdated 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.