斐波那契数列在敏捷估算中的应用

斐波那契故事点帮助团队快速、准确地估算工作，无需纠结于确切的小时数。使用相对大小估算来区分大型、不确定的任务和速赢项目。

斐波那契故事点系统已经存在了一段时间，但敏捷实践的最新普及使其再次流行起来。你可以在几乎所有支持估算的项目管理软件中使用它，例如 Jira 或 Asana。

使用斐波那契数列（1、2、3、5、8、13、21）进行评估

当大多数需求未知、环境复杂且需求紧迫时，使用相对大小估算而非绝对估算。你不需要知道确切要花费多少小时或赚取多少收益。这些数字在 Scrum / 敏捷方法论中也被称为故事点。

这种估算的目标是帮助进行相对大小估算。它有助于确定什么更大、什么更小，但不会找到确切的数字，因为预测很少能够实现。

斐波那契数列估算将估算时间缩短了 80%。它突出了差异并提供了更好的估算。

为什么使用斐波那契数列的故事点优于小时估算

根据 Scrum Inc 的说法，即使是公司中最好的专家也无法估算项目需要多长时间，包括实施项目的人员。此外，Rand Corporation 在 1940 年代的研究表明，人类不擅长估算小时数。实践经验反复证实了这项研究。

开发人员只知道足够开始工作的信息；他们不知道完成一项工作所需的所有信息。需求越模糊，就越难以计算某件事需要多长时间。然而，团队仍然需要估算他们的工作以预测发布。

需求越模糊，就越难以计算某件事需要多长时间。WSJF 不会强迫你设置准确的小时估算。相反，它要求你设置你的不确定性级别。

我们的目标不是找到确切的小时数，而是确定和处理可接受的不确定性级别。随着工作量的增加，不确定性呈指数级增长。

随着你对工作量的估算增长，按时完成任务的概率急剧下降。

按时完成任务的概率，学术制造工程杂志，第 15 卷，第 1 期/2017 45

为了更好的规划，你需要将无法在一个迭代或产品增量周期内完成的大型且不明确的任务分离出来。

使用线性评估量表时，数字彼此太接近，无法区分估算。斐波那契数列将保护你的优先级列表，使具有合理复杂性的任务不会与应该被拆分成更小块的任务混淆。

工作量与按时完成任务概率之间的相关性

斐波那契数列估算如何遵循 80/20 法则

WSJF 优先级评分有 80 个唯一值，分布在 0.14 到 63 之间。你可以将七个优先级级别与 WSJF 评分的每个区间相匹配：

大多数 WSJF 评分值位于 18 以下。这大约占 80% 的值。这符合帕累托法则。这种估算方法将无用的任务与待办事项中的最佳想法分离开来。

如果无法评估任务怎么办？

有时根本无法给出估算。也许任务需要澄清或重新思考，或者对该工单缺乏足够的信息。

提问

一个简单而强大的异步待办事项细化工具。

在使用 hi.ducalis.io 运行评估会话时，你可以就不明确的工单提出问题。然后，该任务将从评估部分移至提问部分。

每个问题解决的结果应该是与该工单相关的操作。你将有时间讨论、澄清、拆分、合并该工单或将其从待办事项中移除。问题解决后，该工单将返回到评估部分。

这种方法最大的优势在于它是异步的。你不需要运行专门的待办事项细化会议。只需跳过另一个可能被"提问"按钮替代的 Zoom 通话即可。

跳过评估

有时你可能会阅读工单的描述，但完全不知道它是关于什么的。例如，也许它只是从你的任务管理工具自动同步过来的。然而，该工单尚未准备好进行评估，因为它仍处于研究、原型设计或实验模式。

你可以跳过它直到下一个评估周期（产品增量）。

该工单将出现在已评分部分，标记为已跳过。

要了解整体情况，请查看团队的评估进度报告，了解待办事项中有多少已跳过的任务。

在 Ducalis 中选择斐波那契数列作为评分方法

在 Ducalis 中创建优先级排序标准时，你无需从头开始创建斐波那契数列，可以快速从提供的评分预设中选择并使用现成的预设。

你可以为每个分值添加描述，以指导团队成员在对产品待办事项中的工单进行评分时使用。

修改后的斐波那契数列

Mike Cohn（故事点概念的作者）建议团队使用修改后的斐波那契数列进行估算：1、2、3、5、8、13、20、40 和 100。

这个想法非常简单。用 40 或 100 评估某件事类似于提出问题或从当前 PI 周期跳过任务。

如果你喜欢这个想法，可以在标准设置下轻松选择修改后的斐波那契数列预设：

然而，这需要大量的手动工作。因此，应该有人始终跟踪这些任务，记住不明确任务的列表，并要求其他人澄清它们。