程序员软件项目预估的宝贵经验
我最近参加了一个关于软件预估的课程。对于这种本质上就是非精确的科学，我一向都非常谨慎，因为我深信预估可以创造价值。在这个历时两个小时的课程中，我发现了如何提醒大家进入预算而不必过度分析和思考的方法。
非常常见的例子
我们经常能听到项目经理和开发人员之间类似于这样的对话：
PM：“你能不能给我一个开发某某功能所需要的预估时间？”
程序员：“一个月”
PM：“一个月时间太长了，我们只有一周时间！”
程序员：“最好三周”
PM：“我只能最多给你两周时间”
程序员：“好吧，成交！”
呵呵！猜猜接下来是什么情况？如果你在下决定之前能快速考虑一下预算与目标之间的差距，那你就不至于这样草率，也不至于在接下来的时间里焦头烂额。
结论截然不同的简图
在课程中有这么一张图片，它强调了精确预估的重要性。我粗略地照着原图重新画了一张：
图片表达的中心思想为，我们需要将精确预估作为目标。对此我不置可否。事实上，我想说的是，我们的预估永远达不到100%的精确。
为什么呢？因为预估本身就是一种并不精确的科学。虽然有很多很多方法（可能甚至比我们需要都要多）可以让我们擅长估计，但是总会有一些不确定性。没错，100％精确自然是最好的，但是在实践过程中，这是不可能的。
不仅如此，低估时间的成本也是不可承受之重。先看看例子：
- 项目可能会失败（最坏的情况）。
- 不断地通宵达旦
- 高压和焦虑
- 项目可能会延迟
- 质量会受影响
- 成本增加
- 用户表示不满
有时候预估时间结果是非常重要的。因为如果你估高了，功能依然可以完成，其代价为耗费的时间多。但是如果你估低了时间，那么可能指定功能你甚至就完成不了。
预估后项目出现异常的原因之一
软件项目中的混乱源于精确的预估。
你知道是什么原因造成一个软件项目出现混乱的吗？原因就是项目进度落后于计划！我们将这种现象称之为正反馈效应（不要望文生义，正的反馈并不都是好的）。
还有一个预估方法是给出一个范围。这么做的效益/成本我们暂时不考虑，下面是使用范围估计最后却发现低估的例子：
下面是高估的例子：
曲线下面的阴影部分代表需要付出的努力、成本和计划进度，看上去明显比上图高估所需要的少得多。
当然100%的预估精准度自然是最为理想的，但是在实际操作中，其错误成本太高。
你的团队是否需要常常加班熬夜？下面这句话是我在一篇文章中看到的，印象非常深刻：
大多数软件开发，项目总是落后于原定计划。这样团队中的人就没有时间偷懒。
这种思想在我们这个行业非常普遍。我真心是想举双手双脚反对！这种想法显然是不公平不公正的。
因为很多开发人员在预估时，大多会有20％-30％乐观余度，换言之就是，开发人员普遍性会低估实际完成项目所需要的时间。这一点我深信不疑。
由此看来，精确的预估精度很有必要。但是结合这些简图，更重要的是，宁可高估啊！
译文链接：http://原网站已经失效/article/programmer-estimating.html
英文原文：A developer's thoughts on estimating software development
翻译作者：码农网 – 小峰