Wie erstellt man realistische langfristige Zeitschätzungen bei der Einführung der agilen Methodik?

Schätzen Sie Story Points und wenden Sie einen Geschwindigkeitsbereich an

Hier ist die vereinfachte Arithmetik:

• Sie verwenden die Geschwindigkeit (in Story Points) als Maß dafür, wie viel Arbeit Sie in einer Zeiteinheit (Sprint) erledigen können.
• Sie schätzen die Größe des Projekts in Story Points.
• Anhand dieser beiden Zahlen können Sie abschätzen, welche Verpflichtungen Sie für die zukünftige Lieferung eingehen können. Sie können zum Beispiel so etwas sagen wie: „Ich habe 5 Sprints an Arbeit auf der Hand (bereits zugesagt). Dieses neue Projekt, über das verhandelt wird, umfasst 2 Sprints an Arbeit. Ich denke also, ich kann mich dazu verpflichten, diese 7 Sprints zu liefern in."

Um dieses einfache Modell umzusetzen, gibt es jedoch viele Voraussetzungen:

1. Sie benötigen Geschwindigkeitszahlen über einen angemessenen Zeitraum. Das Minimum sind drei Sprints, mehr werden bevorzugt. Selbst wenn Sie Geschwindigkeitszahlen über mehrere Sprints haben, wird empfohlen, eher einen Bereich als eine genau aussehende Zahl zu verwenden ("Unsere Geschwindigkeit liegt zwischen 25 und 35 Punkten.").

2. Der schwierigere Teil besteht darin, die Story Points für neue Projekte abzuschätzen, die verhandelt werden:

   • Möglicherweise haben Sie nicht genügend Details, um Story Points gut einschätzen zu können. In einem meiner früheren Unternehmen hatten wir zu diesem Zeitpunkt nur einige Stichpunkte. Diese könnten vielleicht zu Epen werden.
   • Sie wissen vielleicht bereits, dass in Scrum die Story Points von dem Team geschätzt werden sollten, das die Arbeit tatsächlich erledigt. Vorzugsweise mit einem Verfahren wie Planning Poker. Selbst wenn genügend Details verfügbar sind, um die Geschichten zu schreiben, ist das Entwicklerteam möglicherweise damit beschäftigt, die heutigen Brände zu löschen. Und möglicherweise nicht in der Lage sein, die Zeit zu erübrigen, Planning Poker für ein Projekt in der Zukunft zu betreiben. Meiner Erfahrung nach liefert Planning Poker sehr gute Ergebnisse, ist aber sehr langsam.

Hoffentlich hilft dies, Sie in die richtige Richtung zu weisen. Hier ist ein Link, der Sie zu zusätzlichem Material zu diesem Thema führen kann: Agile Estimating and Planning

Zunächst einmal, warum führen Sie Agile ein ?

Denken Sie daran, dass Agile eine Methodik ist und wie jede Methodik ein Mittel ist, um ein Ergebnis zu erzielen . Ich kann mich irren, aber wenn Sie erwarten, dass Agile alle Ihre Probleme löst, nur weil Sie agil sind, werden Sie eine schlechte Zeit haben . Möglicherweise behandeln Sie ein Symptom, ohne sich mit der Krankheit auseinanderzusetzen. Wenn Sie versuchen, nur auf Ihrer IT-Seite agil zu werden und die gleichen alten Vereinbarungen mit Ihren Stakeholdern einzuhalten, können Sie sich in eine sehr komplexe Situation bringen. Oder Sie können nicht. Aber seien Sie vorbereitet, es könnte nicht einfach sein.

Abgesehen davon besteht Ihre Aufgabe darin, Erwartungen zu managen . Wie schätzt man große Projekte ein? Du nicht. Wenn Sie agil werden, können Sie den langfristigen Plan in kleinere Teile aufteilen und diese kleineren Ergebnisse agil behandeln, wodurch Sie Ihren Stakeholdern mehr Sicherheit und Vertrauen bieten können. Sie geben eine hohe Vertrauensschätzung für die ersten Ergebnisse ab und geben dann weitere Schätzungen mit weniger Vertrauen für zukünftige Ergebnisse ab. Unnötig zu erwähnen, dass Schätzungen KEINE Termine sind, zu denen sich Ihr Team verpflichtet . Sie geben einen Überblick über den erforderlichen Aufwand. Je weniger Vertrauen, desto größer die Abweichung von den gegebenen Schätzungen.

Diese Projekte haben wahrscheinlich je nach Stakeholder unterschiedliche Ansichten. In meinem Fall bin ich es gewohnt, mit meinem IT-Team ein Kanban-Board zu verwenden und das Gantt beizubehalten, um „die gleiche Sprache zu sprechen“ wie die Interessenvertreter des Unternehmens . Sie interessieren sich nur für zwei Dinge: ob wir auf dem richtigen Weg sind und wann wir fertig sind ... und in diesem Fall gibt ihnen das Gantt ein bisschen Trost (wie sie es gewohnt sind). Aber noch einmal, wenn Sie vollständig agil arbeiten, könnten Sie mithilfe von Burndown-Diagrammen eine ähnliche Ansicht bieten ... Ich würde nur sicherstellen, dass dieser "Übergang" inkrementell erfolgt, um große Auswirkungen (und Angst vor dem Unbekannten) zu vermeiden.

Haftungsausschluss: Ich bin ein agiler Neuling (mein Projekt ist nicht einmal agil, wie Sie sehen, verwende ich Kanban), also nehmen Sie meinen Rat mit Vorsicht an.

Erfolg!

Dies sind nicht so sehr Fragen zu agilen Methoden, sondern zu Schätzfähigkeiten im Allgemeinen. Wenn Sie für eine Minute außerhalb der IT denken, was wäre, wenn Sie ein Ölunternehmen wären, das versucht zu entscheiden, ob es Gasfelder anstelle von Ölfeldern ausbeuten soll, basierend darauf, wie sich der Ölpreis in den nächsten 40 Jahren entwickeln könnte? Oder vielleicht arbeiten Sie für eine Regierungsbehörde, die die Nachfrage nach ihren Dienstleistungen in fünf Jahren abschätzen muss? Oder für einen Versicherer, der die beste Prämie für einen besonders riskanten, aber hochkarätigen Neukunden ermitteln muss (wie eine Lebensversicherungspolice für Evel Kniebel).

All diese Entscheidungen beinhalten ein gewisses Maß an Ungewissheit, aber diese Unternehmen haben einen bewährten Ansatz zur Quantifizierung und zum Umgang mit dieser Ungewissheit – probabilistische Risikoschätzung. Wenn Sie mehr darüber erfahren möchten, wäre ein guter Ausgangspunkt ein Buch mit dem Titel „How to Measure Anything – Finding the Value of Intangibles in Business“ von Doug Hubbard. Ich bin vor ein paar Jahren über dieses Buch gestolpert, als ich bei einer großen Ölgesellschaft gearbeitet habe, und es war eine absolute Offenbarung. Ich versuche, seine Prinzipien anzuwenden, wann immer es mir erlaubt ist, weil ich dadurch viel genauere Schätzungen erstellen kann als die Menschen um mich herum!

Die Techniken erfordern eine gewisse Anwendung grundlegender statistischer Analysen und Monte-Carlo-Simulationen, aber Doug erklärt das ziemlich gut in dem Buch, also ist es nichts, wovor man sich fürchten muss. Ich bekomme jedoch viel Widerstand von meinen IT-Kollegen, wenn ich versuche, diese Methoden in die IT-Schätzung einzuführen, seien Sie also darauf vorbereitet. Faszinierend ist, wenn diese Leute im selben Gebäude wie die Nicht-IT-Schätzer im Unternehmen arbeiten, aber darauf bestehen, dass probabilistische Techniken nicht auf IT-Projekte angewendet werden können (völlig unbewusst der Tatsache, dass sie auf die viel größeren und kleineren angewendet werden bestimmte Einschätzungen/Entscheidungen des Kerngeschäfts, weil es einfach nicht anders geht!).

Re: Software, schau dir Oracle Crystal Ball oder Palisade Decision Tools an - Decision Tools ist viel schöner und hat eine MS Project Integration, kostet aber auch etwa das 5-fache. Aber das ist immer noch ein winziger Preis im Vergleich zu den potenziellen Einsparungen für jemanden in Ihrer Situation. Die Ölgesellschaft, bei der ich gearbeitet habe, nutzt Crystal Ball stark – so ziemlich jede Kerngeschäftsentscheidung wird damit modelliert.