程序员软件项目预估的宝贵经验

本文由码农网 – 小峰原创翻译,转载请看清文末的转载要求,欢迎参与我们的付费投稿计划

我最近参加了一个关于软件预估的课程。对于这种本质上就是非精确的科学,我一向都非常谨慎,因为我深信预估可以创造价值。在这个历时两个小时的课程中,我发现了如何提醒大家进入预算而不必过度分析和思考的方法。

非常常见的例子

我们经常能听到项目经理和开发人员之间类似于这样的对话:

PM:“你能不能给我一个开发某某功能所需要的预估时间?”

程序员:“一个月”

PM:“一个月时间太长了,我们只有一周时间!”

程序员:“最好三周”

PM:“我只能最多给你两周时间”

程序员:“好吧,成交!”

呵呵!猜猜接下来是什么情况?如果你在下决定之前能快速考虑一下预算与目标之间的差距,那你就不至于这样草率,也不至于在接下来的时间里焦头烂额。

结论截然不同的简图

在课程中有这么一张图片,它强调了精确预估的重要性。我粗略地照着原图重新画了一张:

图片表达的中心思想为,我们需要将精确预估作为目标。对此我不置可否。事实上,我想说的是,我们的预估永远达不到100%的精确。

为什么呢?因为预估本身就是一种并不精确的科学。虽然有很多很多方法(可能甚至比我们需要都要多)可以让我们擅长估计,但是总会有一些不确定性。没错,100%精确自然是最好的,但是在实践过程中,这是不可能的。

不仅如此,低估时间的成本也是不可承受之重。先看看例子:

  • 项目可能会失败(最坏的情况)。
  • 不断地通宵达旦
  • 高压和焦虑
  • 项目可能会延迟
  • 质量会受影响
  • 成本增加
  • 用户表示不满

有时候预估时间结果是非常重要的。因为如果你估高了,功能依然可以完成,其代价为耗费的时间多。但是如果你估低了时间,那么可能指定功能你甚至就完成不了。

预估后项目出现异常的原因之一

软件项目中的混乱源于精确的预估。

你知道是什么原因造成一个软件项目出现混乱的吗?原因就是项目进度落后于计划!我们将这种现象称之为正反馈效应(不要望文生义,正的反馈并不都是好的)。

还有一个预估方法是给出一个范围。这么做的效益/成本我们暂时不考虑,下面是使用范围估计最后却发现低估的例子:

下面是高估的例子:

曲线下面的阴影部分代表需要付出的努力、成本和计划进度,看上去明显比上图高估所需要的少得多。

当然100%的预估精准度自然是最为理想的,但是在实际操作中,其错误成本太高。

你的团队是否需要常常加班熬夜?下面这句话是我在一篇文章中看到的,印象非常深刻:

大多数软件开发,项目总是落后于原定计划。这样团队中的人就没有时间偷懒。

这种思想在我们这个行业非常普遍。我真心是想举双手双脚反对!这种想法显然是不公平不公正的。

因为很多开发人员在预估时,大多会有20%-30%乐观余度,换言之就是,开发人员普遍性会低估实际完成项目所需要的时间。这一点我深信不疑。

由此看来,精确的预估精度很有必要。但是结合这些简图,更重要的是,宁可高估啊!

译文链接:http://www.codeceo.com/article/programmer-estimating.html
英文原文:A developer's thoughts on estimating software development
翻译作者:码农网 – 小峰
转载必须在正文中标注并保留原文链接、译文链接和译者等信息。]

发表我的评论

取消评论
表情 插代码

Hi,您需要填写昵称和邮箱!

  • 必填项
  • 必填项

网友评论6

  1. 麻烦楼主写一篇针对不同项目不同的预估方法,或者公式,包括设计,编码,测试等

    Amazing2015-03-09 09:09 回复
  2. [赞]

    分分钟杀死你2015-07-13 20:26 回复
  3. 没讲到方法啊?都知道预估精确的重要性

    6632015-07-17 10:30 回复
  4. [心]

    985222016-01-15 21:27 回复