张大胖的需求估算

需求估算一向是不准的......



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

晚上和女朋友去看场电影，听说星爷的新片很不错， 她已经叨叨好几天了。周末再出去吃顿大餐，最近项目挺忙的，天天加班到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), 然后其他需求以这个为对比， 估算出复杂度的相对值出来, 估算的过程就是上述的扑克牌游戏。

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

码农翻身相关历史文章推荐：操作系统

CPU阿甘

CPU阿甘之烦恼

我是一个进程

我是一个键盘

我是一块硬盘（上）

我是一块硬盘（下）

那些烦人的同步和互斥问题

冯·诺伊曼计算机的诞生

Java EE

我是一个线程

我是一个Java class

Java:一个帝国的诞生

JDBC诞生记

JDBC后传

一个不安分的JDBC驱动

JSP:一个装配工的没落

Javascript： 一个屌丝的逆袭

Spring本质系列(1) -- 依赖注入

Spring本质系列(2) -- AOP

Http 历险记（上）

Http 历险记（下）—Struts的秘密

三层架构和MVC那点事儿

Java帝国之 Java Bean(上)

Java帝国之 Java Bean(下）

Java帝国之 函数式编程 (上)

Java帝国之 函数式编程 (下)

计算机网络

我是一个路由器

我是一个网卡

TCP/IP之大明邮差

TCP/IP之大明内阁

TCP/IP之蓟辽督师

张大胖的socket

HTTP Server ： 一个差生的逆袭

IE为什么把Chrome和火狐打伤了？

对浏览器村的第二次采访

节约标兵IE的自述

EMail诞生记

EMail诞生记（下）

数据库

小李的数据库之旅（上）

小李的数据库之旅（下）

张大胖学数据库

数据库村的旺财和小王

你看到的只是冰山一角， 更多精彩文章，尽在“码农翻身” 微信公众号， 回复消息"m"或"目录" 查看更多文章

有心得想和大家分享？ 欢迎投稿 ！ 我的联系方式：微信：liuxinlehan  QQ: 3340792577

公众号：码农翻身

“码农翻身”公众号由工作15年的前IBM架构师创建，分享编程和职场的经验教训。

    关注 码农翻身