a
HomeAgile VorgehensweisenWie funktioniert agile Release-Planung?

Wie funktioniert agile Release-Planung?

Die Release-Planung wird benötigt, um die Auslieferung zum Kunden und dessen IT-Infrastruktur gezielt zu planen. Insbesondere da Anwendungen häufig über technische Schnittstellen mit anderen Anwendungen in der Anwendungslandschaft integriert werden müssen, muss dieser Schritt sorgfältig geplant und durchgeführt werden.

Die Frequenz einzelner Releases, also die Anzahl von Releases pro Zeit, ist in der Regel abhängig von der Organisation, der Art der Anwendung und der Projektgröße. Relativ kleine Anwendungen, die nicht über technische Schnittstellen verzahnt sind, können in der Regel häufiger ausgeliefert werden als große Anwendungen mit vielen technischen Abhängigkeiten und vielen unterschiedlichen Nutzergruppen. Anwendungen die sich in der strategischen Entwicklung befinden und die dazu dienen, einen Geschäftsbereich neu aufzubauen, werden in der Regel anders geplant als die Pflege und Weiterentwicklung von ausgereiften und stabilen Anwendungen im Umfeld von Unterstützungsprozessen.

Bei der Steuerung von Release-Zyklen sind folgende Einstellgrößen zu planen:

  • Dauer eines Sprints: Kleinste Planungseinheit eines Teams und Dauer der ungestörten Arbeit einzelner Teams, typisch sind Zeitfenster von 2–4 Wochen.
  • Anzahl der Zyklen pro Release: Wie häufig werden die Ergebnisse einzelner Teams in eine auslieferbare Anwendung integriert?
  • Anzahl der geplanten Releases: Das ist die Häufigkeit der Auslieferung fertiger Ergebnisse an den Kunden.

Über die genannten Einstellgrößen bei der Release-Planung wird die Batch-Größe eines Zyklus und damit auch die Feedback-Frequenz gesteuert. Kurze Sprints von ein bis zwei Wochen haben eine kleinere Batch-Größe als vierwöchige Sprints und zudem eine höhere Feedback-Frequenz. Häufige Releases erfordern häufige Integration, liefern jedoch auch ein schnelleres Feedback über den tatsächlichen Zustand des Gesamtprodukts im Vergleich zu wenigen Releases.

Typische Einflussgrößen auf den Rhythmus von Releases sind:

  • Prozessreife der Organisation / des Unternehmens
  • Marktumfeld
  • Anforderungen der Kunden
  • Abhängigkeiten zu externen Systemen
  • Einfluss auf die Arbeitsabläufe und Geschäftsprozesse
  • Verfügbarkeit von Ressourcen.

Selbst wenn die Entwicklungsabteilung zügig neue Releases bereitstellen kann, muss der IT-Betrieb deren Deployment und Integration durchführen, eventuell müssen Anwender geschult werden usw. usf.

Wenn beispielsweise ein Release aus 4 + 1 Sprints besteht, wird es nach den Regeln von Scrum 4 Sprints geben, die jeweils alle ihren eigenen Sprint-Backlog Katalog besitzen. Der letzte Sprint, ich nenne ihn auch gerne „Open Week“ dient als Puffer für das Team. Es kann von Teammitgliedern dazu genutzt werden, liegengebliebene Arbeit zu erledigen oder sich mit anderen Themen zu beschäftigen, die für das Unternehmen vielleicht später interessant werden könnten. Dazu gehören vielleicht auch Weiterbildungen oder andere Events.

Teile bitte diesen Inhalt mit:
Bewerte bitte den Inhalt
Keine Kommentare.

Hinterlasse doch ein Kommentar

* Die Checkbox für die Zustimmung zur Speicherung ist nach DSGVO zwingend.

Ich stimme zu.