Wie kann die Release-Planung genauer gestaltet werden?

Kein Wunder, dass ich diese Frage oft höre. Das grundlegende Problem bei der Frage ist, dass Agile mit der Grundidee eines Projekts mit festem Umfang/festem Zeitplan nicht einverstanden ist. In der Frage, die Ihnen gestellt wurde, wird angenommen, dass das Enddatum eines festgelegten Umfangs bekannt ist, und das Problem besteht darin, dass wir schlecht darin sind, es zu kennen (zu schätzen). Das ist nicht wirklich wahr. Das Enddatum eines bestimmten Bereichs ist kein erkennbarer Zeitpunkt. Vielmehr handelt es sich um eine zeitliche Verschiebung.

Die Verbesserung der Teamfähigkeiten, das Verständnis der Benutzeranforderungen und ein differenzierteres Verständnis der Implementierung im Verlauf des Projekts verschiebt dieses Datum tatsächlich.

Schauen Sie sich dieses Henrik Kniberg-Video von 11:25 -> 14:45 an (das ganze Video ist großartig, aber dieser Teil ist für diese Frage relevanter). Es leistet großartige Arbeit, wenn es um Prognosen geht, und Sie können dies mit den Ergebnissen der Release-Planung verwenden.

Sie können sehen, dass ich das Enddatum Ihres Projekts festlegen kann, wann immer Sie möchten, wenn die Frist wirklich wichtig ist, oder wir können das Datum verlängern, wann immer der Umfang fertig ist, wenn dies wichtig ist, aber beides festzulegen ist nur eine Vermutung und ein Glücksspiel.

Sergey, die von Ihnen beschriebenen Schritte werden Ihre Veröffentlichungsplanung präziser machen, aber nicht die Genauigkeit verbessern. Gehen Sie nicht in die Falle zu glauben, dass ein detaillierter, expliziter Prozess während der Release-Planung die Genauigkeit verbessert.

Es ist eine Falle, in die wir voreingenommen geraten, weil wir als Menschen versuchen, ein Gefühl der Kontrolle zu schaffen, wo es keines gibt. Die einzige Möglichkeit, die Veröffentlichungsplanung genauer zu gestalten, besteht darin, die Planung näher am Veröffentlichungsdatum vorzunehmen. In der Tat, wenn Sie die Planung am Tag der Veröffentlichung durchführen, haben Sie eine sehr hohe Genauigkeit ;).

Wie Daniel sehr gut erklärt, widerspricht Agile dem Konzept der festen Zeit/des festen Umfangs und respektiert die Tatsache, dass wir zu Beginn eines Projekts einfach nicht mit einem hohen Maß an Genauigkeit schätzen können. Fragen Sie Ihr Management, was das Besondere an der 30 % Abweichungsmarke ist.

Das Beste, was Sie während der agilen Release-Planung tun können, ist:

• Stellen Sie sicher, dass Sie die richtigen Leute im Raum haben
• Planen Sie oft in kleineren, fokussierten Bursts
• Akzeptiere, dass sich der Plan ändern wird
• Seien Sie explizit in Bezug auf Annahmen

Es hört sich so an, als hätten Ihre Interviewer einen "Release-Plan" als Szenario mit festem Umfang und festem Datum definiert. Eine einfache Möglichkeit, die Genauigkeit dieser Pläne um mindestens 30 % zu verbessern.

Einfache Antwort

• Reduzieren Sie die Qualitätsstandards nach Bedarf, um die Frist einzuhalten

Aber im Ernst, das klingt wie eine Fangfrage für einen Shop, der Scrum betreibt. Projekte mit festem Datum und Umfang sind für Projekte mit nennenswerter Komplexität so gut wie zum Scheitern verurteilt (siehe Stacey-Matrix unten zur Veranschaulichung von „Komplexität“).

Möglicherweise können Sie argumentieren, dass prädiktive Prozesse oder Methoden auf einfachere oder sogar kompliziertere Projekte überlagert werden können; Die meisten Softwareentwicklungen bewegen sich jedoch definitiv im komplexen Bereich. Weitere Informationen finden Sie im Cynefin Framework für gute Definitionen von einfach, kompliziert, komplex und chaotisch.

So könnten Sie diese Frage beantwortet haben

Zuerst würde ich die Dysfunktion des festen Datums und des Geltungsbereichs auflösen; Wir würden entweder an einem bestimmten Datum veröffentlichen, aber den Umfang dessen, was wir veröffentlicht haben, flexibel festlegen oder veröffentlichen, wenn ein bestimmter Arbeitsumfang abgeschlossen ist. Darüber hinaus würde das Entwicklungsteam mit der Entwicklung qualitativ hochwertiger Software mit geringer technischer Verschuldung beauftragt, damit zukünftige Versionen nicht durch schlechte technische Entscheidungen und Abstriche verlangsamt oder zunehmend unvorhersehbar werden.

Der Scrum-Guide sagt:

Scrum basiert auf der empirischen Prozesssteuerungstheorie oder dem Empirismus. Der Empirismus behauptet, dass Wissen aus Erfahrung stammt und Entscheidungen auf der Grundlage dessen getroffen werden, was bekannt ist. Scrum verwendet einen iterativen, inkrementellen Ansatz, um die Vorhersagbarkeit zu optimieren und das Risiko zu kontrollieren. Drei Säulen tragen jede Implementierung empirischer Prozesskontrolle: Transparenz, Kontrolle und Anpassung.

Um sicherzustellen, dass sich die Zuverlässigkeit von Veröffentlichungsplänen um 30 % verbessert, würde ich darauf bestehen, dass die Entwicklungsteams im Laufe der Veröffentlichung so unverändert wie möglich bleiben. Dies erhöht die Stabilität des Systems und steigert möglicherweise die Produktivität erheblich im Vergleich zu Teams, die sich häufig neu formieren.

Als Nächstes würde ich mit dem Team zusammenarbeiten, um Prognosen auf der Grundlage des beobachteten Fortschritts in Richtung des Veröffentlichungsumfangs (oder Datums) nach 2-3 Sprints des neuen Veröffentlichungszyklus zu erstellen. Diese 2-3 Sprintperiode stellt sicher, dass einige aussagekräftige und empirische Daten zur Erstellung der Prognose verwendet werden.

Zuletzt würde ich aussagekräftige Visualisierungen des Fortschritts der Teams unter Berücksichtigung ihrer kollektiven „Unsicherheitskegel“-Bereiche aufrechterhalten, um den Interessengruppen aktuelle Schätzungen bereitzustellen, wenn neue Daten auftauchen. Ich würde grundlegende Mathematik wie die in Mike Cohns „ Velocity Range Calculator “ verwenden, um genau abzuschätzen, welcher Umfang zu einem bestimmten Datum vollständig wäre oder zu welchem ​​​​Datum ein bestimmter Umfang vollständig wäre.

Ich werde es vermeiden, auf den Vergleich mit einem Veröffentlichungsplan mit festem Datum einzugehen, und nur einige Vorschläge unterbreiten, wie die Schätzungen der User Stories und der damit verbundenen Aufgaben verbessert werden können (wenn Sie wissen, wie viel sie dauern und die Teamgeschwindigkeit, ist es ziemlich einfach, zu sehen, welcher Umfang kann in einer bestimmten Version erreicht werden).

• Teilen Sie die größeren Geschichten auf ; kleinere Geschichten/Aufgaben sind leichter einzuschätzen
• Sie können Story Points anstelle von Zeiteinheiten (Mannstunden, Manntage, ...) verwenden, also einheitenlose Zahlen, und wenn Sie sie relativieren , wird es einfacher: Sie können ähnliche Storys vergleichen (d. h. eine Zwei -Punkte-Story sollte damit rechnen, dass sie doppelt so lange dauert wie eine Ein-Punkte-Story) – die Leute fühlen sich wohler bei relativen Schätzungen als bei absoluten Schätzungen.
  Sie könnten damit beginnen, herauszufinden, welche die kleinste Geschichte ist, eine, die von einer Person in etwa einem Tag oder einem halben Tag erledigt werden kann, und Sie schätzen diese als 1 ein. Fahren Sie dann mit allen anderen Geschichten relativ fort.
• Noch raffinierter ist es , Zahlen zu verwenden, die von der Fibonacci-Reihe abgeleitet sind: 1,2,3,5,8,13,21, … (jede Zahl ist die Summe der beiden vorherigen). Diese Sonderserie hat den Vorteil, dass die Zahlen exponentiell ansteigen und dadurch das Konzept verstärkt wird, dass eine Aufgabe, die größer ist, komplexer zu implementieren ist und aufgeteilt werden sollte.
  Sie können sogar Ihre eigene (vereinfachte) Reihe herausbringen, wie 1,2,3,5,10,20,40,100. ​ Der untere Bereich (bis 10) soll Teams helfen, kleine Dinge, die sie gut verstehen, genauer einzuschätzen. Der obere Bereich weist jedoch steigende Zahlen auf, was eine größere Unsicherheit widerspiegelt. Wenn die Schätzungen diesen Bereich erreichen, bedeutet dies, dass die Story zu umfangreich für eine Iteration ist, ein erhebliches Risiko darstellt und aufgeteilt werden muss.
• Wer sich freiwillig für die Aufgabe meldet, darf sie normalerweise schätzen. Dies setzt voraus, dass der Freiwillige weiß, wovon er spricht, aber sehr oft erhält man ein verzerrtes Ergebnis, das am Ende ziemlich daneben sein kann.
  Anstatt die gesamte Last und Verantwortung für einen Kostenvoranschlag auf die Schultern eines Einzelnen zu legen , sind Kostenvoranschläge Eigentum von Teams.
  Der akzeptierte Ansatz dafür besteht darin, 3-Punkte-Schätzungen zu verwenden und diese als Team zu konvergieren . Techniken wie Breitband-Delphi stellen Techniken zum Kombinieren mehrerer Schätzungen mit zugehöriger Ungenauigkeit bereit.
  ​Ein bisschen raffinierter wäre es, alle im Team zu fragen und einen Durchschnitt zu bilden. Es könnte Variationen geben, wie das Entfernen des höchsten und des niedrigsten Wertes aus dem Durchschnitt
• Eine andere Möglichkeit wäre das sogenannte Planungspoker : Für jede Aufgabe entscheidet sich jeder im Team für einen Schätzwert und präsentiert dann alle gemeinsam ihren Wert. Der Niedrigste und der Höchste können erklären, warum sie so denken, und dann wird der Prozess wiederholt, bis sich die Mitglieder auf einen gemeinsamen Wert einigen.
  Der große Vorteil dieses Prozesses ist, dass der Wert so kommt, als käme er vom gesamten Team.
• Bewahren Sie einen historischen Satz abgeschlossener Elemente für die Überprüfung auf
• Widmen Sie einen Teil des retrospektiven Fokus dem Unterschied zwischen den Freisetzungszielen und Schätzungen und verstehen Sie, woher dieser kommt.
  Konzentrieren Sie die Schätzungsbemühungen auf den Bereich, in dem es am deutlichsten erforderlich ist (z. B. wo die Differenz zwischen erwartetem und Ergebnis größer war oder Bereiche, die besonders unsicher sind).
• Planen Sie Spikes (dedizierte Forschungsiterationen) für unsichere Bereiche
• In jeder Veröffentlichung kann viel schief gehen, um die Schätzung ungültig zu machen. Diese Variabilität wird im großen Maßstab verstärkt (mehr oder größere Teams, längere Zyklen). Schätzer können stochastische (probabilistische) Systeme, wie z. B. Entwicklungsarbeiten, mithilfe von Monte-Carlo-Simulationen modellieren . Mit einem solchen Modell für die Dauer der Veröffentlichung können Sie die Auswirkungen vieler Variabilitäts- oder Risikoelemente einbeziehen, einschließlich Umfangsänderungen, Fluktuation und langer Krankheit. Es ist besonders nützlich bei sehr großen und lang andauernden Entwicklungen und bei Projekten mit festem Preis und fester Dauer.
  Tom DeMarco hat eine Excel-Datei für die Monte-Carlo-Simulation namens Riskology erstellt , die frei zugänglich ist.

Aber Vorsicht bei der Diskussion: Zu viel Präzision kann schaden.
Zu viel Zeit aufzuwenden erhöht im Allgemeinen nicht die Genauigkeit der Schätzungen (und es langweilt das Team!). Zu viel Zeit mit Schätzen zu verbringen, ist wirklich eine Form der Verschwendung. ​ Am Ende müssen die Teams darauf achten, ihre Schätzungen zeitlich einzugrenzen und nicht versuchen, diese Heuristik in eine Pseudowissenschaft zu verwandeln.

Um die Release-Planung genauer zu machen, müssen folgende Vorsichtsmaßnahmen berücksichtigt werden: Aber Sie können nicht umhin, 15-20 % Puffer in Betracht zu ziehen.

1. Verstehen Sie Ressourcen und deren Effizienzniveaus [Dies ist nur möglich, wenn Sie lange Zeit mit einem Team zusammenarbeiten]

2. Iterationen und Qualitätskontrolle im Auge behalten. [Dies ist möglich, wenn die Kommunikation und Disziplin der Stakeholder aufrechterhalten wird.]

3. Kommende Technologien im Auge behalten [Man weiß nie, was einem das Leben schwer oder leichter machen kann]

4. Reviews und Entwicklung halten sie Hand in Hand. [Aufrechterhalten optimaler QA-Turnaround- und Review-Zyklen]

5. Beobachten Sie die Bewegungen der Wettbewerber genau [Durch die kontinuierliche Bewertung der Entwicklungen der Wettbewerber bleiben Sie bei der Produktvision immer einen Schritt voraus. Ich kenne einige Produkte, die auf Whiteboards gelandet sind, nachdem die Konkurrenz tolle Inhalte veröffentlicht hat.]

6. Erstellen Sie eine bereichsfähige Aufteilung von Features. Und priorisieren Sie die wichtigsten auf TOP.

Es hört sich so an, als ob Sie sich in einer Umgebung mit geringem Vertrauen befinden.

Wenn Sie sich in einer Umgebung mit wenig Vertrauen befinden, müssen Sie so viel Planung wie nötig durchführen, um loszulegen. Sobald Sie beginnen und liefern, werden Sie beginnen, Vertrauen zu schaffen und die Notwendigkeit einer solchen detaillierten Planung im Voraus zu untergraben. Ihre Antwort ist die einzig brauchbare.

Das ist so typisch für große Organisationen am Anfang einer agilen Transformation oder einer ins Stocken geratenen, dass es im Professional Scrum Training einen eigenen Abschnitt dazu gibt.

Es gibt die Ideologie, die ideale Scrum-Umgebung, und dann gibt es die Realität Ihrer organisatorischen Dysfunktion. Da diese Organisation ernsthafte Arbeit und Anstrengungen zu benötigen scheint, um sie in Richtung Agilität zu bewegen, sollten Sie sich fragen, ob Sie bereit sind, diese Anstrengungen beizutragen.

Ich jedenfalls liebe Herausforderungen...

Stimme @Daniel voll und ganz zu und könnte noch etwas hinzufügen: Wenn die Umgebung (wie ungeplante Ablenkungen, ungefähr verfügbare Arbeitsstunden usw.) konstant ist, wird das Team mit der Zeit erkennen, sprint velocitydass dies nur helfen kann, abzuschätzen, wie schnell a Geschichte kann geliefert werden. Dies ist kein Vertrag, sondern nur ein Kostenvoranschlag.

Und die Schätzungen, über die wir sprechen, sind maximal Tage bis zu einer Sprintperiode, nicht Monate, wie im Wasserfall zu sehen ist.

Wenn Sie continuous deliveryAgile hinzufügen, brauchen Sie nicht einmal (oder besser – es macht keinen Sinn) Schätzungen zu erstellen, da Stories fließend aus dem Backlog mit fast kommen und gehen minimal lead time. Mit Continuous Delivery können Sie jeden Tag mehrere Releases haben. Dies funktioniert jedoch mit softwarebasierten Produkten und trifft möglicherweise nicht direkt auf andere Arten von Produkten zu.