Warum wird die Fibonacci-Serie beim agilen Planen von Poker verwendet?
Bei der Schätzung der relativen Größe von User Storys in der agilen Softwareentwicklung sollen die Mitglieder des Teams die Größe einer User Story mit 1, 2, 3, 5, 8, 13, ... schätzen. Die geschätzten Werte sollten also der Fibonacci-Reihe ähneln. Aber ich frage mich, warum?
Die Beschreibung von http://en.wikipedia.org/wiki/Planning_poker auf Wikipedia enthält den mysteriösen Satz:
Der Grund für die Verwendung der Fibonacci-Sequenz besteht darin, die inhärente Unsicherheit bei der Schätzung größerer Elemente widerzuspiegeln.
Aber warum sollte es bei größeren Artikeln Unsicherheiten geben? Ist die Unsicherheit nicht höher, wenn wir weniger messen, dh wenn weniger Menschen dieselbe Geschichte schätzen? Und selbst wenn die Unsicherheit in größeren Geschichten höher ist, warum impliziert das die Verwendung der Fibonacci-Sequenz? Gibt es einen mathematischen oder statistischen Grund dafür? Ansonsten fühlt es sich für mich nach CargoCult-Wissenschaft an, die Fibonacci-Serie für die Schätzung zu verwenden.
Die Fibonacci-Reihe ist nur ein Beispiel für eine exponentielle Schätzskala. Der Grund, warum eine Exponentialskala verwendet wird, stammt aus der Informationstheorie.
Die Information, die wir aus der Schätzung erhalten, wächst viel langsamer als die Genauigkeit der Schätzung. Tatsächlich wächst es als logarithmische Funktion. Dies ist der Grund für die höhere Unsicherheit bei größeren Artikeln.
In der Praxis ist es schwierig, die optimalste Basis der Exponentialskala (Normalisierung) zu bestimmen. Die Basis, die der Fibonacci-Skala entspricht, kann optimal sein oder nicht.
Hier ist eine detailliertere Erklärung der mathematischen Begründung: http://www.yakyma.com/2012/05/why-progressive-estimation-scale-is-so.html
Von den ersten sechs Zahlen der Fibonacci-Folge sind vier Primzahlen. Dies schränkt die Möglichkeiten ein, eine Aufgabe gleichermaßen in kleinere Aufgaben aufzuteilen, damit mehrere Personen gleichzeitig daran arbeiten können. Dies könnte zu dem Missverständnis führen, dass die Geschwindigkeit einer Aufgabe proportional zur Anzahl der Personen skaliert werden könnte, die daran arbeiten. Die 2 ^ n-Reihe ist für ein solches Problem am anfälligsten. Die Fibonacci-Sequenz zwingt tatsächlich dazu, die kleineren Aufgaben nacheinander neu einzuschätzen.
Laut dieses agile Blog
"weil sie ungefähr so schnell wachsen, wie wir Menschen bedeutende Größenänderungen wahrnehmen können."
Ja, genau. Ich denke, das liegt daran, dass sie eine gewisse Legitimität verleihen (Fibonacci! Mathe!), Was im Grunde genommen eine sehr anspruchsvolle Übung in einem frühen Stadium der Größenbestimmung (nicht des Scoping) ist (die Wert hat).
Mit T-Shirt-Größen können Sie jedoch die gleichen Ergebnisse erzielen ...
Sie wollen auf jeden Fall etwas Exponentielles, damit Sie jede Menge Zeit mit einem konstanten relativen Fehler ausdrücken können. Auch die Genauigkeit Ihrer Schätzung ist sehr wahrscheinlich proportional zu Ihrer Schätzung.
Sie möchten also Folgendes: a) mit ganzen Zahlen b) exponentiell c) einfach
Warum nun Fibonacci statt 1 2 4 8? Ich vermute, das liegt daran, dass Fibonacci langsamer wächst. Es ist in Goldverhältnis ^ n und Goldverhältnis = 1,61 ...
Die Fibonacci-Sequenz ist nur eine von mehreren, die bei der Poker-Projektplanung verwendet werden.
Es ist schwierig, große Arbeitseinheiten genau zu schätzen, und es ist leicht, sich in Diskussionen zwischen Stunden und Tagen zu verzetteln, wenn Ihre Zahlen zu "realistisch" sind.
Ich mag die Erklärung unter http://www.agilelearninglabs.com/2009/06/story-sizing-a-better-start-than-planning-poker/ , nämlich die Fibonacci-Serie repräsentiert eine Menge von Zahlen, die wir intuitiv als unterschiedliche Größen unterscheiden können.
Ich benutze Fibonacci aus mehreren Gründen:
- Je größer die Aufgabe wird, desto schwieriger werden die Details zu erfassen
- Die Aufgabenschätzung gibt die Anzahl der Stunden an, die jeder im Team benötigt, um die Aufgabe zu erledigen
- Nicht jeder im Team hat die gleiche Erfahrung für eine bestimmte Aufgabe, was die Unsicherheit ebenfalls erhöht
- Der Mensch wird müde wegen größerer und möglicherweise komplexerer Aufgaben. Während eine doppelt so komplexe Aufgabe für einen Computer in doppelter Zeit gelöst wird, kann sie für einen Entwickler erheblich länger dauern.
Da wir alle Unsicherheiten addieren, wissen wir nicht so genau, wie die Stunden eigentlich sein sollten. Es wird einfacher, wenn wir nur abschätzen können, ob diese Aufgabe größer/kleiner ist als eine andere, für die wir bereits eine Schätzung abgegeben haben. Mit zunehmender Größe/Komplexität der Aufgabe wird auch der Effekt der Unsicherheit verstärkt. Ich würde gerne eine Schätzung von 13 Stunden für eine Aufgabe annehmen, die doppelt so groß zu sein scheint wie eine, die ich zuvor auf 5 Stunden geschätzt habe.