アジャイルソフトウェア開発におけるユーザーストーリーの相対的なサイズを推定する場合、チームのメンバーは、ユーザーストーリーのサイズを1、2、3、5、8、13、...と推定することになっています。したがって、推定値はフィボナッチ数列に似ているはずです。しかし、なぜだろうか?
ウィキペディアの http://en.wikipedia.org/wiki/Planning_poker の説明には、不思議な文が含まれています。
フィボナッチ数列を使用する理由は、より大きな項目を推定する際の固有の不確実性を反映するためです。
しかし、大きなアイテムに固有の不確実性があるのはなぜですか?測定を少なくすれば、つまり、同じストーリーを推定する人が少なくなると、不確実性は高くなりませんか?そして、たとえ大きなストーリーで不確実性がより高い場合でも、フィボナッチ数列の使用を意味するのはなぜですか?数学的または統計的な理由はありますか?そうでなければ、フィボナッチ数列を推定に使用することは、CargoCult科学のように感じます。
フィボナッチ数列は、指数推定スケールの一例です。指数スケールが使用される理由は、情報理論に由来します。
推定から得られる情報は、推定の精度よりもはるかに遅くなります。実際、それは対数関数として成長します。これは、大きなアイテムの不確実性が高い理由です。
指数スケールの最適なベース(正規化)を決定することは、実際には困難です。フィボナッチスケールに対応するベースは、最適である場合とそうでない場合があります。
数学的な正当性のより詳細な説明は次のとおりです。 http://www.yakyma.com/2012/05/why-progressive-estimation-scale-is-so.html
フィボナッチ数列の最初の6つの数のうち、4つが素数です。これにより、タスクをより小さなタスクに均等に分割して、複数の人が並行して作業する可能性が制限されます。これを行うと、タスクの速度が作業中の人数に比例して拡大する可能性があるという誤解を招く可能性があります。 2 ^ nシリーズは、このような問題に対して最も脆弱です。実際、フィボナッチ数列は、小さなタスクを1つずつ再評価することを強制します。
this agile blog によると
「私たち人間が大きさの意味のある変化を知覚できるのとほぼ同じ速度で成長するからです。」
ええ、その通り。それは、本質的に非常に高レベルの初期段階のサイジング(スコーピングではない)エクササイズ(価値がある)に正当性(フィボナッチ!数学!)の空気を追加するためだと思います。
しかし、Tシャツのサイジングを使用しても同じ結果を得ることができます...
一定の相対誤差で任意の時間を表現できるように、必ず指数関数的なものが必要です。推定の精度も、推定に比例する可能性が非常に高くなります。
だからあなたは何かが欲しい:a)整数b)指数関数c)簡単
では、なぜ1 2 4 8ではなくフィボナッチなのでしょうか?私の推測では、フィボナッチの成長が遅いためだと思います。 goldratio ^ nにあり、goldratio = 1.61 ...
フィボナッチ数列は、プロジェクトプランニングポーカーで使用されるいくつかの例の1つにすぎません。
大きな作業単位を正確に見積もることは難しく、数値が「現実的」すぎると、数時間対数日間の議論で行き詰まってしまいがちです。
http://www.agilelearninglabs.com/2009/06/story-sizing-a-better-start-than-planning-poker/ の説明が好きです。つまり、フィボナッチシリーズはセットを表します異なる大きさとしてそれらを直感的に区別できる数の。
フィボナッチを使用する理由はいくつかあります。
すべての不確実性を合計すると、実際に何時間であるべきかがわかりません。このタスクが既に推定した別のタスクよりも大きいか小さいかを測定することができれば、簡単に終わります。タスクのサイズ/複雑さを上げると、不確実性の影響も増幅されます。幸いなことに、以前は5時間で見積もったタスクの2倍の大きさのタスクに対して、13時間の見積もりを取っています。