为什么斐波那契数列用于敏捷计划扑克？
在评估敏捷软件开发中用户故事的相对规模时，团队成员应该估计用户故事的大小为1,2,3,5,8,13 ……。 所以估计值应该类似于斐波那契数列。 但是我想知道，为什么？
维基百科上http://en.wikipedia.org/wiki/Planning_poker的描述包含着神秘的句子：
使用斐波纳契数列的原因是为了反映估计较大项目的内在不确定性。
但是为什么大项目应该有固有的不确定性呢？ 如果我们减less测量的话，难道不是不确定性更高，这意味着如果更less的人估计同样的故事？ 即使大型故事中的不确定性较高，为什么这意味着使用斐波纳契数列呢？ 是否有math或统计的原因呢？ 否则，使用斐波那契数列进行估算，对我来说就像货讯科学一样。
斐波那契数列只是指数估计量表的一个例子。 使用指数规模的原因来自信息理论。
我们从估计中获得的信息比估计的精度要慢得多。 实际上它是作为对数函数增长的。 这是大型项目不确定性较高的原因。
确定指数规模（归一化）的最优基础在实践中是困难的。 对应于斐波纳契尺度的基数可能是最优的也可能不是最优的。
这是math理由的更详细的解释： http : //www.yakyma.com/2012/05/why-progressive-estimation-scale-is-so.html
在斐波纳契数列的前六个数字中，有四个是素数。 这限制了将任务平等分解为更小的任务的可能性，以使多个人平行地工作。 这样做可能会导致一个错误的观念，认为任务的速度可以与工作的人数成比例地扩大。 2 ^ n系列最容易出现这样的问题。 斐波那契数列事实上迫使人们逐一重新估计较小的任务。
根据这个敏捷博客
“因为它们的增长速度大致与我们人类可以感知到的幅度有意义的变化的速度相同。”
是的。 我认为这是因为他们增加了一个合法性（斐波那契math！）本质上是一个非常高层次，早期的规模（而不是范围）的运动（这确实有价值）。
但是，使用T恤大小可以得到相同的结果…
你绝对想要一些指数的东西，这样你就可以用一个相对常量来表示任何时间量。 你估计的精确度很可能与你的估计成正比。
所以你想要的东西：a）整数b）指数c）简单
现在为什么是斐波那契而不是1 2 4 8？ 我的猜测是，这是因为斐波那契越来越慢。 这是在goldratio ^ n，goldratio = 1.61 …
斐波那契序列只是项目计划扑克中使用的几个之一。
如果你的数字过于“现实”，就很难准确地估算出大量的工作单位，并且很容易在数小时内陷入困境。
我使用斐波那契有几个原因：
- 随着任务越来越大，细节变得越来越难以掌握
- 任务估计值是团队中任何人完成任务的小时数
- 不是团队中的每个人都有相同的经验来完成特定的任务，这也增加了不确定性
- 人类通过更大和更复杂的任务而疲劳。 虽然两倍复杂的任务可以在双倍的时间内解决，但对于一个开发者来说可能要花费更多的时间。
当我们把所有的不确定性加起来的时候，我们就不太确定实际的时间应该是多less。 如果我们只能估计这个任务是否比另一个已经估计的任务更大/更小，结果会更容易。 随着任务的规模/复杂性的增加，不确定性的影响也被放大。 我会乐于以13小时的时间估计一个任务，这个任务似乎是我以前估计的5个小时的两倍。
