Mir ist bekannt, dass die Länge eines Scrum Sprints von Fall zu Fall variieren kann. Dabei stellen sich folgende Fragen:
Typische Vorgehensweise
Scrum by-the-book geht davon aus, dass Sie am Ende der Iteration ein Release veröffentlichen und dann das Produkt einem Kunden vorführen. „Release“ und „Demo“ können natürlich je nach Produkt, das Sie erstellen, unterschiedliche Bedeutungen haben, z. B. eine Backoffice-App für große Unternehmen im Vergleich zu einer App, die sich direkt an Endbenutzer richtet.
Die meisten Scrum-Teams versuchen, am Ende der Timebox zu veröffentlichen, da es ihnen mehr Freiheit gibt, wie die Arbeit innerhalb der Iteration erledigt wird, z. B. können sie alles am Anfang eines Sprints beginnen und Stories erst beenden, wenn sich das Ende des Sprints nähert.
Häufige Veröffentlichungen
Wenn Sie jedoch häufiger veröffentlichen möchten, was ich persönlich ermutigen würde, können Sie dies tun, unabhängig davon, was die typische Praxis ist oder was Bücher sagen. Scrum ist wie jede andere Methode keine Religion und sollte nicht dogmatisch behandelt werden.
Möglicherweise möchten Sie (mehr) häufigere Veröffentlichungen einführen, da:
Übrigens gibt es Methoden, die Planungs-, Release- und Retrospektivzyklen entkoppeln. In diesem Fall sprechen wir von Trittfrequenz. Die Planungskadenz muss nicht dieselbe sein wie die Release-Kadenz oder die Retro-Kadenz. Es ist nur Scrum, das sie dazu gemacht hat. Lesen Sie hier mehr über Kadenz versus Iteration .
Im Allgemeinen wirkt sich der Wechsel zu häufigen Releases auf das Team aus, da sich die von Ihnen verwendeten Tools normalerweise weiterentwickeln müssen. Sie können ein paar Stunden damit verbringen, ein Produkt herauszubringen, wenn Sie es zweiwöchentlich tun. Wenn du es jeden Tag machst, kannst du es nicht. Das Gute ist, dass Sie diesen Übergang evolutionär gestalten können, indem Sie den Veröffentlichungszyklus Schritt für Schritt verkürzen, z. B. von zweiwöchentlich auf wöchentlich, und nach Schwachstellen suchen und diese angehen.
Scrum hatte ursprünglich nichts mit Releases zu tun, aber glücklicherweise wurde es geändert und es gibt eine Sache namens Release Planning . Während dieses Meetings sitzen das Scrum Team und der Product Owner zusammen und sehen, wann das Produkt freigegeben werden kann. Es ist ein hochrangiges Planungstreffen.
In Wirklichkeit werden die Freigaben von den Projekten und den Stakeholdern festgelegt. Das Scrum Team und der Product Owner nutzen dieses Meeting, um den Stakeholdern regelmäßig Feedback zum Release zu geben. Dieses Feedback sollte Informationen über die Risiken, den Umfang (Inhalt) und mögliche Hindernisse enthalten.
Die Häufigkeit dieses Treffens hängt von der Länge der Sprints und der Länge des ursprünglichen Projekts ab. Ich habe keine Angaben zur Häufigkeit finden können, aber ich würde sagen mindestens 3 Meetings während eines Projekts haben - gleichmäßig verteilt auf die Projektdauer.
Dies war der Fall, als die Freigabe an das Team gepusht wurde. Wenn das Team über die Releases entscheiden kann, würde ich mich auf die ursprüngliche Scrum-Idee beziehen, dass das Ergebnis eines Sprints etwas Lieferbares sein muss , daher findet das Release nach jedem Sprint-Review-Meeting statt .
Häufige Veröffentlichungen in einem großen Kontext haben einen enormen Overhead, aber das Feedback der Kunden/Benutzer/Stakeholder ist sehr wertvoll. Aus diesem Grund sollten Teams agil arbeiten: Sie erhalten häufig Feedback zu ihrer Arbeit, um sicherzustellen, dass sie auf dem richtigen Weg sind, und ohne häufige Releases ist dies kaum möglich.
Ich denke, sobald ein veröffentlichbares Paket fertig ist, kann es veröffentlicht werden. Aus diesem Grund habe ich darüber geschrieben, warum Sprints zeitlich begrenzt sein sollten und Fixes und Releases erfolgen können, wann immer ein veröffentlichungsfähiges Paket fertig ist. Sie können den Sprint-Prozess vom Release-Prozess entkoppeln:
Dank des fortschrittlichen CI und des Continuous-Delivery-Prozesses können wir sogar mehrmals am Tag veröffentlichen. Der Release-Prozess kann an den meisten Stellen fast unabhängig vom Sprint-Abschluss sein.
— Auszug aus Warum Timeboxed-Sprints? Was passiert mit Freigaben?
Die Häufigkeit von Releases in einem Sprint ist nicht definiert und kann je nach Bedarf des Projekts von der Umfangsdefinition eines Releases durch den Product Owner abweichen. Obwohl die Mehrheit der Teams es vorzieht, die Veröffentlichung am Ende der Iteration durchzuführen.
Ein weiterer wichtiger Aspekt eines Releases ist die Geschwindigkeit des Teams. Dieser Begriff wird in keiner der Antworten erwähnt. Velocity ist der Durchschnitt der Gesamtzahl der vom Scrum-Team abgeschlossenen Story Points Story Points. Dasselbe wird anhand der folgenden Punkte berechnet:
Die Rolle des Product Owners beinhaltet das Führen eines gut priorisierten und definierten Backlogs . Diese Storys des Backlogs mit hoher Priorität sollten auch Story Points haben. Basierend auf den Story Points, die der Product Owner vervollständigen und in ein Release aufnehmen möchte, und der Geschwindigkeit des Teams, könnte die Anzahl der Sprints berechnet werden, die für ein Release erforderlich sind.
Anzahl der für eine Veröffentlichung benötigten Sprints = Gesamtzahl der abzuschließenden Story Points / Geschwindigkeit des Teams
Dies wäre hilfreich, um ein Veröffentlichungsdatum zu erhalten. Somit erhält ein Product Owner die Option, das Veröffentlichungsdatum oder den Umfang der Veröffentlichung basierend auf der Velocity des Teams zu ändern. Dies könnte zu einem Release nach 5 Sprints von mehr als 5 Releases im Sprint führen.
Bei Scrum geht es um Timeboxing. Bei Continuous Delivery geht es um Rolling Releases und (bis zu einem gewissen Grad) um automatisierte Continuous Integration und Deployment. Sie sind nicht vollständig orthogonal, aber auch keine Synonyme.
Wenn Sie „echtes“ Scrum praktizieren, sollte ein Release mit einem auslieferbaren Inkrement am Ende einer Timebox zusammenfallen. Ich habe jedoch reale Beispiele gesehen, bei denen „Versand“ eine Story innerhalb eines Sprints war, wo die Versand-Story als Arbeit verfolgt wird und User-Storys hat, die über die Versand-Story hinaus im Sprint-Backlog fortgesetzt werden. Wenn dies zu Ihrem Arbeitsablauf passt, sollten Sie dies sicherlich in Betracht ziehen.
Alternativ kann jeder Sprint vom Product Owner abgebrochen werden, sodass es sogar innerhalb des traditionellen Scrum-Frameworks eine Methodik für den frühen Versand gibt. Die Idee ist, dass der Product Owner den Sprint jederzeit beenden und das Team an die Sprint-Planung zurückgeben kann. Dies verursacht Prozess-Overhead, kann aber in manchen Fällen sehr wohl gerechtfertigt sein.
Eine vorzeitige Beendigung des Sprints ist nicht automatisch etwas Negatives; Es ist einfach ein Management-Tool, das etwas Zykluszeit und Prozess-Overhead eintauscht, um auf sich ändernde Geschäftsanforderungen zu reagieren. Wenn das Sprint-Ziel für einen bestimmten Sprint „das Produkt ausliefern“ lautet, dann ist die vorzeitige Beendigung des Sprints nach einer erfolgreichen Produktauslieferung die Essenz von Agilität, da das Projekt nicht vor sich hin tuckert und unnötige Kosten verursacht die Organisation, sobald ihre Ziele erreicht sind.
Die Freigabe erfolgt auf zwei Ebenen – an den internen Stakeholder; an den externen Kunden. Für das Scrum-Team ist es erledigt, sobald es sich um Code handelt, entworfen, getestet, in Pre-Prod oder Prod bereitgestellt, Fehler behoben und die Benutzerakzeptanz erhalten wurde. Dies wird als minimal marktfähiges Feature bezeichnet. Der Kunde kann seine eigene Zeit für die Bereitstellung auf dem Live-Server wählen.
MCW
Hoss