为什么斐波那契数列在敏捷规划扑克中使用？[关闭]

在敏捷软件开发中估计用户故事的相对大小时，团队成员应估计用户故事的大小为1、2、3、5、8、13...。因此，估计值应类似于斐波那契数列。但是我想知道，为什么？

Wikipedia上对http://en.wikipedia.org/wiki/Planning_poker的描述包含一个神秘的句子：

使用斐波那契数列的原因是为了反映估计较大项目时固有的不确定性。

但是，为什么较大的物品应该存在固有的不确定性？如果我们进行较少的测量，也就是说，如果更少的人估计相同的故事，不确定性是否会更高？即使较大故事中的不确定性较高，为什么还要暗示斐波那契数列的使用呢？是否有数学或统计原因？否则，使用斐波那契数列进行估计对我来说就像是CargoCult科学。

斐波那契数列只是指数估计量表的一个例子。使用指数标度的原因来自信息论。

我们从估计中获得的信息的增长速度远慢于估计的精度。实际上，它是作为对数函数增长的。这就是较大项目不确定性较高的原因。

在实践中，很难确定指数尺度的最佳基数（规范化）。对应于斐波那契量表的基准可能是最佳的，也可能不是最佳的。

这是对数学证明的更详细说明：http : //www.yakyma.com/2012/05/why-progressive-estimation-scale-is-so.html

在斐波那契数列的前六个数字中，有四个是质数。这限制了将任务平均分解为较小任务以使多个人并行处理的可能性。这样做可能会导致误解，认为任务的速度可能与从事此任务的人数成比例。2 ^ n级数最容易受到此类问题的影响。实际上，斐波那契数列迫使一个人一个个地重新估计较小的任务。

根据这个敏捷博客

“因为它们的增长速度与人类感知到有意义的幅度变化的速度相同。”

是的，对。我认为这是因为它们在本质上是一种非常高级的，早期的规模确定（而非范围界定）练习（确实有价值），从而增加了合法性（Fibonacci！数学！）。

但是使用T恤尺码可以得到相同的结果...

您肯定想要指数级的东西，以便您可以用恒定的相对误差表示任意数量的时间。估算的精度也很可能与估算成正比。

因此，您需要：a）具有整数b）指数c）简单

现在为什么用斐波那契代替1 2 4 8？我的猜测是，这是因为斐波那契的增长速度较慢。在goldratio ^ n中，goldratio = 1.61 ...

斐波那契数列只是项目规划扑克中使用的数列之一。

如果您的数字过于“现实”，则很难准确估计大型工作单元，并且很容易陷入数小时或数天的讨论中。

我喜欢http://www.agilelearninglabs.com/2009/06/story-sizing-a-better-start-than-planning-poker/上的说明，即斐波那契数列代表了一组数字，我们可以直观地区分它们它们之间的大小不同。

我使用斐波那契有两个原因：

• 随着任务的扩大，细节变得更加难以掌握
• 任务估计是团队中任何人完成任务的小时数
• 并非团队中的每个人都会对特定任务拥有相同的经验，因此也增加了不确定性
• 人类会因更大且可能更复杂的任务而感到疲劳。对于计算机来说，虽然两倍完成一次复杂的任务就可以解决，但是对于开发人员来说，可能要花更多的时间。

当我们将所有不确定因素加总时，我们就不确定应该实际使用多少小时。如果我们仅能衡量此任务是否比我们已经估计过的另一任务大/小，则最终会更容易。随着我们增加任务的规模/复杂度，不确定性的影响也被放大。我会很高兴地花费13个小时来完成一项任务，这个任务似乎是我之前估计的5个小时的两倍。