Ich bin auf ein ständiges Problem gestoßen. Wenn ein Projekt beginnt, hat der Kunde normalerweise eine Liste von Funktionalitäten, die in die Anwendung eingebaut werden müssen. Als Team möchten wir Scrum folgen. Aber als nächstes fragt der Kunde nach einem Go-Live-Termin.
Der Kunde hat seine eigenen Fristen, um auf den Markt zu gehen. Es ist also richtig, dass er ein Datum wissen muss, damit er dem Rest des Unternehmens mitteilen kann, wann die Bewerbung eintrifft.
Da das Team nicht mehr als einen Sprint gleichzeitig planen kann, ist das Enddatum normalerweise nicht sichtbar. Der Kunde sagt: „Ich habe Ihnen bereits genau gesagt, welche Funktionalität ich brauche. Sagen Sie mir, wann Sie diese App erstellen können.“
Wie geht man mit einer solchen Situation in Agile oder Scrum um?
Die agile Release-Planung basiert auf Zyklen mit fester Länge und standardisierter Kapazität , die auf dynamisch geplanten und dynamisch begrenzten Funktionen basieren. In Scrum muss die Release-Planung mit festem Datum durch die Kontrolle des Umfangs gehandhabt werden, um die Fristen einzuhalten, da Sie nicht gleichzeitig Fristen mit festem Datum und festem Umfang haben können. Dies ist selten ein praktisches Problem, kann aber in nicht agilen Shops ein politisches sein.
Die agile Release-Planung basiert auf Iterationen. Um eine kalender- oder zeitbasierte Release-Planung in Scrum durchzuführen:
estimated velocity * fudge factor.Die Anzahl der Iterationen für ein Release wird anhand der folgenden Variablen und Formeln berechnet:
e / v = iDer i -Wert kann wieder in eine Kalender- oder Zeitschätzung umgewandelt werden, indem Interationen mit der Länge der Sprints in Wochen oder Monaten multipliziert werden, z . B. i * 2.
Angenommen, Sie haben einen Gesamtrückstand von 200 Story Points und planen eine zweiwöchige Sprintlänge. Die historische Geschwindigkeit Ihres Teams beträgt 20, aber dies ist ein brandneues Projekt mit einem großen Unsicherheitskegel, daher ist Ihr Fudge-Faktor der Standard-Multiplikator von 0,6; Infolgedessen beträgt Ihre Planungsgeschwindigkeit nach Anwendung des Fudge-Faktors 12 Story Points pro Sprint.
Ihr Veröffentlichungsplan für alle Product-Backlog-Einträge wäre also:
200 / 12 = 17 Sprints
Sie verwandeln dies dann in einen Kalender oder eine Zeitschätzung mit:
17 * 2 = 34 weeks
Basierend auf diesen Informationen wird Ihr Projektplan angeben, dass es etwa 34 Wochen dauern wird, alle Funktionen, die sich derzeit im Product Backlog befinden, auszuliefern. Dies ist eine Schätzung auf der Grundlage der derzeit verfügbaren Informationen und sollte eher als Planungswert denn als eiserne Garantie behandelt werden.
Mit fortschreitendem Projektverlauf verengt sich der Unsicherheitskegel und das Team kann genauere Schätzungen über den Umfang der verbleibenden Arbeit am Product Backlog vornehmen. Darüber hinaus wird ein gut funktionierendes Scrum-Team bei der Messung seiner Geschwindigkeit im Laufe des Projekts genauer, so dass die Berechnungen des Release-Zeitplans von Zeit zu Zeit erneut durchgeführt werden sollten, um den Zeitplan auf der Grundlage genauerer Daten „auf den Punkt zu bringen“. erhältlich.
Darüber hinaus kann der Product Owner während des gesamten Projekts Scope (in Form von Product Backlog Items) hinzufügen oder entfernen. Dies wird den Umfang des Projekts erweitern oder verringern und sich natürlich auf den geschätzten Zeitplan auswirken. Eine Änderung des Projektumfangs sollte in der Regel eine Neuberechnung des Veröffentlichungsdatums auslösen, wenn dies geschieht.
Schließlich strebt Scrum danach, am Ende jedes einzelnen Sprints ein potenziell auslieferbares Produkt bereitzustellen. Obwohl es möglicherweise nicht vollständig in dem Sinne ist, dass es 100 % aller Backlog-Elemente enthält, sollte das Produkt während des Sprint Reviews einen stabilen und veröffentlichbaren Zustand aufweisen, damit die Organisation entscheiden kann, es früher auszuliefern, wenn ein ausreichender Wert im Produkt vorhanden ist Versand im aktuellen Zustand zu rechtfertigen. Diese „Auszahlung“ des verdienten Werts, um ein Minimum Viable Product zu liefern, das als „gut genug“ erachtet wird, kann dem Unternehmen (nicht nur dem Scrum-Team) einen erheblichen agilen Vorteil verschaffen.
Das einzige Werkzeug, das Sie in Scrum haben, um dieser Situation zu helfen, ist Ihre Geschwindigkeit. Ich glaube, Sie kennen Ihre Velocity – wie viele Story Points Sie in einem Sprint schaffen –, prüfen das Product Backlog und planen jede User Story. Anhand dieser beiden erhalten Sie eine Einschätzung zu einem möglichen Liefertermin.
delivery in weeks = ((number of point in backlog) * (number of weeks of a sprint))
/ velocity
Das ist sehr ungenau, aber basierend auf dem, was Sie haben, ist das alles, was Sie tun können.
Wenn Sie einen Product Owner (PO) haben, sollte er/sie die Lieferungen mit dem Kunden auf der Grundlage Ihres Fortschritts und der gelieferten User Stories verhandeln. Der PO sollte herausfinden, welche User Stories ein Muss für Ihren Kunden sind, um sein Geschäft zu starten. Es ist eine Teilmenge des gesamten Produktrückstands, und daher sollte die obige Formel eine bessere Schätzung liefern, da die Unsicherheit geringer ist als für den gesamten Rückstand.
Als Alternative können Sie Ihre historischen Daten überprüfen und sehen, wie lange es gedauert hat, eine ähnliche App bereitzustellen, die Risiken überprüfen, die Sie sehen, und auf dieser Grundlage eine Schätzung abgeben.
time to deliver the previous app +
sum(additional length of each risk when they happen)
Alternative zwei: Sie können ausprobieren, wie Kanban mit diesen Situationen umgeht: http://zsoltfabok.com/blog/2013/02/when-will-it-be-done/
Falls Sie die Geschwindigkeit nicht kennen und keine historischen Daten haben, können Sie versuchen, mit Ihrem Kunden zu sprechen und herauszufinden, welche die wichtigsten Merkmale sind. Setzen Sie sich mit Ihrem Team zusammen und schätzen Sie das Projekt auf altmodische Weise ein.
In der Zwischenzeit können Sie versuchen, Ihren Kunden die Vorteile von Continuous Delivery aufzuzeigen . Häufiges Reden und kontinuierliche Lieferung sind der Schlüssel zu Agile , ich empfehle, damit zu beginnen + die anfängliche Schätzung. Wenn Ihr Kunde sie und die Vorteile versteht – häufige Lieferungen sind sehr hilfreich, wenn man vorgelagerte Projekte plant –, wird es eine Win-Win-Situation sein.
Zsolt hat einige gute Starter, ich gebe ihm eine Stimme.
Scrum funktioniert sehr gut für feste Veröffentlichungstermine, solange Sie eine einfache Realität erkennen. Dass man mit Scrum eine von zwei Wahrheiten haben kann.
1- Sie erledigen entweder die gesamte Arbeit im Backlog. Du weißt nur nicht wann.
2- Sie geben an einem bestimmten Datum die Arbeit frei, die Sie bis zu diesem Datum abgeschlossen haben.
Wenn Ihr Kunde (oder interner Chef) Ihnen ein festes Datum gibt, müssen Sie weiterliefern, dann verwenden Sie Techniken wie das, von dem Zsolt spricht, und schätzen, wie viel Arbeit Sie tun können. Zu Beginn der Entwicklung ist meine allgemeine Richtlinie, dass Sie sich nicht zu mehr als 50 % dessen verpflichten, was Sie für möglich halten. Denn das Gesetz von Hofstadter besagt, dass Sie die Arbeit immer unterschätzen werden, auch wenn Sie das Gesetz berücksichtigen.
Das Schöne an Scrum ist, dass Sie beim Durchlaufen des Projekts Ihre Geschwindigkeit nutzen können, um Ihre Vorhersage zu verfeinern, was Sie liefern werden. Wenn Sie 2/3 der Entwicklung abgeschlossen haben, haben Sie eine felsenfeste Vorstellung davon, was ausgeliefert wird.
Das bedeutet, dass Sie sicherstellen müssen, dass der Rückstand gut geordnet ist. Liefern Sie zuerst das Wichtigste und dann das Kleinere. Wenn Sie also nicht alles versenden, verpassen Sie nicht das MVP-Zeug.
Wenn Ihr Kunde sagt "Aber es muss alles versendet werden", haben Sie ein anderes Problem. Scrum wird das nicht beheben, Sie müssen Agilität in der Wertschöpfungskette nach oben bringen. Ich empfehle Innovation Games, den Produktbaum zu beschneiden und ein Feature zu kaufen, wenn Sie damit konfrontiert werden.
Hinweis: Eine Sache, die mir in Ihrem Beitrag aufgefallen ist, ist, dass Sie "Da das Team nicht mehr als einen Sprint gleichzeitig planen kann" erwähnt haben. Das ist eine Flagge für mich. Teams sollten außerhalb des normalen Sprints mit ihrem Product Owner zusammenarbeiten, um den Rückstand zu pflegen und zukünftige Arbeiten zu planen. Wenn Sie zu einem Sprint kommen, sollten Sie bereits eine gute Vorstellung davon haben, was Sie im Sprint tun werden. Ich habe ein Team, das gerade mit seinem Product Owner zusammengearbeitet hat und einen Arbeitsplan (der sich ändern wird) für die nächsten acht Sprints (4 Monate) hat. Ein separates Thema von diesem, nur etwas, das ich zum Nachdenken bringen wollte.
Die Idee von Scrum ist, dass sich ein Team darauf konzentriert, das zu liefern, was ein Kunde will. Dazu machen wir etwas Arbeit, demonstrieren es, hören uns Feedback an und passen uns dann an. Dieser Ansatz trägt der Tatsache Rechnung, dass es für einen Kunden schwierig ist, seine Anforderungen im Voraus zu erfüllen. Es ist viel einfacher, ein erfolgreiches Produkt zu entwickeln, wenn Sie ständiges Feedback und Anpassungen haben.
Wenn ein Kunde den Umfang und das Enddatum des Projekts festlegen möchte, wird er nicht den vollen Nutzen aus dem Scrum-Ansatz ziehen.
Ich würde vorschlagen, mit Ihren Kunden zu sprechen und ihnen die Idee zu verkaufen, dass der Scrum-Ansatz ihnen die Möglichkeit gibt, das Produkt nach ihren Wünschen zu gestalten. Es wird eine gewisse Unsicherheit über das Enddatum geben, aber dies wird gegen den Wert verrechnet, das Produkt richtig zu machen.
Natürlich gibt es Situationen, in denen der Kunde eine harte Deadline hat. In solchen Situationen arbeiten wir den priorisierten Rückstand an Anforderungen so weit wie möglich in der vorgegebenen Zeit ab. Wenn der Kunde im Laufe des Projekts neue Anforderungen einführt, kann dies dazu führen, dass Sie auf der Liste weniger weit nach unten kommen. Tatsächlich wird das, was geliefert wird und wann es geliefert wird, sowohl vom Kunden als auch vom Lieferteam bestimmt.
Es gibt zwei Methoden, Liefertermine für Ihren Rückstand zu prognostizieren:
Ist dem, was Todd in seiner Antwort beschreibt , sehr ähnlich , aber genauer, weil:
Gehen Sie also über den Link unten, sehen Sie sich das Video an und laden Sie die Excel-Datei herunter, die die Berechnungen für Sie erledigt – alles, was Sie brauchen, ist, Ihre Backlog-Elemente, ihre Schätzungen und in welchem Sprint sie abgeschlossen oder hinzugefügt werden.
Ist eine Technik, bei der Sie nicht einmal Schätzungen für Elemente in Ihrem Backlog benötigen – Sie geben einfach "1" als Schätzungen in Ihre Reliable Scrum-Datei für alle darin enthaltenen User Storys ein, und dann erhalten Sie eine genaue Prognose, wann Ihr Backlog dies tun wird auszufüllen.
Es scheint magisch zu sein, funktioniert aber tatsächlich sehr gut, da es tatsächlich die Zeit berücksichtigt, die zum Abschließen Ihrer Arbeitsaufgaben benötigt wird. Dh es wird nicht durch Rauschen durch ungenaue Expertenschätzungen Ihrer Rückstandsposten beeinflusst!
Als ich beide Methoden bei 5 Projekten verglichen habe, hat sich gezeigt, dass beide Methoden sehr gut funktionieren und die letzte noch genauere Ergebnisse liefert als die erste.
Weitere Informationen finden Sie im Video von Troy Magennis . Sie müssen die Theorie dahinter nicht verstehen – wissen Sie nur, dass die Verwendung von Reliable Scrum mit „1“ als Schätzung für Ihre Backlog-Elemente sehr gut funktioniert.
Ich glaube, es ist diese Art von historischer Situation, die zum agilen Wert geführt hat
Kundenzusammenarbeit über Vertragsverhandlungen
Beachten Sie auch
auf Veränderungen reagieren, anstatt einem Plan zu folgen
Der PO hat ein Problem mit der Kundenbindung, das er lösen muss, bevor die Arbeit beginnen kann, um ein teures Durcheinander zu vermeiden.
Der Vater von Scrum , Jeff Sutherland , hat ein Scrum-Muster entwickelt: „Change For Free and Money for Nothing“ . Obwohl es unwahrscheinlich ist, dass Ihr Unternehmen oder Ihre Kunden bereit sind, solche Agile-Verträge abzuschließen, lohnt es sich, diese zu überprüfen, um zu verstehen, wie der PO mit dem optimalen Kundenwert und dem ROI umgehen sollte.
Verwenden Sie gepufferte Moskau-Regeln
Grüße,
Yves Lehmann