Question

周五傍晚， 快要下班了，想着马上就要到来的周末， 张大胖的心情是无比愉悦。

晚上和女朋友去看场电影，听说星爷的新片很不错， 她已经叨叨好几天了。周末再出去吃顿大餐，最近项目挺忙的，天天加班到 9 点， 得犒劳一下自己。

正在美好憧憬的时候， 公司内部通信工具 XT 上， 经理那似笑非笑的头像开始疯狂的闪动，张大胖心里有种不详的预感， 极为不情愿的点开了聊天窗口。

经理发来一个需求文件， 附带着一句话： “赶快做一下工作量评估， 下班之前给我！！！！”

几个红色的感叹号，在大胖看来简直就是红色的怪物。

还等什么，赶紧估算吧， 大胖快速读了一下文档， 这个需求还算简单，他心里快速盘算：

需要新建两张表 ， 估计两个小时就能把 sql 脚本写好。

界面也不太复杂，一天就差不多了；

中间层的那个 Service 需要大改， 两天吧；

最不确定的就是调用另外一个部门提供的接口了，如果一切都好，一天就可以了， 但是跨部门合作有点难， 加一天缓冲吧。

还有自己手工测试， 写自动化单元测试， 把代码评审的时间也加上，这三项总共 2 天吧， 肯定够了。

一共需要 7 天， 不， 大胖眼珠一转： 软件估算向来不准， 为了防止把自己累死， 再加两天缓冲， 一共 9 天！

当然大胖聪明的把这额外的两天平均分配到了各个任务中。

大胖把工作量估算发给了经理没多久， 经理就一脸不悦的来了： “大胖， 这个需求看起来也不复杂啊，你怎么估算了这么多？ 是不是有水分？”

大胖解释了一通， 经理仍然不满意：“ 我看四五天就够了。”

大胖知道，经理是开发出身，对项目代码还是非常熟悉的。 他又耐心解释了一下， 经理还是坚持 4-5 天。

经理说： “看来我也说服不了你，你也说服不了我 ，这样，我们再找几个人， 搞个全员估算。”

大胖说： “什么是全员估算？ ”

“你听说过敏捷中有个 Planning Poker 的估算游戏没有？ 简单的说就是要求开发、测试、需求分析、产品设计各色人等都参与工作量估算， 每个人手头有一副牌， 牌上的数值是 1，2，3，5，8，13，20，40， 代表了一个需求的复杂度， 称为点数(Point)。 “

”我有个问题， 哪些测试的，需求分析的，产品设计的， 他们不懂开发，怎么能估算出工作量？“

经理回答： “注意， 我刚才说的是需求复杂度， 而不是具体需要几天来完成，这两者是不同的， 非开发人员也能估算复杂度。 但是现在快下班了，临时找不来那么多人，只能找来开发人员， 我们可以简单一点，就认为牌面数值代表了 1 人天， 2 人天，3 人天等。

“具体怎么做？ ”

“大家对一个需求进行评估之前，需要先了解这个需求， 各自估算， 然后同时出牌，注意，一定得同时出牌， 防止互相影响，尤其是新人容易被老员工的经验引导。 如果大家的牌面数值比较接近， 则接受估算结果。”

“要是每个人的差异比较大怎么办？”

“那就请估分最高的和最低的进行解释， 大家讨论， 然后开始下一轮的评估， 直到大家达成基本一致为止。”

“我们好像没有那个 Planning Poker 吧” 大胖问到。

“简化一点，每个人都写到纸上吧。 ”

经理把开发小李和老付拉了过来， 大家在一起先过了下需求， 然后第一轮出牌 ：

经理： 4 天

大胖： 7 天

小李： 8 天

老付：10 天

大胖充满感激的看着老付和小李： 不愧是开发的兄弟啊。

经理说： ”好吧， 我估算的最少， 我先说说， 我觉得这个需求界面半天就差不多了， 我让美工做出来，开发套上动态代码就行了； 业务层代码 1 天就搞定， 这个需求还要使用隔壁开发的接口，不过上星期小李已经调用过了， 没什么问题，一天绰绰有余； 测试的话 1 天也够了。 所以总共是 4 天。“

老付说： ”我刚开始认为 7 天就差不多，估了 10 天， 是因为除了基本的功能实现之外，这个需求对安全和性能的要求比较高， 代码需要小心写，小李调用的那个接口和这次的不同啊， 参数有变化， 咱们没有用过， 再加上跨部门合作，估算一天风险也很大； 那个业务层代码我之前浏览过， 典型的遗留代码， 难改的很呐，一天可搞不定。 还有， 这个需求特别难于测试，准备数据极为麻烦， 也得加上额外的工作。“

大胖心里暗自佩服， 姜还是老的辣， 老付考虑的很周到。

小李插嘴说： ”老付， 可能你不知道， 测试组搞了一个自动化的工具，现在准备数据方便多了“

经理说： ”嗯，大家的建议不错啊，看来实现这个东西还不那么容易， 咱们再来一轮评估“

第二轮结果如下：

经理： 7 天

大胖： 8 天

小李： 8 天

老付： 9 天

这次的结果比较接近了， 经理说： 要不就按 8 天算吧， 大家都表示同意。

张大胖暗自庆幸， 刚刚 6 点半， 看来不用给女朋友请假了， 能按时下班了。

不料经理走到楼道打了个电话， 回来说：”客户要求下周三就得完成， 大胖和小李， 还得辛苦你们俩了，周末加个班吧......“

唉，看来无论多么精确的估算都敌不过客户的要求啊。

后记：上文展示了全员参与估算的游戏， 这只是针对一个需求的 工作量（人天） 评估。

在敏捷开发中， 需要对一批需求（用户故事）进行全员参与的 复杂度 评估， 在评估的时候，会选取一个大家公认的最简单需求，作为 基准复杂度 ， 即一个点数(Point), 然后其他需求以这个为对比， 估算出复杂度的 相对值 出来，估算的过程就是上述的扑克牌游戏。

对这个过程感兴趣的可以参考《用户故事与敏捷开发》 和《敏捷估计与规划》这两本书。