Ich habe einen andauernden Streit – unser Delivery Manager hat versucht, ein „Release nach 3 Sprints“-Muster in unsere Teams einzuführen. Leider kann die tatsächliche Arbeit, wie in vielen Unternehmen, x Sprints betragen, oft mehr als 3.
Ich behaupte, nur weil der Umfang im Voraus festgelegt ist, ist das nur unser DoD. Wir veröffentlichen zu Live, wenn wir den Umfang abgeschlossen haben und fertig sind. Nichts darin verstößt gegen agile Prinzipien – wir erkennen nur an, dass wir, obwohl wir theoretisch am Ende eines bestimmten Sprints veröffentlichen könnten , dies in Wirklichkeit nie tun würden, bis wir fertig sind und dann einen echten Veröffentlichungskandidaten haben.
Er argumentiert, dass Agilität nur agil sein kann, wenn man einen Sprint nach dem anderen arbeitet und für jeden Sprint einen Release Candidate hat.
Welche Version ist richtig, oder haben wir beide recht/falsch?
Wenn Sie in jedem agilen Framework basierend auf einem festen Umfang schätzen möchten, werden Ihre geschätzten Veröffentlichungsdaten variieren. Wenn Sie sich stattdessen für ein festes Veröffentlichungsdatum oder einen routinemäßigen Veröffentlichungsrhythmus entscheiden, variiert der Umfang. Beides sind legitime Optionen, aber in diesem Fall hat Ihr Delivery Manager mehr Recht als Sie.
Ihr Delivery Manager hat meistens recht. Unabhängig davon, ob Sie Scrum oder einem anderen Framework folgen, das zufällig den Begriff „Sprint“ verwendet, sollte eine agile Iteration immer zu einem potenziell veröffentlichungsfähigen Produkt führen. Gerade Scrum macht sehr deutlich, dass jedes Inkrement lösbar sein muss :
Am Ende eines Sprints muss das neue Inkrement „Done“ sein, d. h. es muss sich in einem brauchbaren Zustand befinden und der Definition von „Done“ des Scrum-Teams entsprechen … Das Inkrement muss sich in einem brauchbaren Zustand befinden, unabhängig davon, ob der Product Owner beschließt, es freizugeben.
Während die meisten agilen Frameworks keine feste Release-Kadenz definieren, verbieten sie diese auch nicht. Da jeder Sprint zu einem potenziell auslieferbaren Inkrement führt, gibt es keinen Grund , nicht eine dreimonatige Release-Kadenz für das Projekt anzustreben, wenn dies einen geschäftlichen Mehrwert bringt.
Es ist traditioneller, dass bei der agilen Release-Planung ein Release-Datum basierend auf der Anzahl der Iterationen geschätzt wird, die wahrscheinlich erforderlich sind, um einen bestimmten Satz von Funktionen fertigzustellen. Lean Flow, DevOps-Kultur und eine Branchenverlagerung hin zu Continuous Delivery und Continuous Deployment haben jedoch dazu geführt, dass sich einige Projekte in Richtung einer routinemäßigen Release-Kadenz bewegen, wie sie Ihr Delivery Manager wünscht.
Als ein Beispiel hat Ubuntu einen zweijährlichen Veröffentlichungsrhythmus für Langzeit-Support-Releases und einen sechsmonatigen Rhythmus für Interim-Releases. Im Gegensatz dazu folgt der Debian-Veröffentlichungszyklus einem traditionelleren Modell, das nicht von Natur aus zeitlich festgelegt ist.
Ein zuverlässiger Rhythmus ist im Allgemeinen eine gute Sache in einem Projektmanagement-Framework. Allerdings sind ein iterativer Lieferrhythmus und ein Produktfreigaberhythmus eigentlich zwei verschiedene Dinge. Ob Veröffentlichungen einem Rhythmus folgen sollten oder nicht, ist eine produktspezifische Geschäftsentscheidung, und es gibt keine allgemeingültige Antwort auf diese Frage.
Releases sind ein enorm wichtiger Aspekt von Agile. Es gibt viele Gründe für ihre Bedeutung, darunter:
Aus diesem Grund betonen agile Frameworks wie Scrum die Notwendigkeit, am Ende jedes Sprints ein potenziell auslieferbares Inkrement zu haben.
Es mag verlockend sein zu sagen, dass Sie das Produkt erst veröffentlichen möchten, wenn die abgeschlossene Entwicklungsarbeit aus Sicht des Produktmarketings funktionsreich und „vollständig“ ist. Damit fehlen allerdings zwei der drei oben genannten Punkte. Wenn Sie mit der Veröffentlichung warten, bis das Produkt funktionsreich ist, verzögern Sie den Abbau der Ungewissheit der Veröffentlichung und lassen Ihre Entwickler dazu übergehen, Arbeiten zu verzögern, die nur für eine Veröffentlichung wichtig sind.
Es ist erwähnenswert, dass viele agile Organisationen häufig neue Versionen veröffentlichen, ihre Änderungen jedoch nicht sofort den Benutzern zur Verfügung stellen. Beispielsweise verwenden einige Teams Feature Toggles . Dies bietet das Beste aus beiden Welten, Sie profitieren von häufigen Releases, können aber auch Ihr Unternehmen und Ihre Marketingmitarbeiter steuern lassen, wie und wann Funktionen für die Benutzer verfügbar werden.
Todd A. Jacobs