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

【问题标题】：Why is the Fibonacci series used in agile planning poker? [closed]为什么在敏捷规划扑克中使用斐波那契数列？ [关闭]
【发布时间】：2012-03-10 20:41:06
【问题描述】：

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

维基百科对http://en.wikipedia.org/wiki/Planning_poker的描述中包含着神秘的一句话：

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

但是为什么较大的项目应该存在固有的不确定性？如果我们进行更少的测量，意味着如果更少的人估计相同的故事，不确定性不是更高吗？即使在较大的故事中不确定性更高，为什么这意味着使用斐波那契数列？有数学或统计原因吗？否则，使用斐波那契数列进行估计对我来说就像 CargoCult 科学。

【问题讨论】：

可能只是因为斐波那契数列“酷”。任何指数序列都可以。 2^n 可能会将数字间隔太远，那么为什么不使用斐波那契数列，大约是 c*phi^n？
+1 表示“很酷”。我曾经和程序员一起工作过，他们总是想把奇怪的东西推到斐波那契——这一直是他们的“东西”
重复pm.stackexchange.com/questions/4251/…
这个问题似乎是题外话，因为它是关于...？

标签： math statistics agile agile-project-management

【解决方案1】：

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

我们从估计中获得的信息比估计的精度增长得慢得多。事实上，它以对数函数的形式增长。这就是较大项目的不确定性较高的原因。

在实践中很难确定指数尺度（归一化）的最佳基数。斐波那契尺度对应的底数可能是最优的，也可能不是最优的。

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

【讨论】：

这是我希望得到的更深入的解释。谢谢你的回答。
“[a] 少量估算工作有很大帮助，[a] 大量估算工作几乎没有帮助” 很棒的文章

【解决方案2】：

在斐波那契数列的前六个数字中，有四个是素数。这限制了将任务平均分解为更小的任务以让多人并行工作的可能性。这样做可能会导致一种误解，即一项任务的速度可能与从事这项工作的人数成正比。 2^n 系列最容易出现此类问题。斐波那契数列实际上迫使人们一一重新估计较小的任务。

【讨论】：

这是一个有趣的观点。但是为什么不使用素数序列 1,2,3,5,7,11,... 来进行估计，而不是使用斐波那契数列呢？
这是个好主意。实际上，它们出现的频率足以仅选择那些大致创建 [1.5-2.0]^n 系列的那些。诚然，斐波那契数字更容易从头部重新创建，但 JIRA 等工具允许指定任何一组值。
另一点是估计之间的距离。您估计的时间越长，确定性就越低。 3-5 和 5-7 之间是相同的差异，意味着相同的确定性。但是，当您必须在 8 和 13 之间进行选择（更大的差距）时，它会迫使您真正检查自己的确定性。
@asmaier 我认为这是因为斐波那契数是指数的，而素数对于估计故事时通常使用的小样本是线性的

【解决方案3】：

根据this agile blog

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

是的，没错。我认为这是因为它们为本质上非常高级的早期规模调整（不是范围界定）练习（确实有价值）增添了一种合法性（斐波那契！数学！）。

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

【讨论】：

这个答案与两个月前的answer from @kaj 几乎完全相同（引用相同的链接和相同的引用）。
我真的很喜欢这个人引用它的方式。让我立刻明白了。

【解决方案4】：

你肯定想要一些指数的东西，这样你就可以用恒定的相对误差来表达任意数量的时间。您的估算精度也很可能与您的估算成正比。

所以你想要一些东西： a) 整数 b) 指数的 c) 简单

现在为什么选择斐波那契而不是 1 2 4 8？我的猜测是，这是因为斐波那契增长较慢。它在 goldratio^n 中，而 goldratio=1.61...

【讨论】：

“您的估计精度也很可能与您的估计成正比。”这是统计学中的规则还是人类通常会做的事情？如果您使用斐波那契数，您假设估计的相对误差约为 f(n-1)/f(n) = 1-goldenratio = 61 %。因此，如果估计为 5，人们假设这意味着相对误差约为 3，因此复杂性的显着增加只会是 8 或更高。但是，为什么假设相对误差约为 60%？这只是经验法则吗？
回答我自己的评论：Mike Cohn（2005 年 11 月）。 “敏捷估算与规划”说：“研究表明，我们最擅长估算一个数量级以内的事物（Miranda 2001；Saaty 1996）”。
Miranda (2001)：“使用配对比较改进主观估计”说：“我在同事中进行了一次非正式调查；来自不同国家和工业界和学术界的 30 人为量表提供了输入。结果表明，软件领域的大小和语言描述之间的对应关系更接近表 3 中显示的对应关系，而不是 Saaty 的对应关系。”在这张表中，我们看到如果某个东西是基本尺寸的 125%，则称为“稍大”，如果是基本尺寸的 175%，则称为“更大”。
下一个斐波那契数是前一个斐波那契数的 161%，因此这适合 Mirandas 表中的“稍大”和“更大”之间。似乎这项非正式调查是我们使用斐波那契数的根源，因为如果我们说某事更大，它们的比率更接近我们的意思。
@asmaier 我认为您应该将这些 cmets 添加为单独的答案，它们非常好，或者可能在链接的 PM.SE question 上，因为不幸的是，这已被锁定。

【解决方案5】：

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

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

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

【讨论】：

【解决方案6】：

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

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

当我们将所有不确定性加起来时，我们不太确定实际应该是多少小时。如果我们可以判断这个任务是否比我们已经估计过的另一个任务更大/更小，那么最终会更容易。随着我们增加任务的规模/复杂性，不确定性的影响也会被放大。对于一项看起来是我之前估计的 5 小时的两倍大的任务，我会很乐意估计 13 小时。

【讨论】：