Wer führt eine Freigabe durch und wie wird sie geschätzt?

1. Es ist die Aufgabe des Entwicklerteams.
2. nicht separat geschätzt, da es sich um eine Aufgabe handelt, die bei der Schätzung der Geschichte berücksichtigt wird
3. Das Team kann eine separate Aufgabe im Backlog erstellen, wenn das Team der Meinung ist, dass es ihnen hilft. 4. Die Geschichte ist noch nicht fertig

wer führt die Freigabe durch?

Normalerweise der Release Engineer. Andernfalls würde es von den Kompetenzen abhängen, die für die Freigabe erforderlich sind. Sie werden feststellen, dass dies ein QA-Ingenieur tun könnte, oder vielleicht ein Entwickler, ein technischer Leiter ...

Wie wird das normalerweise geschätzt?

Meiner Meinung nach muss man das nicht schätzen. Da dies eine wiederkehrende Aufgabe in jedem Sprint ist, mit ungefähr der gleichen Art von Problemen entlang der verschiedenen Sprints, ist sie bereits in Ihrer Sprintgeschwindigkeit enthalten

Gibt es dafür eine eigene Aufgabe?

Dies ist eine separate Aufgabe für den Macher, aber da es sich um eine sich wiederholende Aufgabe handelt, muss sie nicht in das Sprint-Backlog aufgenommen werden

Was passiert, wenn es so langsam geht, dass es sich in den nächsten Sprint überschneidet?

Dasselbe wie das, was kommt, wenn eine User Story schlecht eingeschätzt wird. Sie würden über die Probleme in der Retrospektive diskutieren und gemeinsam Lösungsmöglichkeiten für das nächste Mal finden

Normalerweise organisiert sich ein Team selbst, um herauszufinden, wer die Freigabe machen soll. In einigen Teams gibt es Teammitglieder, die sich auf Releases spezialisiert haben. Andere Teams teilen sich die Verantwortung.

Normalerweise würde ich nicht erwarten, dass ein Team eine separate Schätzung für eine Veröffentlichung vornimmt. Denn in Scrum beinhaltet die Definition of Done oft auch die Freigabe. Das bedeutet, dass die Zeit, die für die Veröffentlichung benötigt wird, in die Schätzungen für einzelne Geschichten eingerechnet werden sollte.

Es ist durchaus üblich, eine Aufgabe zu haben, die die Veröffentlichung verfolgt. Dies hängt jedoch stark vom Aufwand ab, der für die Freigabe erforderlich ist. Einige Teams haben einen sehr raffinierten Release-Mechanismus und halten es daher nicht für erforderlich, Releases als separate Aufgaben zu verfolgen.

Wie Sie zu Recht anmerken, besteht die Gefahr, dass sich die Veröffentlichung aus irgendeinem Grund verzögert. Wenn dies passiert, kann es sehr störend sein, sowohl für die Planung des nächsten Sprints als auch für das Geschäft im Allgemeinen. Noch einmal: Wenn die Definition von erledigt für Stories das Release beinhaltet, dann sollte sich das Versäumnis, innerhalb des Sprints zu releasen, auf die Geschwindigkeit des Teams auswirken.

Ich habe viele Ansätze zur Veröffentlichung von Strategien gesehen. Einige Teams veröffentlichen am letzten Tag des Sprints. Andere Teams veröffentlichen ein oder zwei Tage vor dem Ende des Sprints. Es ist auch nicht ungewöhnlich, dass ein Team eine gestaffelte Freigabe hat, sodass die Arbeit für jeden Sprint im darauffolgenden Sprint freigegeben wird.

Was dies unterstreicht, ist die Bedeutung eines schnellen und einfachen Auslösemechanismus. Die Automatisierung von Releases kann für ein Team von großem Nutzen sein. Dies liegt daran, dass es die Zeit, die das Team mit der Veröffentlichung verbringt, verkürzt und das Risiko einer Unterbrechung aufgrund von Veröffentlichungsproblemen verringert.

Es lohnt sich, einen Business Case für die Automatisierung Ihrer Releases zu erstellen. Angenommen, Sie können durch die Automatisierung Ihrer Releases 5-6 Stunden Aufwand pro Sprint einsparen. Über 10 Sprints, die 50-60 Stunden Aufwand einsparen und auch das Risiko einer Störung deutlich reduzieren würden. Wenn das Team 40 Stunden Aufwand für die Automatisierung des Freigabeprozesses aufwenden müsste, würde sich dies in 10 Sprints oder weniger amortisieren.