Wir wollen unseren Ansatz für Schätzungen ändern. Jetzt schätzen wir in Stunden/Tagen, aber wir würden dies gerne ändern und unseren Prozess flexibler gestalten. Wir arbeiten auf Basis von Scrum, wo Stories basierend auf einer anfänglichen Schätzung geplant werden und nach der technischen Analyse eine neue Schätzung verwendet werden kann (die verfeinert ist).
Da wir festgestellt haben, dass unser Schätzprozess verbessert werden kann, suchen wir nach Alternativen. Ich habe bereits online eine Dokumentation gefunden, in der es darum geht, Story Points und Geschwindigkeit zu verwenden, um den Aufwand anzugeben, der erforderlich ist, um etwas zu implementieren.
Gibt es neben Story Points/Velocity noch Alternativen? Ich habe online gesucht, aber ich finde keine guten Quellen mit Alternativen.
Für mich klingt es so, als wollten Sie Ihre Schätzgenauigkeit verbessern – nicht flexibler machen. Deshalb hier ein paar Hinweise.
Je früher Sie im Projekt sind, desto ungenauer wird Ihre Schätzung sein. Der Unsicherheitskegel veranschaulicht dies, indem er bei einer Streuung von 0,25x bis 4x beginnt und langsam auf den Faktor 1 konvergiert. Dies ist die maximale Genauigkeit, die Sie von Ihren Schätzungen erwarten können. Dh. Wenn Sie anfangen, können Sie mit Ihrer Schätzung nicht genauer sein - Sie können nur mehr Glück haben.
Ich spreche das an, weil Ihre Fragen für mich so klingen, als würden Sie Geschichten basierend auf der ursprünglichen Schätzung priorisieren, ohne eine Verfeinerung zu berücksichtigen. Ich könnte mich diesbezüglich aber irren.
Anstatt Einzelpunktschätzungen bereitzustellen, bieten Sie Bereiche an. Beginnen Sie mit der Schätzung des absoluten Worst-Case-Szenarios für Ihre Obergrenze. Schätzen Sie dann das "wahrscheinliche" Szenario für Ihre Untergrenze. Versuchen Sie, beide Schätzungen so festzulegen, dass Sie sich zu 90 % sicher sind, dass Sie richtig liegen. Das bewirkt zweierlei: Die Betrachtung des schlimmsten Falls bringt Sie zuerst auf die Spur, was schief gehen kann, und bewahrt Sie davor, zu viele Risiken einzugehen. Zweitens, indem Sie sich dazu zwingen, Ihre Schätzungen auf einen extremen Konfidenzbereich von 90 % auszudehnen, haben Sie eine Chance von mindestens 30 %, richtig zu liegen.
Vermeiden Sie nach Möglichkeit absolute Schätzungen und versuchen Sie, die Positionen in Relation zueinander zu schätzen. Verwenden Sie dann die Geschwindigkeit, um die Menge der abgeschlossenen Aufgaben pro Sprint in Relation zu den Schätzungen zu setzen, die Sie darauf setzen. Sie KÖNNEN dies mit Stunden tun, wenn Sie möchten. Es kommt einfach natürlicher, wenn man es mit Punkten macht. Um ein gewisses Maß an Zuverlässigkeit zu bewahren, müssen Sie außerdem davon absehen, Ihre relativen Gewichte zu ändern. Wenn Sie Ihren ersten Sprint auf der Grundlage schätzen, dass Aufgabe X Y Stunden/Punkte sind, und dann nach dem Sprint auf Ihre Geschwindigkeit schauen und sagen: „Aha! Wir waren um den Faktor 2,375 daneben. schießen Sie sich selbst in den Fuß.
Es gibt im Wesentlichen drei Ansätze, die Sie wählen können, wenn Sie einen Steinhaufen bewegen müssen:
Montecarlo-Simulationen .
Die Idee ist ziemlich einfach. Ihre Geschichten in den vergangenen Wochen haben eine Art Verteilung, wie lange sie jeweils gedauert haben. Nehmen wir an, die Geschichten haben jeweils diese Anzahl von Tagen gebraucht, bis die nächste Geschichte fertig war:
3, 2, 5, 4, 1, 2, 3, 10, ...
Diese folgen oft einer sogenannten Weibull -Verteilung, die in Richtung eines großen, fetten Schwanzes verzerrt ist, da die meisten Entdeckungen Sie mehr verlangsamen als beschleunigen. (Die menschliche Intuition neigt dazu, eine Normalverteilung anzunehmen, was einer der Gründe ist, warum wir normalerweise optimistisch sind.)
Manchmal sind diese Distributionen jedoch bimodal (es gibt zum Beispiel ein altes System, das jede Geschichte verlangsamt, die es berührt) oder einfach nur chaotisch (niemand checkt an einem Freitag ein, weil er den Build nicht beschädigen möchte). Das Gute an Monte-Carlo-Simulationen ist ... es spielt keine Rolle! Es funktioniert unabhängig von Ihrer Distribution.
Die Art und Weise, wie Sie dies tun, besteht darin, eine zufällige Reise durch die Geschichten zu berechnen, die Sie hinterlassen haben, und herauszufinden, wann diese Reise endet. Sagen wir also, ich schätze, ich habe noch 60 Geschichten übrig. Für jede Geschichte werde ich zufällig aus Ihrer Verteilung auswählen, wie lange es zwischen den Geschichten gedauert hat.
1, 5, 4, 10, 3, 2, 10, 2, 5...
Und das machst du so lange, bis alle 60 Geschichten fertig sind. Addieren Sie nun die Anzahl der Tage, die es gedauert hat, zum Startdatum ...
...und dann nochmal.
Machen Sie es 1000 Mal oder öfter (ja, Sie brauchen dafür eine Software oder eine spezielle Tabellenkalkulation). Es spielt keine Rolle, ob diese seltsame "10" zweimal ausgewählt wird, da dies nicht bei jeder Fahrt der Fall ist. Einige werden seltsam langsam sein, aber die meisten werden schneller sein. Notieren Sie die Enddaten für jede Fahrt.
Jetzt haben Sie etwas mehr als eine Schätzung. Sie haben eine Wahrscheinlichkeitsprognose . Wenn ich also am 1. Januar 2018 beginne, bekomme ich vielleicht so etwas wie:
100% 10-04-2018
95% 03-04-2018
90% 29-03-2018
85% 25-03-2018
usw.
Jedes dieser Daten zeigt, wie viel Prozent der Fahrten Sie bis zu diesem Datum beendet haben. Dies gibt Ihnen eine Vorstellung von der Wahrscheinlichkeit , ein bestimmtes Datum mit all den Geschichten zu treffen. Alternativ können Sie sehen, wie viele Geschichten Sie bis zu einem bestimmten Datum fertig haben, indem Sie einfach zählen, bis das Datum erreicht ist.
Die meisten Leute sind wirklich optimistisch, wenn sie schätzen, und Sie können sich glücklich schätzen, wenn Sie sogar 50 % der Reisen erreichen, die bis zu diesem Datum enden!
Troy Magennis von Focused Objective hat kostenlose Tabellenkalkulationen für solche Dinge, und das Tool von Dan Vacanti von Actionable Agile ist billig genug und meines Erachtens ausgezeichnet. Beide haben auch zahlreiche Videos, die über die Technik sprechen. Ich habe auch ein Open-Source-Projekt , das noch keine Validierung hat, aber gut genug für den Import von Excel-Tabellen funktioniert, einschließlich Exporte aus Jira.
Troy empfiehlt Daten zwischen 7 und 25 Wochen, um dies zum Laufen zu bringen; mehr als das ist normalerweise veraltet. Denken Sie jedoch an saisonale Muster.
Wahrscheinlichkeitsschätzungen
Wenn Sie sich den Ärger von Montecarlo nicht antun wollen, aber die Wahrscheinlichkeitsverteilung wollen, könnte Ihnen eine Technik helfen, die ich von Douglas Hubbard, dem Autor von „How to Measuring Anything“, gelernt habe.
Ich bitte das Team, mir eine Vorstellung davon zu geben, wann sie voraussichtlich versenden werden. Normalerweise sind sie sehr optimistisch, wenn es also Anfang Januar ist, sagen sie "Ende April" oder so ähnlich.
Dann frage ich sie, wie wahrscheinlich sie dann versenden werden. „Oh, 70 %“, sagen sie mir.
Also biete ich ihnen einen hypothetischen Preis von 10.000 £ und zwei verschiedene Möglichkeiten, ihn zu gewinnen. Sie können entweder eine rote Murmel aus einem Beutel mit 7 roten und 3 weißen Murmeln auswählen oder bis Ende April versenden.
Sie gehen normalerweise für die Murmeln; Obwohl sie sagen, dass sie zu 70 % sicher sind, dass sie versendet werden, bevorzugen sie die Chancen, 7 von 10 Murmeln zu ziehen!
Also reduzieren wir die Anzahl der Murmeln in unserer hypothetischen Tasche, bis sie lieber versendet werden. Das sagt uns, wie hoch ihr wahres Selbstvertrauen ist. Indem wir dies mit einer unterschiedlichen Anzahl von Murmeln tun, können wir eine Reihe unterschiedlicher Vertrauensniveaus erhalten.
Wie man diese benutzt
Wenn Sie in irgendeiner Weise vom Versanddatum abhängig sind, verwenden Sie nichts weniger als 85 % Vertrauen. Das ist normalerweise ein Ausweg im Vergleich zu den Schätzungen der meisten Leute. Wenn das Datum näher rückt, können Sie sehen, ob Sie es schaffen oder nicht, und Sie haben immer noch die Möglichkeit, die Dinge zu beschleunigen oder andere Abhängigkeiten zu verschieben, falls erforderlich.
Beachten Sie, dass das Unternehmen nicht glücklich sein wird ... bis sie anfangen, die Zeitersparnis zu sehen, die dadurch entsteht, dass sie keine leicht spielbaren Story-Punkte einschätzen und nicht eine Menge Pläne wiederholen müssen, die auf etwas basieren, das sowieso nie passieren würde. Möglicherweise müssen Sie ein wenig Aufklärung betreiben oder durch knifflige Politik navigieren, bis sie die Realität akzeptieren.
Keine Schätzungen
Es gibt ziemlich starke Bewegungen gegen die Erstellung von Schätzungen. Im Gegensatz zum Namen bedeutet dies nicht, dass Sie keine Schätzungen erstellen, sondern nur, dass Sie keine Schätzungen erstellen und veröffentlichen.
Wie es funktioniert
Zuerst sollte sich das Team auf eine Geschichte mit "durchschnittlicher" Größe einigen. Sie würden eine Richtlinie wie „Wir sollten in der Lage sein, 5 bis 8 dieser Geschichten in einem Sprint zu erledigen.“ verwenden. Es ist hilfreich, 2 oder 3 Beispiele früherer Artikel zu haben, die ungefähr diese Größe haben.
Da Sie nun eine ungefähre Zielgröße haben, zerlegen Sie größere Elemente, bis sie in etwa der Größe entsprechen. Die Idee dabei ist, dass dieser Prozess der Größenschätzung die nützlichen Gespräche im Team verdrängt, die das Erstellen von Schätzungen tut, aber da es keine resultierenden Schätzungszahlen gibt, vermeidet es viele der Funktionsstörungen und Probleme, die durch die Veröffentlichung von Schätzungen entstehen können.
Die gute Nachricht für Product Owner und Stakeholder ist, dass Prognosen immer noch einfach sind. Wenn das Team durchschnittlich 5 - 8 Backlog-Items pro Sprint abschließt, können Sie gut abschätzen, wie viele Sprints es braucht, um an eine bestimmte Stelle im Backlog zu gelangen.
Wenn Sie Scrum praktizieren, sollten Sie sich für Story Points entscheiden. Die Gründe sind:
Lassen Sie mich versuchen, Ihre Frage zu beantworten:
Jetzt schätzen wir in Stunden/Tagen, aber das würden wir gerne ändern... Gibt es neben Story Points/Velocity noch Alternativen?
In ausgereiften Branchen werden grobe Schätzungen auf der Grundlage des Outputs vorgenommen:
Obwohl Scrum Guide Story Points nicht erwähnt, ist Jeff Sutherland, der Mitbegründer von Scrum, ein großer Befürworter von Story Points . Eine der größten Schwächen von Scrum ist, dass es einige Maßeinheiten für den Aufwandseingang gibt, aber keine Maßeinheit für die Ergebnisausgabe.
Es gibt gut etablierte Organisationen, Standards, Tools und Zertifizierungen für Function Point, was ein Maß für die Leistung ist:
Organisationen : In den USA ist es die IFPUG International Function Point Users Group und in Europa NESMA und FISMA Finnish Software Measurement Association .
Standards : Sie können die ISO/IEC-Standards auf der Wikipedia-Funktionspunktseite sehen .
with no attempt to measure the result output.
ich denke, dass die INVEST-Kriterien (nicht Scrum, aber oft eine solide Praxis) und die Sprint-Review-Funktion "testbar" sind, um die Output-Bewertung innerhalb des Frameworks bereitzustellen, aber ich stimme sicherlich zu, dass der Schätzungsprozess selbst ist primär Input-getrieben durch Design. Sehr gute Punkte, Ashok!Gibt es neben Story Points/Velocity noch Alternativen?
Sie können in jeder Einheit schätzen, die Sie messen möchten. Übliche Messungen umfassen Zeit, Aufwand, Geld und kalenderbasierte Ziele.
Die drei Eckpunkte des ikonischen „Eisernen Dreiecks“ des Projektmanagements sind Umfang, Zeitplan und Ressourcen. Alle Projektkontrollen und Schätztechniken sollten eines oder mehrere dieser Elemente oder die Beziehungen zwischen ihnen ausdrücken.
Die meisten Projekte schätzen alle drei Eckpunkte, aber die grundlegende Theorie des modernen Projektmanagements besagt, dass Sie nur zwei der drei kontrollieren können. Umfang, Zeitplan und Ressourcen können nicht gleichzeitig festgelegt werden; Mindestens einer der drei muss sich beugen.
Beispielsweise könnten Sie die Ressourcen und den Zeitplan eines Projekts schätzen, um den Umfang zu erreichen. Sie können auch den Umfang und den Zeitplan abschätzen, um zu den Ressourcen zu gelangen. Im Allgemeinen ist das Geschäft jedoch am häufigsten damit beschäftigt, wann ein Projekt geliefert werden kann, sodass Zeit und Aufwand als primäre Schätzungstechniken oft am sinnvollsten sind. Das bedeutet jedoch nicht, dass sie der einzige Ansatz sind.
Einige warteschlangen- oder zyklusbasierte Methoden beinhalten überhaupt keine einheitenbasierte Schätzung. Während Kanban beispielsweise oft viele Metriken bereitstellt, die für die Nachverfolgung, Release-Planung und Prozessverbesserung nützlich sein können, werden einzelne Arbeitselemente nie explizit geschätzt.
Auch auf Einheitsebene werden verschiedene Arten von Arbeiten (z. B. Support oder Wartung) häufig nicht geschätzt. Sie können solche Arbeit als Warteschlange, Ringpuffer oder Bucket ausdrücken, aber letztendlich sind dies alles nur Möglichkeiten, Arbeit auf der Makroebene und nicht auf der Ebene der Arbeitseinheiten zu planen oder zu budgetieren.
Wenn Sie Schätzungen ganz vermeiden möchten, können Sie sich die #NoEstimates-Bewegung ansehen . Ron Jeffries hat jedoch einige interessante Gedanken dazu, die meiner Meinung nach gelesen werden müssen, bevor Sie auf diesen speziellen Zug aufspringen.
Sie müssen Ihr Projekt innerhalb einiger grundlegender Parameter bewerten und kontrollieren, und Zeit und Aufwand sind zwei der häufigsten. Wenn Sie von der Schätzung der Arbeitsstunden oder des Aufwands wegkommen möchten, können Sie dies sicherlich tun. Ich würde jedoch einige Zeit damit verbringen, Ihren Business Case dafür sorgfältig zu evaluieren. Das könnte Ihnen helfen, eine bessere Metrik zu finden oder ein X/Y-Problem aufzudecken, das die Suche nach einer Alternative vorantreibt. In jedem Fall ist es im Allgemeinen gut investierte Zeit, sich die Zeit zu nehmen, Ihre Annahmen und Ihren Prozess zu überprüfen!
Meines Wissens "nein".
Zeitschätzungen sind die intuitive Methode der Schätzung. Manager wollen wissen, wie lange X brauchen wird. Intuitive Lösung? Fragen Sie, wie lange X brauchen wird.
Es gibt jedoch Probleme mit diesem Ansatz. Zum einen hängt die Zeit, die zum Ausführen von X benötigt wird, davon ab, wer X abschließt. Zum anderen sind Menschen schlecht darin, Zeit einzuschätzen. So entstanden Story Points, eine Form des Schätzens in relativem Aufwand. Sie haben sich seitdem als alles andere als genau herausgestellt. Sie können durch Anwenden der Geschwindigkeit des Teams in Zeit umgewandelt werden.
Ich glaube nicht, dass es eine andere Methode gibt, vor allem, weil ich nicht sehe, was sonst zuverlässig verwendet werden könnte. Ich sehe auch keine Notwendigkeit. Wenn Sie einen Prozess schnell definieren müssen und keine Zeit zum Nachdenken aufwenden möchten/können, schätzen Sie die Zeit ein. Wenn Sie eine genauere Methode wünschen, verwenden Sie Story Points.
Bearbeiten: Zum Zeitpunkt des Schreibens hatte ich die Methode „keine Schätzungen“ vergessen. Obwohl man technisch sagen könnte, dass eine solche Methode dasselbe wie Story Points ist, wird nur jeder Aufgabe der gleiche Aufwand gewidmet. Es könnte sogar ein Kontinuum geben, mit Ansätzen wie dem, bei dem jede Aufgabe bis auf seltene Ausreißer gleich geschätzt wird. Dies ist der Ansatz, zu dem sich mein letztes Team entwickelt hat – fast jede Story war 1 Punkt, mit der gelegentlichen 0,1- oder 3-Punkte-Story.
nvoigt
Daniel
Todd A. Jacobs