Fibonacci Agile Estimation

敏捷估算之斐波那契数列

Posted by Oscaner on July 24, 2021

斐波那契数列是一系列数字, 它们随指数增长, 并且每个数字都是前面两个数字之和。

$ 0, 1, 1, 2, 3, 5, 8, 13, 21, \dots $

如果您有兴趣看斐波那契数列相关算法, 您可以前往我的另外两篇文章。

  1. 《PHP - Fibonacci Sequence》
  2. 《PHP - Fibonacci Search》

这里我们将探讨斐波那契数列在敏捷估算中的作用。

什么是斐波那契数列 (Fibonacci Sequence)

斐波那契数列是由意大利数学家 Leonardo Bonacci 在中世纪发明的, 更广而人知的名字是 Leonardo Fibonacci。

他将斐波那契数列包含在了《Liber Abaci》, 该书又被称为《计算之书》。

在《Liber Abaci》中, Fibonacci 还提出了这样一个问题:

一个人把一对兔子放在四面围墙的地方。假设每对兔子都会生一对新兔子, 从第二个月开始就可以生产, 那么一年可以生产多少对兔子?

为了估计答案, Fibonacci 引入了一个指数序列, 就是现在的斐波那契数列。在数列中, 每个数字都是前面两个数字之和:

$ 0, 1, 1, 2, 3, 5, 8, 13, 21, \dots $

在下面, 我们将更多的称其为斐波那契量表, 而非斐波那契数列。

什么是敏捷估算 (Agile Estimation)

管理者在管理团队的时候, 一个最基本的能力就是能够估算一项任务从开始到完成需要多长时间。

同样, 您可能也有过这样的经历: 您的估算结果是错误的, 项目实际花费的时间要比预期长, 或者您的产品无法及时交付。

如果估算经常错误, 为什么还要花费精力去做它们? 想象一下, 花费时间进行成本估算, 但到项目开始以后, 大量出现超出预算的情况?

看似很无力? 实际情况是, 估算的主要目的是设定预期, 并确定您的团队在特定时间范围内可以完成多少工作。

作为一名项目经理 (Project Manager), 提高您的项目估算能力, 并带领您的团队与您一同前行是非常重要的。

在敏捷环境中, 管理者需要使用斐波那契量表来改进估算过程, 同时评估在 Sprint 中需要完成的任务。

为什么要在敏捷中使用斐波那契量表

斐波那契数列在许多不同的学科或者自然界中都有广泛应用。例如, 它已经被用于描述植物的生长, 估计特定时间范围内的人口增长, 病毒爆发模型, 以及预测金融市场行为。

但是, 斐波那契数列与敏捷估算又有什么关系?

从本质上讲, 敏捷斐波那契数列, 或者说量表, 提供了一种更现实的方法 – 使用故事点 (Story Points) 进行估算。

Story Points 用于表示完成或实施 User Story 所需要的规模、复杂性和工作量。

每个 Story Points 都从斐波那契量表中分配一个数字, 数字越高, Story Points 越复杂, 完成 Story 所需的工作量也就越多。

同样, 我们可以打个更直观的比喻:

我们想象一下, 一只手拿着一公斤重物, 另一只手拿着两公斤重物。不允许偷看, 我们能确定哪只手更重吗? 应该很容易, 因为它们之间的重量相差了一倍。

但是, 如果这两个重量分别是 20 公斤和 21 公斤呢? 我们将很难通过感知去区分它们。

只有差异足够大的时候, 我们的大脑才能更好的去感知它们。

这其实就是利用斐波那契量表来估算 Story Points 的原因。

随着序列的不断进行, 您的团队能够选择的数字会不断出现大的跳跃, 但它们始终以一致的速度增长 – 每个数字都表现出了约为 60% 的跳跃。这样的数字跳跃, 我们的大脑仍然有能力去感知它们。

同时, 斐波那契量表一个更显著的作用是在估算更大、更复杂的任务时强迫你去做出选择, 而不是浪费时间在细枝末节。

比如, 假设您的 Product Backlog 中有一个大型任务需要评估工作量, 您打算以 1 - 50 的稳定比例来估算您的 Story。

一个人选择了 31, 一个人选择了 36, 第三个人选择了 38。这些估算之间的差距令您很难有信心去决定, 需要将估算变得非常精细。

而使用斐波那契量表, 这种情况将不会/很难发生, 因为序列迫使您必须在距离较远的数字之间进行选择。在这个例子中, 每个人都可能会选择序列中的 34, 因为备选方案是 21 或 55。

同样, 基于斐波那契量表, 您不必担心大型任务的估算不准, 因为很多时候您也无法将大型任务放入一个 Sprint 之中, 更多时候会将大型任务进行一定的分解; 也不必担心小型任务的估算不够精细, 因为斐波那契量表也提供了细微差别和定义。

该如何使用斐波那契量表

许多敏捷团队使用 Planning Poker 方法来估算 Story Points。

此方法引入了一系列卡片组, 或基于以 0 开头的斐波那契数列 ($ 0, 1, 2, 3, 5, 8, 13, 21, \dots $), 或使用修改版本的序列 ($ 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 $)。

只要您的团队理解并认可比率的含义, 那么您的团队可以使用任何具有特定比率的数列。

除了主持人, 估算团队的每个成员都会拥有一副自己的纸牌, Planning Poker 的步骤基本如下:

  1. 产品负责人向团队提供 User Story Overview。

  2. 给予团队时间去讨论和提问, 以确保能够更好的了解风险和假设。

    讨论过程中不应该设计估算数字, 以免产生估算偏差。

    主持人需要及时记录讨论摘要, 并在限制讨论时间

  3. 每个团队成员选择一张卡片来代表他们对 Story 的估算, 并将其正面朝下放在桌子上。

  4. 团队成员同时翻牌。

    • 如果每个人都选择了相同的数字, 那么该数字就用于估算。您可以继续下一个 Story
    • 否则, 选择明显高于或低于其他数字的人, 让他们说明他们的估算原因, 由大家共同判断是否合理。

      例如, 开发人员完成任务很简单, 向表单中添加字段。但对于测试人员, 这种简单的添加会造成大量的回归测试, 可能会在以后变得更加复杂。

  5. 从步骤 3 开始反复, 直到大家达成统一估算。

  6. 进入下一个 Story, 整个过程开始重复。

如果您的团队没有实体卡片, 您也可以使用在线斐波那契量表

常见的斐波那契量表

  1. Classic Fibonacci: $ 1, 1, 2, 3, 5, 8, 13, 21, 34, \dots $

  2. Modified Fibonacci: $ 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 $

    很多时候, 原始序列上的较大数字在实际的 Story 精确度上并不存在。

    此版本是对较大数字进行了四舍五入, 以免出现关于为什么是 21 而不是 20, 为什么是 34 而不是 40 的问题。

  3. Powers of two: $ 1, 2, 4, 8, 16, 32, 64 $

    这个版本的数字增长是非常迅速的。由于缺少精细化数字, 即使对于较小的任务, 它也迫使团队成员做出艰难的选择。

  4. Five fingers: $ 1, 2, 3, 4, 5 $

    刚接触敏捷的团队可能会将卡片上的数字与时间进行混淆, 因此基于简单符号做估算可能更加有利。

1.png

总结

斐波那契数列不仅因出名而出名。数百年以来, 它一直在提供着真正的价值, 算法、电影、科研, 到处都有它的影子。

所以, 是时候将斐波那契量表纳入您的敏捷计划了。

致辞, 共勉。


本文由 Oscaner 创作, 采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外, 均为本站原创或翻译, 转载前请务必署名