我们的敏捷之路—任务估算篇

前言

由于上周孩子生病，耽误了更新，因此今天补上。

这次我们介绍一下在敏捷开发中我们如何进行任务的估算，简单来说就是确定一项工作到底需要多少资源（一般是人*天）。

凡是做软件开发都离不开任务的估算，因为老板总是希望你能告诉他这个系统或软件什么时候能完成，大概需要多少人，这个工作一般都是费力不讨好的活，很难估计，因为估计值根据需求，开发团队的技术水平，人员状态都有密切的关系，估的多了，老板觉的团队水平不行，估的少了，又是给自己挖坑，每次估算都让人头痛，虽然任务估算确实十分困难，但其实是有一些方法，尽管不能让你的估算精确到多少天，但肯定可以让你的估算更加靠谱。

估算的意义

准确的项目估算往往能带来巨大的收益，比如：

可以根据估算确定产品的上线日期

根据估算来确定是否要招聘新的技术人员

根据估算可以大体确定团队竞争力

根据估算可以确定大家要不要一起来996的加班

相反如果估算非常不准会有什么结果呢，比如：

项目经理不再相信技术人员的估算，每次都会把估算*2再报给用户或老板

由于估算过于乐观（99%的情况），项目经常拖期，大家绩效受到影响

为了弥补项目拖期，大家不得不加班

团队离职率飙升

估算的影响还不止于此，既然估算影响这么大，还无法避免我们应该找一些方法来提高我们估算的能力，让我们的估算靠谱一点。

传统项目如何估算

简单一句话：

开发人员根据经验和直觉提直接拍脑袋拍出来的。

基本过程

老板把技术人员A和项目经理B找来

B把项目需求大体描述一下

A说我感觉差不多是半年

一个典型的估算就算是完成了，稍好一些的会把项目需求分成几大功能再来估算。其实也都差不多。

我们如何估算

如果上面的情景，现在我会这样回答：

现在没法给出一个精确的估算，之前项目是三个月完成的一个原型版本，如果需要进一步的估算，可以让开发团队和项目经理共同工作1~2个周期，就能得到相对靠谱的估算了。

由于我们的敏捷开发都是按照迭代周期进行的，因此我们这里的估算也是指这个周期工作的估算。下面这三种方法都是基于PM能提供功能需求列表或用户故事列表这一前提下进行的。

先计算出本周期一共的团队资源量(人天，有必要的话可以将开发和测试分开)

计划扑克

计划扑克”（PlanningPoker）是一种标有数字的扑克牌。计划扑克的目的是为了能够在一个尽可能短的时间内，让团队成员更加多的了解需要做的工作，同时顺带得到一个可接受的估算结果，一般推荐4到8人参与估算。



基本玩法：

1.发牌

2.拎出一个要估算的功能，PM解释要求

3.开发人员根据功能给出自己的估算值，用牌上 的最接近的数字代替，出牌背面朝上（每次一张）

4.大家同时翻转牌，差距过大的人给出自己的想法

5.大家根据刚刚的发言再出牌和翻转，直到达成一致，该功能的估算结束

6.重复2~5直至团队资源耗尽。

好处：

1.有一定趣味性

2.再解释时能够实现知识和技术的分享

坏处：

1.再其他人看来实在玩扑克

2.需要道具

排序法

相对于计划扑克，排序法需要的是一块大一些的白板和卡片。

基本过程

1.大家把全部功能逐一写到卡片上

2.把卡片用磁铁贴到白板上

3.大家一起来将卡片按照自己估算的工作量大小进行排序，鼓励进行相互交流

4.把大家分歧大的卡片挑出来，大家说明自己估算的依据以及PM及时站出来解释

5.都说明后再把卡片交给大家进行重新排序，直到大家的排序意见一致

6.根据排序的结果将任务分别大中小三种级别，对于不符合这三个级别的再进行拆分和重新排序

7.对于三种级别给出估计值，在计算全部综合即为估算。

好处：

速度快

坏处：

场面比较难控制

需要道具

总结

估算的第一要义就是：

不要试图进行长时间的精确估算。

估算的第二要义就是：

估算的目标越小，就越准确

估算的第三要义就是：

保持冷静和一定的悲观

估算的第四要义：

作对事情更重要