Ich bin wirklich verwirrt darüber, wie Kosten und Aufwand für agile Projekte budgetiert werden, bevor das Projekt beginnt. Denn die User Stories werden nie vollständig als Praxis in Agile diskutiert und eingeschätzt. Wenn wir also raten und zu einer Reihe von Story Points kommen (bis Mai vom Produktmanager während der Gründung), die per Definition alles andere als genau sein werden, wie wird das Budget basierend auf dieser wilden Vermutung abgeschlossen.
Jede Erkenntnis würde helfen...
Nun, die einfache und wahrscheinlich nicht ganz hilfreiche Antwort lautet: Agilität erfordert eine Änderung der Geschäftspläne. Sie finanzieren Teams, keine Projekte.
Das ist nicht ganz hilfreich, also lassen Sie mich versuchen, die Lücke zu schließen.
Der Erfolg eines agilen Projekts hängt von einem guten Backlog und engagierten Teams ab.
Wenn Sie keine Zeit für die Planung eines Rückstands aufwenden, erhalten Sie nie eine genaue Schätzung, und als Ergebnis erhalten Sie kein gutes Budget. Das heißt nicht, dass Sie das gesamte Backlog in seine Teilaufgaben zerlegen müssen. Sie müssen genug zerlegen, um die Antwort zu erhalten, die Sie benötigen. Der entscheidende Schlüssel sind die Akzeptanzkriterien. Sie könnten ein riesiges Epos von „Bereitstellen von Spa-Dienstleistungen im Hotel“ haben und wenn Sie Akzeptanzkriterien dafür haben „Massagen, Gesichtsbehandlungen, Schlammbäder, Zen-Warteraum“, dann können Sie es schätzen und damit ein Budget festlegen.
Ein gut zusammengestelltes und funktionierendes Team wird in der Lage sein, einen hohen Rückstand aufzunehmen und eine angemessene Schätzung der Lieferzeit zu erstellen. Noch wichtiger ist, dass ein gut geformtes Team, das mit einem guten Product Owner (oder Product Owner) Team zusammenarbeitet, die User Stories priorisieren kann. Warum ist das wichtig?
Bei Verwendung von Scrum ist das Datum festgelegt. So können Sie den Aufwand budgetieren. Was dann fließend wird, ist der Umfang. Da Sie das Backlog richtig priorisiert haben, wird etwas, das nicht erstellt wird, eines der am wenigsten wichtigen Elemente sein (und kann durchaus zu den 60 % der Funktionen gehören, die nie oder nur selten verwendet werden).
Ist das perfekt? Nein. Andererseits hat eine Harvard Business Review-Studie gezeigt, dass jedes sechste IT-Projekt eine Kostenüberschreitung von 200 % oder mehr aufweist. Mit einem agilen Projekt werden Sie das Budget nicht überschreiten. Sie können einfach nicht alles versenden, was Sie geplant haben, und wenn Sie nachhaken, stellen Sie möglicherweise fest, dass dies völlig in Ordnung ist.
Einen guten HBR-Artikel zur Budgetierung in Agile finden Sie hier: https://hbr.org/2014/12/your-agile-project-needs-a-budget-not-an-estimate
Eine Möglichkeit, darüber nachzudenken, ist die Verwendung der klassischen Kurve „Genauigkeit vs. Aufwand“. Sicher, Sie können viel Zeit mit der Planung im Voraus verbringen, aber Sie werden schnell abnehmende Ergebnisse bei der Genauigkeit erzielen und werden definitiv Zeit damit verschwenden, Dinge zu planen, die es nicht in das Endprodukt schaffen (und sich selbst weit entlang der Kurve platzieren).
Oder Sie können eine agile Denkweise annehmen und gerade genug planen, um loszulegen, auch wenn dies eine Budgetspanne oder einen flexiblen Umfang bedeutet, wie Joel erwähnt hat (niedriger auf der Kurve sein, aber akzeptieren, dass sie um einige % nach oben oder unten gehen könnte).
In meiner Praxis werden agile Projekte genauso aufgesetzt und budgetiert wie die regulären. Wir haben einen Business Case / High-Level-Umfang, auf dessen Grundlage wir eine vorläufige Schätzung für Kosten und Zeitplan erstellen, diese mit unseren bisherigen Erfahrungen (oder früheren Projektkennzahlen) vergleichen und in der Projektcharta dokumentieren.
Die meisten agilen Methoden decken nicht den gesamten Projektlebenszyklus ab, sodass agile Projekte auf hoher Ebene (z. B. auf der obersten Managementebene) genauso sind wie Projekte, die auf traditionellere Weise ausgeführt werden. Aus Gründen des Erwartungsmanagements ist es natürlich gut, die Methodik zu kommunizieren (damit sie Umfangsänderungen verstehen und sogar antizipieren).
Bei der Schätzung agiler Projekte kann es einen wesentlichen Unterschied geben: Es ist normalerweise ein sehr schlechtes Setup, wenn Sie nur Zeit / Budget für obligatorische Anforderungen haben, also entweder einige optionale in den anfänglichen Umfang aufnehmen oder einen großen (30-40% bzw noch mehr) Reserve für zusätzliche Funktionen, die später kommen können. Auf diese Weise ist Ihr Team (Product Owner usw.) in der Lage, Umfangsänderungen flexibel zu handhaben.
Sie müssen die treuhänderische Anleitung haben, während Sie ein Budget für einen Wertstrom zuweisen. Sobald Sie die Wertstromebene erreicht haben, können Sie die Geschichten schätzen und die Funktionen und Fähigkeiten dimensionieren
Firooz