Zeitpläne für die Freigabe in agilen Umgebungen

Question

Wir arbeiten derzeit in einem agilen Umfeld. Eine meiner Aufgaben besteht darin, einen Zeitplan für die Veröffentlichung zu erstellen. Dazu gehört es, einen Zeitrahmen zu erstellen, der angibt, wie lange ein Projekt braucht, um von der Entwicklungsumgebung zum Staging und dann in den Echtbetrieb überzugehen.

Ich habe widersprüchliche Ansichten darüber, ob ein solcher Zeitplan notwendig ist.

Zunächst einmal bewegen wir uns schnell auf eine Umgebung mit kontinuierlicher Integration und konstanter Bereitstellung zu, in der eine Anwendung in allen Umgebungen getestet wird, wenn eine Änderung an der Codebasis vorgenommen wird. Daher gibt es keinen Zeitrahmen, aber die Dinge sollten "einfach" bereitgestellt werden können. (Nun ja, wir brauchen immer ein wenig Kontingenz, denn die besten Pläne können immer schief gehen.)

Kann mir jemand einen Tipp geben, wie ich solche Zeitpläne und Zeitrahmen am besten handhaben kann, wenn sie für das Release Management in einer agilen Produktentwicklungsumgebung benötigt werden?

Herzliche Grüße,

Steve

Answer 1

Kann mir jemand einen Tipp geben, wie ich solche Zeitpläne und Zeitrahmen am besten handhaben kann, wenn sie für das Release Management in einer agilen Produktentwicklungsumgebung benötigt werden?

Zunächst einmal wird in den Richtlinien des Scrum Frameworks niemals empfohlen, keinen Release-Plan oder Zeitplan zu erstellen. Was bringt Sie dazu, widersprüchliche Gedanken zu haben? Ich würde gerne die Quelle kennen, die Sie zu diesem Konflikt führt.

Am besten erstellen Sie einen Freigabeplan wie folgt (dies kann je nach Größe Ihres Projekts etwa eine Woche dauern):

1. Versammeln Sie die Stakeholder in einem Raum und schreiben Sie unter deren Anleitung eine EPIC User Story an die Tafel. Die EPIC-Benutzergeschichte sollte die Vision des Endprodukts enthalten. (ignorieren, falls bereits geschehen)

2. Führen Sie die Art der Benutzer auf (ignorieren Sie, falls bereits geschehen).

3. Zerlegen Sie die Epic User Story in immer kleinere Teile von User Stories, bis sie klein genug sind, um in Sprints bearbeitet werden zu können (ignorieren Sie, falls bereits geschehen).

4. Bitten Sie den/die Product Owner des/der Scrum-Teams, die Stories in der/den unbestätigten Backlog-Liste(n) zu priorisieren.

5. Holen Sie sich von den Stakeholdern das angestrebte Enddatum oder das Datum für die Inbetriebnahme des Projekts.

6. Teilen Sie den Zeitrahmen von jetzt bis zum Enddatum in Releases ein. Fragen Sie die Stakeholder, welche Funktionen bis wann geliefert werden müssen, und fügen Sie die entsprechenden User Stories hinzu, und nennen Sie diese Releases. Bei Bedarf können Sie diesen Releases auch Themen zuweisen.

Der Freigabeplan ist nun konzeptioniert. Zeichnen Sie ihn auf ein Whiteboard oder legen Sie ihn an einen sichtbaren und transparenten Ort, wo ihn jeder sehen kann - fügen Sie User Story Cards zum entsprechenden Release hinzu.

Jetzt sollte Ihr erster Freigabeplan fertig sein

Ideen für die Umsetzung:

1. Bilden Sie ein Scrum-Team speziell für operative Aktivitäten. Sie könnten nach Scrum oder besser nach Kanban arbeiten.

2. Sobald die Entwicklungsteams "versendbare Produkte" in das Regal stellen, kann das Operations Kanaban Team die Bereitstellung und Verzweigung usw. gemäß dem Release-Plan vornehmen.

Auf diese Weise konzentrieren sich die Entwicklungsteams nicht wirklich auf den Release-Plan oder die Arbeit, sondern das Operationsteam übernimmt diese Aufgabe. Das Entwicklungsteam konzentriert sich nur auf die Sprint-Arbeiten, und der Product Owner muss sicherstellen, dass die richtigen User Stories im richtigen Release und in der richtigen Reihenfolge sind. Die Richtung würde von den Stakeholdern vorgegeben werden.

Um ehrlich zu sein, müssen Sie wirklich nichts selbst tun, es liegt alles in der Hand der Interessengruppen und POs, ich weiß nicht, wo das Problem liegt?

Ich hoffe, Sie verstehen das Bild.

Answer 2

In der Regel pflege ich einen Release-Plan für das Management, der hauptsächlich auf einer Kombination aus den geschätzten und priorisierten User Stories (ich gruppiere sie so, dass sie zu einer neuen Hauptfunktion des Produkts passen) und der Geschwindigkeit basiert.

Mit einem gut gepflegten Product Backlog ist es ziemlich einfach, einen Release-Plan zu erstellen. Ich plane in der Regel drei bis vier Releases pro Jahr.

Was mir an Scrum gefällt, ist, dass ich nach jeder Iteration möglicherweise eine Freigabe erteilen kann.

Wenn Sie Ihr Release Management meistern wollen, brauchen Sie mehr Informationen als die wenigen Antworten von Praktikern. Ich empfehle Ihnen dringend dieses Buch .

Answer 3

Wenn Sie derzeit eine agile Umgebung nutzen, sollten Sie Folgendes überprüfen Buch über agile Kalkulation und Planung für einige Vorschläge. Dieses Buch enthält auch ein kleines Kapitel über Release-Planung.

Eine gewisse Release-Planung sollte immer vorgenommen werden. Ein Release ist ein Ziel, das normalerweise 3-12 Monate der Entwicklung = eine Reihe von Iterationen umfasst. Es ist etwas, das die Zielkriterien für den Projekterfolg beschreibt. Es wird in der Regel als Kombination von erwarteten Features und einem Datum beschrieben. Features sind in diesem Fall normalerweise nicht direkt User Stories, sondern Epen oder ganze Themen, da man nicht alle User Stories mehrere Monate im Voraus kennt. Ich persönlich denke, dass Release etwas ist, das angibt, wann das Projekt basierend auf der Vision geliefert werden kann. Es nimmt die hohen Erwartungen und Einschränkungen aus der Vision und wandelt sie in eine Schätzung um. Man kann ein Projekt auch in mehrere Releases unterteilen.

Aber denken Sie daran, dass die drei Kräfte auch im agilen Bereich wirken. Es besteht ein direkter Zusammenhang zwischen dem Feature-Set, dem Veröffentlichungsdatum und den Ressourcen (und der manchmal auch erwähnten vierten Kraft: Qualität). Wird eine dieser Kräfte forciert, bewegen sich immer auch die anderen. Es wird normalerweise als gleichseitiges Dreieck (oder Quadrat) modelliert.

Es gibt verschiedene Ansätze für die Planung einer Veröffentlichung. Eine davon wird in dem Buch erwähnt. Er basiert auf der Schätzung von Benutzergeschichten, der Auswahl der Iterationslänge und der Schätzung der Geschwindigkeit, aber ich stehe diesem Ansatz etwas skeptisch gegenüber, weil man keine einfachen Benutzergeschichten für die gesamte Version hat und die Schätzung von Epics und Themen ungenau ist. Andererseits ist die Definition von Features auf hoher Ebene genau das, was man für Three Forces braucht. Wenn Sie nicht genug Zeit haben, werden Sie nur die grundlegenden Funktionen aller Themen implementieren. Wenn Sie mehr Zeit haben, werden Sie mehr fortgeschrittene Funktionen implementieren. Dies ist die Aufgabe des Product Owners, die geschäftlichen Prioritäten richtig zu setzen, wenn er die Epen und Themen in kleine User Stories aufteilt.

Das Wichtigste an der agilen Methode ist, dass man schon bald mehr weiß. Nach jeder Iteration haben Sie bessere Kenntnisse über Ihre Geschwindigkeit und Sie werden auch einige geplante User Stories neu einschätzen. Aus diesem Grund denke ich, dass die tatsächliche (genaue) Schätzung und das Veröffentlichungsdatum nach einigen Iterationen geplant werden sollten. Wie mir in einer Schulung gesagt wurde, sollte der Aufwand nicht geschätzt werden, sondern gemessen werden. Wenn sich jemand darüber beschwert, zeigen Sie ihm Waterfall und fragen Sie ihn, wann er eine relativ genaue Schätzung erhält. Tipp: Kaum vor dem Ende der Analyse, die etwa nach 30% des Projekts stattfinden sollte.

Es ist auch wichtig, welche Art von Projekten Sie mit Agile/Scrum durchführen wollen und wie lang das Projekt sein wird. Einige Projekte sind strikt budget- oder terminorientiert, andere wiederum können eher funktionsorientiert sein. Dies kann sich auf Ihre Release-Planung auswirken. Bei kurzen Projekten haben Sie in der Regel kleine User Stories und können zu Beginn eine viel genauere Schätzung abgeben.

Answer 4

Das ist eine sehr schwierige Frage, die sicher von Ihrem Unternehmen abhängt. Zunächst muss ich fragen, warum Sie 3 Umgebungen und kontinuierliche Integration verwenden (der Grund ist wichtig)? Führen Sie überhaupt automatisierte Tests durch? Wie sind Ihre Codeverzweigungen aufgebaut? Geben Sie eine bestimmte Funktionalität frei oder nehmen Sie nur routinemäßige Wartungsarbeiten vor?

Die Beantwortung dieser Fragen wird Ihnen Aufschluss darüber geben, warum Sie eine Freigabe benötigen und wie Sie dabei vorgehen sollten.

Wenn Sie zum Beispiel nur eine Staging-Umgebung für die Integration haben und automatisierte Tests durchführen, kann es dann nicht ausreichen, einen separaten Code-Zweig zu haben, in dem kontinuierliche Integrationstests laufen?

Wenn das Staging dazu dient, eine Art von Benutzerakzeptanz durchzuführen, verfügt Ihr Unternehmen dann über ein spezielles Testteam oder sind sie Mitglieder der agilen Teams?

Wie Sie richtig sagten, wenn der Code immer integriert und getestet wird, warum bräuchten Sie dann einen Zeitplan und den Wechsel von einer Umgebung zur nächsten, wenn Sie sich nicht sicher sind, ob die Funktionen tatsächlich "fertig" sind? Damit meine ich nicht, dass Sie unsicher sind, ob die Funktion korrekt kodiert wurde, sondern dass Sie befürchten, dass sie andere Fehler einführt? Wird sie sich gut in den bereits in Produktion befindlichen Code integrieren lassen? Gehen Sie die Bedenken an der Wurzel des Problems an. Tun Sie es nicht nur, weil Sie denken, dass Sie X Umgebungen haben sollten oder dass die Tests in einer anderen Gruppe stattfinden sollten. Vielleicht besteht die Lösung für diese Probleme darin, die Definition von "fertig" entsprechend anzupassen.

Wie Sie sehen können, gibt es viele, viele Faktoren, die Ihre Organisation einzigartig machen werden. Es gibt nicht den einen richtigen Weg, sondern nur Kompromisse, die Sie bereit sind zu akzeptieren.

Ich finde, dass mehrere Umgebungen mit Teams von Mitarbeitern, die auf den verschiedenen Ebenen arbeiten, eher kontraproduktiv sind und der Agilität entgegenwirken. Am besten analysieren Sie Ihre Bedenken und versuchen, Wege zu finden, sie zu lösen (z. B. die Definition von "erledigt" zu erweitern oder die verschiedenen Organisationen aufzulösen und sie den Teams zuzuordnen, so viele Umgebungen wie möglich zu eliminieren und den Prozess zu vereinfachen usw.). Möglicherweise ist dies in Ihrer Organisation nicht möglich, so dass Sie mit Kompromissen leben müssen.