方案

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

这个在之前谈到过很多次了，具体可以参考敏捷开发绩效管理系列的之六、之七。另外在敏捷开发用户故事分类与组织结构（一期） （整个活动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，请参考敏捷开发松结对编程系列，可以直接阅读之三及之四（泛型将在“之四”提到的“前关键点”中由师傅传授给徒弟），或从头开始。