敏捷开发一千零一问系列之三十：敏捷怎样估算（中）？

方案

方案一：用早期功能点估算法进行报价或早期制定项目计划

这个在以前谈到过不少次了，具体能够参考敏捷开发绩效管理系列的之6、之七。另外在敏捷开发用户故事分类与组织结构（一期） （整个活动1期）中有详细描述。

这个是国际上迄今为止惟一被大规模推广使用的方法，中国即将发布的国标就是基于这个的。如今世界上有6000多认证的功能点估算专家，中国只有2个（本人不是），因此显得不太出名。这多是软件界中外差距最大的一个知识领域了。

方案二：用敏捷扑克防止大规模的代码和工做量浪费

几种错误作法

可不是用了扑克牌就是敏捷估算的，好比下面的玩法：
1. 随机抽一张牌，是多少就是多少
这个是最快的扑克牌估算，很快，尚未争议。但相信没有人喜欢，因此“快”不是咱们敏捷估算的目的。
2. 各自出一张牌，加在一块儿除以人数
这个听起来理智多了，还很民主，颇有点放权的意思。是否是正解？嗯……若是有人出1，也有人执意出100人天，怎么办？（1+100）/2 = 50.5？看来，民主和放权也未必是正解。
3. 不用扑克，主动领取，谁干谁说了算，本身估算的本身干着才带劲
这个听着也很敏捷，放权，激励，承诺……都有了。不过，不论是不是敏捷，若是前面那几位4000行和19万代码的来了，那就完了。无论高手有多厉害外加多热情，代码冗余不可避免；而新手在写下一份简历的时候，大概在想：我这两年作的事情，实际上被一个家伙两个月重写了。
这里有个标准问题了：究竟是选择符合敏捷标准的，仍是符合最小代码和工做量的？
是我会选择后者。毕竟敏捷是来服务咱们的，不是让咱们来“遵照”或“追随”的，若是都伤害了团队和项目的利益，就算它是敏捷又如何。

那到底应该怎么估算？

正确作法

在说正确作法前，先要找到正确目的。

放权，激励，承诺，民主……这些不是目的吗？不是，这些是手段。目的，是一种达成后，能直接看到进度、质量、成本、需求得以改善的东西，而不是还要七拐八绕才靠边的东西。

其实咱们前面讲到了，一个值得花费一天进行估算的目的，是估算能够有效减小代码行和工做量。

为了达到这个目的，估算的过程应该是：

0. 产品经理讲解需求，你们提问（若是愿意，能够稍加讨论，建议不要太长）

1. 各自估算（扣牌出，不要亮牌）

2. 全部人出牌后，开牌

3. 最大值和最小值PK，其余人起哄也能够参与

4. PK后，不要直接达成一致（好比“那就三天吧”），而是从新出牌

5. 返回2，直到达成“近似一致”

6. 肯定最终结果

肯定选择最终结果的规则很复杂——实际上没有很精确的规则，因此要“随机应变”，往后会同一些反馈，在本话题的下篇中讨论。

按照这个作法，大概会发生这些事情：

0. 产品经理：……好了，大概就是这样，你们若是没有什么问题就出牌吧……

1. 小张：唔……我估计至少这些（X天）；老王：就这还讲了半天，最多这些（Y天）

2. Scrum Master：都出好了？开牌！你们：天哪，X=20 & Y=0.5

3. 老王：最多一个小函数55行就能够了啊，为何要那么多天？

小张：一个函数是55行，但是要处理13中不一样类型，还要有5种不一样的常数值。

老王：对啊，一个泛型+一个For循环传入参数，最多56行。

分支A

4. 小张：等一下……循环，这个我怎么没想到呢……还有……泛型……有道理……我想一想……来，再出一次牌

5&6. Scrum Master：X = 1 & Y = 0.5……差很少就这样了，算1天吧。下一个。

分支B

4. 小张：等一下……循环，这个我怎么没想到呢……这个好理解……泛型？什么是泛型？

若遇到了分支B，请参考敏捷开发松结对编程系列，能够直接阅读之三及之四（泛型将在“之四”提到的“前关键点”中由师傅传授给徒弟），或从头开始。