敏捷实践 — 估算-京东云开发者社区

在敏捷开发中，我们通常会通过故事点或者理想人天的方式来对用户故事进行估算，本文主要讲解估算时用到的故事点、理想人天，并介绍速度度量的方法和估算方法，最后通过计划扑克游戏来讲解估算的过程。

### 1 故事点是相对的

故事点是用于表达用户故事、特性或其他工作的总体大小的度量单位。当我们进行估算时，我们给每一个故事（任务）分配一个点值。我们分配的原始点值并不重要，重要的是点值的相对大小。故事点为2的故事是1的两倍，是3的2/3；

用户故事的故事点数反映了它的总体大小，对故事点的估算需要综合开发该功能所需对工作量、复杂性、蕴藏的风险等。

#### 1.1 故事点估算的两种方法

1. 在将要开发的用户故事中，选取一个认为最小的故事，然后将它的大小设定为1故事点；
1. 选择一个基本处于中等的用户故事，然后给它分配一个大致处于取值范围中间的点数。

在以上两种方法中，一旦相对主观的给第一个故事（又称黄金故事）分配了故事点值，其他故事就可以通过与第一个故事或者任何一个已经估算了故事点的用户故事进行比较，来估算他们的大小。

### 2 理想人天

如果我问你一场CBA篮球比赛需要持续多长时间时，你可能会回答40分钟或者俩小时。这两种回答都有道理，是站在不同的角度来回答的这个问题。如果单纯从比赛来看，一场比赛分为4小节，每节进行10分钟，但如果从观看比赛的角度，一场比赛通常需要近两个小时，其中包含中场休息和暂停等耗时。他们之间的区别恰好体现了理想时间与实际耗时的区别。

在软件项目中，理想时间与耗时之间存在的差异是由于我们每天都会遇到的自然额外开销，例如：回复系统问题，查Bug，回邮件，需求评审，回顾会，面试，任务切换，参加培训等等。

所以，使用理想人天进行估算是需要假定：
1. 所估算的用户故事是你将处理的唯一工作
2. 你所需要的所有东西在你开始工作时都会准备好
3. 不会被打断

当我们估算开发、测试、验收一个用户故事所需要的理想人天时，并不需要考虑团队的工作环境所带来的额外开销。此时理想人天可以等同于对大小进行估算的方法，就像故事点一样。然后我们也可以通过速度把以理想日的数量表示的大小估算转换成对持续时间的估算。

在敏捷资料中更多是推荐以故事点进行估算，很少见到理想人天的方式。但在实际工作场景中，由于团队成员大多是从传统方式转向敏捷，对故事点估算的方式和内在的接受度相对较差，反而对理想人天的接受度更高。

### 3 速度

速度是对开发小组的进度生产率的度量，可以通过计算开发小组在一次迭代中完成的用户故事所分配的故事点数的总和来得到。例如在为期10个工作日的迭代中，完成了5个估算值都是3点的用户故事，那么他们的速度就是15。

如果小组在上次迭代中完成的故事点数为15，那么我们可以作出他们将在本次迭代中也会完成15个点的故事，由于故事点是相对大小的估算，所以无论他们是完成3个5点故事或者是5个3点故事，这一结论都是成立的。

#### 3.1 修正估算误差

随着团队在项目的用户故事上取得的进展，他们的速度在最初的几次迭代中就会显示出来。此时可以通过实际速度来修正计划的误差；例如一个包含100点的项目，最初认为每个迭代可以完成25个点，需要4个迭代完成，但是在项目开始以后发现每次只能完成15个，所以可以推算出需要6.7个迭代才可以完成。

在以上方法中，虽然工作量和进度表密切相关，但是我们将工作量的估算和对工作时长的估算完全隔离开来，进行独立的估算，实际上不再需要对项目持续时长进行估算，只需要进行推算即可。

### 4 估算方法

#### 4.1 共同估算

在敏捷团队中并不是依靠某一专家来进行估算，其中原因之一是认为将要做此工作的人做出的估算比其他人更准确。其次，在敏捷项目中，我们往往不知道该项工作最终是由谁来完成，因此最佳做法是由团队协作作出。

#### 4.2 估算尺度

计算故事大小最常用的是 1、2、3、5、8、13、20 等一些列斐波那契数列，它的好处是团队能估算很大的故事，通常我更倾向于选择0.5～8之前的数字；当然，在敏捷开发中也会引入0（零）、∞（无穷大）、？（问号）等标记，下面我们将一一介绍：

- 0 （零）：表示该故事小到可以忽略不计，这种情况下通常会将类似故事进行合并，而不是选择0，当然多个0的故事合并在一起的结果可能不再为0；
- ∞（无穷大）：表示该故事大到无法评估，这种大粒度的故事又被称为“史诗”。此时我们需要做的是将故事进一步拆分，拆分需要保持故事的INVEST原则；其实现实中很难找到无法拆分的故事，毕竟程序员最终要奖故事拆分成一行行的代码来实现，所以拆分的难点是要保持INVEST原则；
- ？（问号）：表示根本不知道，这将意味着需要穿刺。穿刺又称元故事，即代表“用于估算故事的故事”。这样就可以评估这个“用于估算故事的故事”的工作量了。

#### 4.3 得到估算的方法

最常见的有以下三中方法：

1. 专家意见：想知道一件事需要多长时间，可以去问问专家，这种方法一般效率较高，在传统项目中经常见到，算得上是一种相对有效的方法。但这种方法在敏捷中很少使用。
2. 类比：使用类比进行估算时，估算者将一个估算中的故事与一个或多个其他故事进行比较。这种方法会把每个新故事与已经估算完成的故事进行比较，也称为“三角测量”。
3. 分解：指将用户故事或特性分解为更小的、容易估算的部分。如果项目中大部分任务都是2～5个故事点，此时要对一个50点的故事进行评估是很难的，我们很难现象一个故事是另一个故事的10倍，甚至20倍，所以将大的故事分解成小的故事再进行评估将更容易估算。当然，分解太过小时不仅容易遗忘某个任务，而且对大量小任务的工作量求和也会出现问题。以登陆功能为例，假设我们评估为3个故事点，但是将故事进行分解，分解成：用户名密码登陆、手机登陆、短信验证码登陆、发送短信、......等等任务，而每个任务评估0.5~1个点，最终偏差会越来越大。我曾经见过迭代会上评估点每个任务都是0.5或1个点，完全没有其他点，这种是典型的分解过细造成的结果。

### 5 计划扑克

计划扑克游戏是敏捷团队经常用到的一种评估任务量的最佳实践，它可以产生快速而可靠的估算。计划扑克的参与者包括敏捷团队的所有开发和测试人员，在估算时每个估算人员都会得到一叠卡片，卡片的内容为一系列斐波那契数列，代表评估值。对故事进行估算时，通常由主持人读出故事的说明，由产品负责人回答估算者提出的问题。在答疑完成后，估算者私下选择一张合适的卡片，在所有估算者都完成选择后共同展示出来，大家可以看到彼此的估算。

这时的估算往往会有一些显著的差异，这时可以让估值较高和低的人分别说出他们的理由，这其中通常是由于大家信息不对称和理解偏差所造成的，在说出理由后，大家可以花几分钟进行简单的讨论。最后，每个估算者再次出牌进行估算，一般来讲第二轮时结果会集中起来，不再出现较大偏差，当然如果仍没有达成一致可以再次重复说明理由和讨论、澄清的过程，直到拉齐认知并得到大家认为合适的结果。在以往的工作中，我见过一些团队采用取平均值的办法，其中没有讨论澄清的环节，这种是不可取的。计划扑克的目标不是为了获取一个未来经得起详细审计的估算，而是花较小的代价获取一个有价值的估算，它的重点不在于绝对精确，而在于合理性。

在一些情况下，也可以采取将团队分成几个小组，每个小组至少3名估算者，而不是所有人都一起对所有故事进行估算的方法。这种做法可能违背敏捷的理想做法，但是在需要评估的任务较多，或者团队中每个人并不能做到对所有任务都有所了解到情况下可能是一种合适的做法。这种情况下小组之间需要在评估尺度上保持一致性，需要团队对3故事点或1个理想人天有一个共识，最终也可以通过三角测量法进一步确认结果。

#### 6 总结时刻

以上是这篇文章的所有内容，我们再回顾一下本文的重点：

- 故事点是相对的，反应的是工作量，不是工作时长
- 理想人天方法最重要的点是“理想”，假设工作环境没有任何“噪音”，全身心投入一件工作中
- 敏捷估算推荐所有开发人员共同评估用户故事，但在一些特殊情况下也是可以采取分组评估的
- 计划扑克的重点是要大家通过讨论达成最终共识，期间需要解决信息不对称和理解偏差
- 敏捷估算的重点不在于精确，而在于合理性

如果以上的内容你只能记住一件事，那请记住：**敏捷估算的重点不在于精确，而在于合理性**

### 7 参考资料

- 《敏捷整洁之道——回归本源》——Robert C.Martin（著），申健、何强、罗涛（译）
- 《敏捷软件开发实践——估算与计划》——Mkie Cohn（著），金明（译）
- INVEST原则：Idependent（独立的）；Negotiable（可协商的）；Valuable（有价值的）；Estimatable（可评估）；Small（小的）；Testable（可测试的）

------------

###### 自猿其说Tech-京东物流技术发展部
###### 作者：郭峰