前两年在网上看到一个笑话集锦, 列举电视剧中的穿帮情节。 其中一个是在某缠绵冗长的言情剧中, 一个叫 “书桓” 的角色沉痛地说 - “长达八年的抗日战争就要开始了…” 书桓同学当时是怎么估计到抗日战争要打八年的? 这一技术让软件工程师和项目经理望尘莫及。
软件项目计划的一个重要环节就是估计项目各类工作（特别是各种功能）所需的时间。 如果你没有书桓同学的能力, 你得好好练习这一技术。 “估计” 这一技术看似容易, 其实大有学问。 Steve McConnell 还专门写了 《Software Estimation: Demystifying the Black Art》 一书, 希望能把软件估计这一神秘技术 “去神秘化”。
在开始估计之前, 我们先分清楚几个概念 - 目标, 估计和决心, 。
目标: 表明一个希望达到的状态. 例如: 软件五一之前要投放市场! 在建校一百周年之时把我校建成世界一流大学! 不论这类目标如何重要, 它们未必能够实现。
估计: 以当前了解的情况和掌握的资源, 要花费多少人力物力时间才能实现某事。
决心: 保证在某个时间之前完成预先规定的功能和质量。 例如: 我们跑步前进, 全民炼钢, 两年超英赶美!
如果我们混淆了目标, 估计和决心, 那就会犯错误, 我们历史上就有这样的例子:
到了1976-77 年, 中国钢产量终于超过英国。 用了18 - 19 年时间。 扣除当年瞎折腾的几年, 这和当初估计的时间差不多! |
这样痛心的例子在软件项目也可以看到, 软件项目的延迟更是比比皆是 - 为什么我们估计得不准呢? 因为难么? 为什么软件估计这么难呢? 其实所有的估计都难. 不信的话, 我们做一些估计的练习, 不查搜索引擎, 你估计一下下面的数目 (数量级正确就行):
中国陆地边界长度 (参考答案)
非洲人口密度 (参考答案)
长江一年的流量 (参考答案)
2009年中国货币流通的总量 (参考答案)
一个80岁的人一生说过多少句话 (参考答案)
怎么样? 你的估计和实际情况差几个数量级?
一些硬件项目的估计相对容易 - 例如: 这边有一堆砖头, 估计有 X 块, 我们 N 个人要把这些砖头搬到那边, 每人每小时可以搬 M 块, 那么我们估计大概要 X / N / M 小时。 这个估计还是比较靠谱的。
软件项目的难度还体现在另一个方面, 写软件的人的能力也是要估计出来的数值, 而且没有合适的衡量单位, 例如: 如果王屋村的移山公司程序员果冻一天能写1000 行C++ 代码。 那他 10 天就能写好10,000 行代码?! 而且什么叫 写好 10,000 行代码? 如果你估计一个项目的代码量是10万行, 难道 10个像果冻这样的人 10 天就能做完?
所以我们做软件的估计, 事实上是 (估计的工作量 / 估计的人员能力), 如果两个估计都差一两个数量级, 那么我们最终估计的结果就会偏离十万八千里.
我在上课的时候给学生布置这样的课堂练习:
一个小组的同学 (6-8 人) 决定要徒步遍历中国陆地边界, 假设硬件装备齐全, 估计需要多长时间?
很多软件项目就是这样雄心勃勃地开始的, 大家觉得当年某某牛人/公司也这样做出来世界级的软件, 我们现在还有互联网, 我们小组里还有人精通设计模式, 这有什么可怕? 他们甚至连硬件装备都不齐全, 就开始行军了.
你觉得他们会花多长时间? 用什么样的办法能让同学们方便地交流各自的估计, 最后到达大致理性和统一的共识?
答案明天揭晓。
