Release Termine sind oft fest und werden von außen durch Messen, Buchhaltungsdruck oder vertragliche Verpflichtungen vorgegeben. Da das Ziel aber darin besteht, den Benutzern so schnell wie möglich funktionierende Software zur Verfügung zu stellen, um möglichst schnell „Kurskorrekturen“ vornehmen zu können, wird alles getan, um die Entwicklungszyklen für Releases so kurz wie möglich zu halten. Agile Release-Zyklen sollten auf jeden Fall kürzer als ein Jahr sein und sind oft nur sechs oder drei Monate lang. Ein Release besteht wiederum aus Iterationen. Für ein bestimmtes Projekt wird die Iterationslänge typischerweise auf einen Wert zwischen einer Woche und einem Monat festgelegt. Wenn das Release in sechs Monaten erscheint und die Iterationen jeweils zwei Wochen dauern, besteht das Release aus 13 Iterationen.
In manchen Umgebungen wird Software den Benutzern oder zumindest einer Teilmenge von Benutzern schrittweise am Ende jeder Iteration oder alle paar Iterationen bereitgestellt. Nachdem eine anfängliche Featureliste identifiziert, priorisiert und ggf. geschätzt wurde, hält das Team ein Release-Planungsmeeting ab, um den allgemeinen Release-Zeitplan festzulegen und zu bestimmen, welche Features wahrscheinlich bereitgestellt werden können. Der allgemeine Release-Plan in Bezug auf die priorisierten Features wird dann verwendet, um einzelne Iterationspläne direkt zu speisen.
Einige agile Methoden betonen eine klare Trennung der Verantwortlichkeiten zwischen Programmierern und Kunden. Während der Planung ist nur der Kunde für Geschäftsentscheidungen und Priorisierung verantwortlich und nur die Programmierer sind für die Aufgabenschätzung und die Entwicklungsausführung verantwortlich. Agile Methoden Halten Sie das Management außerdem dringend davon ab, der Entwicklungsgruppe willkürlich Technologieentscheidungen aufzuzwingen, und geben Sie den Entwicklern stattdessen so viel Spielraum wie möglich, um die besten Tools für das System und das Projekt auszuwählen.
Vorläufige Releaseplanung
Das Ziel der anfänglichen Release-Planung besteht darin, grob abzuschätzen, welche Funktionen bis zum Release-Termin geliefert werden (vorausgesetzt, der Termin ist fest), oder einen ungefähren Liefertermin für einen bestimmten Satz von Funktionen festzulegen (wenn der Umfang feststeht). Anhand dieser Informationen entscheiden wir, ob das Projekt einen ausreichenden ROI erzielt, um sich zumindest selbst zu amortisieren, und ob wir daher fortfahren sollten oder nicht.
Die ersten Besprechungen zur Release-Planung dauern selten länger als einen Tag – oder zwei halbe Tage, wenn Sie es einfach nicht ertragen können, einen ganzen Tag in einer Besprechung zu bleiben. Zunächst stellt der Kunde die zu liefernden Funktionen mit Priorität vor. Im Idealfall haben die Entwickler bereits grobe Schätzungen erstellt, wie viel Arbeit für die Implementierung jeder dieser Funktionen erforderlich ist.
Anhand der Schätzungen der Entwickler und der Funktionsprioritäten des Kunden erstellt das Team einen Release-Plan, in dem die Funktionen sehr grob den ersten Iterationen zugeordnet werden. Die Entwickler stellen möglicherweise fest, dass Funktionen mit relativ niedriger Priorität Design- oder Architekturrisiken bergen, und bitten die Kunden daher möglicherweise, diese Funktionen trotzdem früheren Iterationen zuzuweisen, um diese potenziellen Risiken so früh wie möglich im Projekt zu berücksichtigen.
Es ist enorm hilfreich, wenn die Geschwindigkeit des Entwicklungsteams bei einer früheren Version bereits bekannt ist. In diesem Fall dividieren Sie, wenn der Umfang festgelegt ist, die Gesamtschätzung für alle erforderlichen Funktionen durch die Geschwindigkeit des Teams, um die ungefähre Anzahl der Iterationen zu ermitteln, die zur Bereitstellung der Funktionalität und damit der Frist erforderlich sind. Wenn die Frist festgelegt ist (wie es normalerweise der Fall ist), multiplizieren Sie die Geschwindigkeit mit der Anzahl der Iterationen, um ein erstes Gefühl dafür zu bekommen, wie viele Funktionen bereitgestellt werden können. Wenn die Geschwindigkeit des Entwicklungsteams nicht bekannt ist, muss es eine Schätzung dafür abgeben, und der Release-Plan muss für die ersten paar Iterationen als weniger präzise verstanden werden, bis eine zuverlässige Geschwindigkeitszahl abgeleitet werden kann.
Vorläufiger Veröffentlichungsplan
Der anfängliche Releaseplan stellt selten alle Beteiligten zufrieden – entweder wird nicht genügend Funktionalität geliefert oder es scheint zu viel Zeit erforderlich zu sein, um die gewünschte Funktionalität zu liefern. In der agilen Welt sieht sich das Team jedoch diesen harten Wahrheiten ins Auge und entwickelt einen Softwareentwicklungsplan um sie herum. Niemand glaubt an Umfangswunder, die alle zufriedenstellen. Anstatt kollektive Verleugnung zu praktizieren, verwendet das Team reale Kennzahlen und Verhandlungen, um schwierige Entscheidungen so kurz wie möglich zum Projektstart zu treffen.
Agile Vordenker sind sich einig, dass dies zwar der Fall ist möglich Um Umfang, Termin, Ressourcen und Qualität für ein bestimmtes Projekt anzupassen, sind die einzigen Variablen, die gut auf Anpassungen reagieren, Termin und Umfang. Umfangreiche Forschung hat gezeigt, dass größere Teams dazu neigen, Systeme von geringerer Qualität langsamer zu liefern, während kleinere Teams dazu neigen, Systeme von höherer Qualität schneller zu liefern. Es kann tatsächlich notwendig sein, einem Team Programmierer hinzuzufügen, aber das wird das Team wahrscheinlich zumindest eine Weile verlangsamen, nicht beschleunigen. Wenn wir diese Erkenntnisse akzeptieren, akzeptieren wir, dass wir in unserer Release-Planung entweder den Umfang oder den Termin anpassen müssen, um einen Release-Plan zu erstellen, der von Sponsoren, Kunden, Entwicklern, Managern und anderen Beteiligten als umsetzbar anerkannt wird. Die Tatsache, dass das Team diese schwierigen Entscheidungen im Voraus trifft, verringert das Gesamtrisiko für das Projekt. Es erhöht die Chancen, dass das Team bis zum Termin einen Funktionsumfang erstellt, der die Investitionen der Beteiligten mehr als angemessen zurückzahlt.
Kontinuierliche Planung der Veröffentlichung
Der anfängliche Releaseplan ist als grober Plan zu verstehen. Er muss detailliert genug sein, um uns den Einstieg zu erleichtern, indem er vorhersagt, dass das Projekt eine ausreichende Kapitalrendite liefert, um es mehr als zu finanzieren. (Wenn der anfängliche Releaseplan eine zu niedrige Kapitalrendite vorhersagt, um das Projekt zu rechtfertigen, können wir das Projekt abbrechen, bevor wir sehr viel Geld verschwenden.) In agilen Projekten planen wir kontinuierlich und korrigieren unseren Kurs im Laufe der Zeit. Einer der wichtigsten Mechanismen zur Kurskorrektur besteht darin, den Releaseplan als Reaktion auf alle Arten von Feedback weiterentwickeln zu lassen. Es wird mindestens ein paar Iterationen dauern, bis sich die Teamgeschwindigkeit stabilisiert. Iterationen werden manchmal weniger Funktionalität liefern als geplant und manchmal mehr. Funktionen, Architekturentscheidungen, Designentscheidungen oder Framework- oder Technologieentscheidungen könnten sich als zu riskant oder einfach unbrauchbar erweisen. Die Benutzeroberfläche muss möglicherweise überarbeitet werden. Mitarbeiter könnten verloren gehen oder hinzugefügt werden. Funktionsprioritäten könnten sich ändern. All diese Faktoren werden uns helfen, den Releaseplan kontinuierlich zu überarbeiten und zu verfeinern. Mit jedem neuen Iterationsplan sollte auch ein überarbeiteter Releaseplan veröffentlicht werden, der die neue Realität widerspiegelt.
Start und Abschluss
Viele agile Teams planen, in der ersten Iteration (oft als „Iteration 0“ bezeichnet) nur eine kleine Menge an Funktionalität bereitzustellen, um explizit die Lösung anfänglicher technischer und logistischer Probleme zu ermöglichen und möglicherweise auch die Architektur von Anfang bis Ende zu belasten. Dies kann für Teams, die wenig oder keine agile Erfahrung haben, von entscheidender Bedeutung sein. Für ein Team ohne gute Geschwindigkeitsmetrik könnte dies bedeuten, dass die Geschwindigkeit erst am Ende der zweiten oder dritten Iteration stabil und zuverlässig geworden ist.
Einige Teams planen außerdem bis zu zwei Iterationen zum Projektende zur Stabilisierung, systemweiten Integration und Prüfung, Fehlerbehebung und Fertigstellung der Benutzerdokumentation ein. In einem idealen agilen Projekt wäre dies nicht erforderlich, aber in der realen Welt hängt es von den spezifischen agilen Praktiken ab, denen das Team folgt, der Organisationsstruktur, der Gesamtkomplexität des Systems, den vom Team erwarteten nicht-codebasierten Fähigkeiten, der Komplexität der Systembereitstellung und ähnlichen Faktoren.
Häufig gestellte Fragen
Muss ich wirklich Releases und einen Release-Plan verwenden?
Einige Teams kommen ohne aus agile Planung auf Release-Ebene. Ein ASP kann beispielsweise einfach jede Iteration (also alle paar Wochen) Software in die Produktion bringen, sodass jede Iteration effektiv ein Release ist und eine einfache agile Planung pro Iteration ausreichen kann. Wenn andererseits das Management auf Softwareebene ein gewisses Maß an Transparenz verlangt, Release-Management (d. h. Fortschritt, Status, Änderungen gegenüber dem ursprünglichen Softwareentwicklungsplan usw.) können die Planung und Verwaltung auf Release-Ebene von unschätzbarem Wert sein.
Wie groß sind die Veröffentlichungen?
ReleaseDie Laufzeiten liegen normalerweise zwischen zwei und zwölf Monaten. Bei längeren Releases kann es sinnvoll sein, diese in mehrere Unterreleases aufzuteilen.
Wie viele Iterationen umfasst eine Version?
Die Anzahl der Iterationen innerhalb einer Version wird normalerweise durch den Zeitplan bestimmt. Wenn eine Version sechs Monate dauert und die Iterationen zwei Wochen dauern, sollten für die Version 13 Iterationen eingeplant werden.
Wer ist an der Release-Planung beteiligt?
Bei kleineren Teams kann es sinnvoll sein, dass das gesamte funktionsübergreifende Team sowohl aus Input- als auch aus Verantwortungsgründen teilnimmt. Bei größeren Teams und Organisationen kann eine Untergruppe des Teams ausgewählt oder gewählt werden, um das Team zu vertreten.
Wie lange dauern Release-Planungsmeetings?
Release Planungsbesprechungen dauern in der Regel zwischen vier und acht Stunden.
Wie viel Arbeit wird in die Vorbereitung eines Release-Planungsmeetings investiert?
Im Allgemeinen wurde vor einem Release-Planungsmeeting hinsichtlich Projektgenehmigung, Budgetierung, Vision, Teamidentifikation usw. bereits eine ganze Menge Arbeit erledigt. Hinsichtlich der Funktionalität hat der Kunde wahrscheinlich Zeit damit verbracht, gemeinsam mit der Entwicklung erste Features zu identifizieren und diese möglicherweise aufzuschlüsseln und erste Schätzungen auf hoher Ebene bereitzustellen.
Ändert sich der Veröffentlichungsplan während der Veröffentlichung?
Wenn mehr Informationen aufgedeckt werden, Funktionen bereitgestellt werden, mehr über das System verstanden wird, sich Geschäftsanforderungen entwickeln und Prioritäten ändern, wird sich die Gesamtzusammensetzung der Version mit ziemlicher Sicherheit ändern. Obwohl dies erwartet wird, muss die Entwicklung des Software-Release-Managements im Laufe der Zeit allen relevanten Stakeholdern mitgeteilt werden.
