アジャイルソフトウェア開発でユーザーストーリーの相対的なサイズを見積もる場合、チームのメンバーは、ユーザーストーリーのサイズを1、2、3、5、8、13、...と見積もることになっています。したがって、推定値はフィボナッチ数列に似ているはずです。しかし、なぜだろうか？
ウィキペディアのhttp://en.wikipedia.org/wiki/Planning_pokerの説明には、不思議な文章が含まれています。
フィボナッチ数列を使用する理由は、より大きなアイテムを推定する際の固有の不確実性を反映するためです。
しかし、なぜ大きなアイテムに固有の不確実性があるのでしょうか？測定を少なくする場合、つまり同じストーリーを推定する人が少ない場合、不確実性は高くなりませんか？そして、不確実性がより大きな物語でより高いとしても、なぜそれはフィボナッチ数列の使用を意味するのでしょうか？それには数学的または統計的な理由がありますか？それ以外の場合、推定にフィボナッチ数列を使用することは、私にはカーゴカルト科学のように感じます。
フィボナッチ数列は、指数推定スケールの一例にすぎません。指数スケールが使用される理由は、情報理論に由来します。
推定から得られる情報は、推定の精度よりもはるかに遅くなります。実際、それは対数関数として成長します。これが、大きなアイテムの不確実性が高い理由です。
指数スケール（正規化）の最適なベースを決定することは、実際には困難です。フィボナッチスケールに対応するベースは、最適な場合と最適でない場合があります。
数学的正当化のより詳細な説明は次のとおりです。http ：//www.yakyma.com/2012/05/why-progressive-estimation-scale-is-so.html
フィボナッチ数列の最初の6つの数のうち、4つが素数です。これにより、タスクをより小さなタスクに均等に分割して、複数の人が並行して作業できるようにする可能性が制限されます。そうすることで、タスクの速度がそれに取り組んでいる人の数に比例してスケーリングする可能性があるという誤解につながる可能性があります。2 ^ nシリーズは、このような問題に対して最も脆弱です。実際、フィボナッチ数列は、小さなタスクを1つずつ再推定することを強制します。
このアジャイルブログによると
「彼らは私たち人間が大きさの意味のある変化を知覚できるのとほぼ同じ速度で成長するからです。」
そうだね。それは、本質的に非常に高レベルの初期段階のサイジング（スコーピングではない）演習（価値がある）に正当性の空気（フィボナッチ！数学！）を追加するためだと思います。
しかし、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時間の見積もりを取ります。