Ich arbeite derzeit für ein Unternehmen, das Scrum eingeführt hat, und wir versuchen, eine Regel zu finden, wie wir den technischen Support, die Fehlerbehebung und die Unbekannten des Apple Appstore in unseren Sprints berücksichtigen können.
Im Wesentlichen frage ich mich, ob wir für jeden Sprint Zeit einplanen – sagen wir 20 % unserer Zeit – geht an die oben genannten Punkte.
Alle Vorschläge würden sehr helfen, da ich nicht viel Glück hatte, Ressourcen dafür online zu finden.
In Bezug auf Releases müssen Sie nicht nach jedem Sprint releasen. Der Output eines Sprints in Scrum ist ein potenziell auslieferbares Produkt. Das Schlüsselwort dort ist "potenziell". Jede abgeschlossene Story sollte der Definition of Done entsprechen (was alle damit verbundenen Aufgaben wie Dokumentationsaktualisierungen, Komponententests, Integrationstests, Abnahmetests usw. umfassen sollte). Wenn Sie sich entscheiden, Ihr potenziell lieferbares Produkt zu versenden, befindet sich dies außerhalb Ihres Scrum-Prozesses und jemand durchläuft einfach den Einreichungsprozess, wahrscheinlich nachdem die Sprint-Überprüfung abgeschlossen ist und vor der Sprint-Planung für den nächsten Sprint.
Fehler sollten als Geschichten behandelt werden. Die meisten Fehler sollten einfach in das Product Backlog aufgenommen und wie jede andere Anforderung oder User Story priorisiert werden. Möglicherweise haben Sie jedoch einen Fehler mit hoher Priorität. Wenn dies der Fall ist, kann sich der Product Owner dafür entscheiden, mit dem Team zusammenzuarbeiten, um zu entscheiden, wie er es in die Iteration einfügt. Dies kann beinhalten, dass eine User Story aus dem Sprint Backlog entfernt und durch die Story für den Fehler ersetzt wird.
Technischer Support kann, wenn er vom Entwicklungsteam geleistet wird, in der Sprint-Planungssitzung berücksichtigt werden. Wenn Sie Ihre Geschwindigkeit verwenden, um zu bestimmen, wie viele Story Points Sie in den Sprint einbringen möchten, passen Sie sie basierend auf einer Zuteilung der Zeit an, die Sie mit Support-Arbeiten verbringen. Wenn Sie in jedem Sprint konstant 20 % der Zeit Ihres Teams für den technischen Support aufwenden, dann würde Ihre Velocity dies widerspiegeln und Sie müssen überhaupt keine Anpassungen vornehmen.
Verwandte Fragen:
Ich glaube, die Links im Kommentar zu Ihren Fragen sind gültig und können für Ihre konkrete Situation nützlich sein. Vor allem, wenn es darum geht, Arbeit zu priorisieren und sichtbar zu machen.
Möglicherweise gibt es jedoch noch einen weiteren Punkt, den Sie sich ansehen möchten, Trunk-Flow. Es ist im Grunde der Fluss, den das Team verwendet, um seine Arbeit mit git/svn oder anderen Systemen zu versionieren. Trunk Flow besagt, dass alle Commits an den Trunk gehen und dass Releases aus dem Trunk herausgepickt werden und alle Fixes im Trunk erfolgen. Es bezieht sich auf die Veröffentlichungsbedingungen der AppStores in einer Weise, dass alle zwei Wochen eine Veröffentlichung vorbereitet werden könnte (so oft werden Apps normalerweise überprüft), und diese Veröffentlichung enthält all das, was bisher getan wurde.
Interessante Frage ist, was ist Ihre DoD? Wenn ein Feature im AppStore ist oder gerade zur Veröffentlichung bereit ist...
Todd A. Jacobs