如何当个神算子？项目任务估算那些事儿

对于估算，团队常常会有这样的困惑：花了大把时间来估算，最后却发现与实际还是有不小的偏差，到底有没有必要做估算，怎样来做估算？

俗话说，行百里者半九十，意思是说一百里的路走了前面九十其实只完成了一半，剩下的十里仍需要花很大的功夫。那么现实的生活和工作中，我们是不是也经常遇到这样的情况呢？回想一下，会不会有这样一种经历：打扫卫生，让房子从凌乱到整洁只需要20%的努力，要让房子从整洁到一尘不染却要花费80%的努力。那么我们就要审视一下，在精力有限的情况下，从整洁到一尘不染的过程有没有必要，房子从凌乱变到了整洁是不是就已经足够。我想没有洁癖的一般人，就如我，都会觉得后面那个过程的性价比实在 太低，完全没有必要。

回过头来看看我们在项目中的估算是不是也可以类比，从无估算到有估算其实花的是比较有限的精力，但是从有估算到追求“准确”估算却是个漫长的过程，并且有数据显示我们花一些时间得到的估算数据跟花费大量时间而得到的结果不会差很多。《敏捷估计与规划》这本书中提到，估计的准确度和投入的工作量之间存在以下关系：

因此，我推荐在进行估算的时候不必强求精确，更何况我们也无法做到精准，估算只是估算，只要做到尽量合理，尽量贴近真实值即可。

估算单位的选择

有的团队往往会在估算开始时纠结于如何选择估算单位，因为合理的选择是影响估算成功的关键因素。那么究竟该如何选择呢？

理想人日

理想人日是指成员在不受干扰的情况下，全部时间都用于开发一需求所需的天数。

理想人日的劣势在于：小组成员对技术和项目的熟悉程度，个人的经验和能力不同，都会导致基于理想人日的估算值有一定差异。例如，你问一个擅长C语言的成员某个需用java开发的功能的理想人日，他也许会告诉你是5天。但是你问一个擅长java的成员同样的问题，他的回答也许就是1天。这样的差异会导致我们对任务规模认识的偏差，很难衡量项目的实际“大小”。而它的优势则在于：对于团队外部的人来说理想人日更容易被理解，无需解释。对于团队而言，它使估算更容易开始。

理想人时

理想人时是对应理想人日而存在的，只不过它的粒度更小。当熟悉需求的情况下，用理想人时的估算会更准确些。想象一下，让你估算接下来1个小时能完成多少工作任务和接下来一天能完成多少任务，哪个的会更接近真实情况些？我想应该是前者吧。因为一天内能做多少工作，我们需要去除很多“杂事”（如喝水，上厕所，跟同事唠嗑，戳网页···）来估算纯干活的时间，这一点往往较难一些，总会存在一些偏差。但是如果要估算接下来1个小时能做什么，应该就比较容易了。理想人时的估算优势就在于：在充分理解需求的情况下，能帮助团队做到更靠近真实值的估算。而缺点是：对于一些大的需求无法做到如此细粒度。

故事点

故事点是来自于敏捷的概念，是对任务规模的估计，它是一种相对概念。例如：需求X为4个故事点，需求Y为8个故事点，则表示Y的规模是X的两倍，但并不表示开发Y比开发X要多一倍的时间，因为这还取决于是由什么样技术熟练度的人员开发。故事点的优势在于：一方面，基于故事点的估算更纯粹，不会因为开发人员的变更，时间的推移而改变。换句话说，项目半途有成员离职，加入新的成员，此时我们不需要对每个任务都重新估计，只需要重新评估一下是否有需要调整插入到当前迭代的故事点数。另一方面，由于人们往往更擅长于相对估算，所以故事点会让估算更迅速。想象一下，让你估算一杯水是另一杯水的几倍，是不是会比让你估算两杯水各是多少毫升来的更容易呢？劣势在于：一方面，而且由于编程语言不同或者业务分块，大家很难找到一个共同熟悉的需求作为基准，那么用故事点的作为估算单位的方式就很难开展了。另一方面，故事点相对于其他估算单位更难被理解，这也使估算难以开始。

估算的几种常用方式

自底向上的估算

由每个开发人员估算自己的任务时间，然后将所有的任务汇总，并考虑过任务间的依赖关系后，就排出了计划。该方式适用于具有以下特点的团队：成员间业务独立性强，相互之间的业务熟悉度不高且熟悉成本较大，较难进行共同估算；各成员的经验相对丰富，对自己的任务能进行较好的评估。

在这样的团队应用该估算方式有以下优势：

1. 估算效率较高，各自任务的估算可以并行。

2. 准确度也会较高，因为对各自的任务比较熟悉。

专家判断

由一个或多个专家根据相应开发的情况给出任务的估算值，但前提是你能找到这样一个熟悉整个项目所有业务和整个项目团队成员的专家或专家组，在笔者所在的团队一般会有开发leader来充当这样的角色。

它的好处显而易见：

1. 通常不需要太多的时间，一个人估算就不存在太多的交流成本。

2. 准确度也有一定的保障。甚至有证据说这种估算方法比其他的分析性方法更准确。

扑克估算

是以扑克牌的形式进行团队估算。估算开始前，每个估计者会分到一叠扑克牌，每张上有一个数值，如0,1,2,3,5,8···然后由负责人对某个需要进行估算的需求或者任务进行讲解，讲解完之后，所有人可以向该负责人提问关于该条需求或任务的问题，直至足够了解以做出估算。所有成员各自挑选一张扑克牌代表自己对该条目的估算。例如A给出8，而B只给了2，这样就需要A和B各自给出理由说明自己估算的理由，这样一轮下来，大家对该条目又加深了了解，然后进行第二轮估算，如果相差还是很大，则继续下一轮。大多数情况下至多经过两轮，大家的估算值已经非常接近了，就可以取平均值作为对该条目最终的估算。

扑克估算的好处在于：

1. 集合了所有团队成员的意见，比一个人的估算少了很多主观成分；

2. 其次，在估算过程中，强化和深入了大家对需求和任务的理解，将其考虑地更加细致，降低了不确定性给计划带来的冲击；

3. 最后，这种形式使相对严肃的计划和估算会变得更加有趣。但是不得不承认，这需要比前两种方式更多的时间成本。

实际应用中的估算

团队1

• 组成：4人团队（3人开发，1人测试）。

• 现状：团队稳定合作近2年，尝试敏捷一年多，开发语言统一，成员间对相互的业务也都比较熟悉。

估算单位和估算方法：由于很容易找到大家熟悉的一个用户故事作为基准，目前团队正应用基于故事点的扑克估算。团队在经过几次迭代之后，基本上确定团队的开发速率（每个迭代能完成的故事点数）。在接下来的迭代中，团队通过扑克估算确定每个用户故事的故事点，再根据用户故事的优先级一个个插入迭代开发计划中，直到不能再承诺完成为止。

团队2

• 组成：9人团队（7人开发，2人测试）

• 现状：团队组建不到3个月，开发语言不统一，成员比较年轻，对系统的熟悉程度也不高。

估算单位和估算方法：一方面，由于成员之间的业务熟悉度不高且开发语言不统一，团队无法轻易找到一个合适的基准用户故事，所以团队的估算都是基于理想人天开展的。另一方面，由于开发人员数量较多且一部分成员经验比较欠缺，无法很好的进行团队估算，所以团队目前采用专家判断（开发leader给出估算）为主的方式进行计划。

团队3

• 组成：13人团队（9人开发，4人测试，2人运维）

• 现状：团队组建约1年多，产品模块较多，不同模块有不同的负责人，成员对自己模块的业务逻辑比较清楚，但是对其他模块的业务了解甚少。

估算单位和估算方法：由于成员间业务熟悉度不高且开发语言不统一，团队无法找到合适的基准故事点，所以团队选择采用理想人日作为估算单位。另一方面，也由于模块较多，开发leader不能熟知各业务逻辑，所以团队采用了自底向上的估算方式。由成员各自估算各自的任务，进而给出开发计划。

团队4

• 组成：4人团队（3人开发，1人测试）

• 现状：团队组建2年多，产品已经处于成熟期，目前大部分工作处于查漏补缺的阶段。各成员对自己负责的部分比较精通。项目采用1周的短迭代形式。

估算单位和估算时间：由于迭代时间较短，团队成员又在自己的领域比较精通，故能做到基于理想人时的自底向上的估算，估算的偏差一般较小。

通过以上几个例子，笔者想说明的是：各种估算单位和估算时间本身并没有好坏之分，只有合适不合适只说。每个团队都需要根据成员和项目的现状来进行选择。如果生搬硬套只会弄巧成拙，得不偿失。

关于估算，我们必须明白

1. 我们要知道，估算仅仅是一个预测，当对外承诺项目完成时间的时候，最好提供一个日期范围，让听者知道你的估算只是估算；

2. 不管是用什么估算方法，更小块的工作总是更容易被估计；

3. 团队需要练习估算并且收集反馈，没有反馈的估算最终将被证明是毫无价值的。每一次估算对应的开发结束后，大家需要回过头看看我们当初做的估算是否合理；

4. 估算也许需要反复进行，当项目进行到一半时，发现估算过于乐观了，那么就需要对剩下的工作进行重新的估算。