BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

估算是一种,很难的东西,如影~随行~

| 作者 申健 关注 0 他的粉丝 发布于 2012年5月2日. 估计阅读时间: 4 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

最近Uncle Bob发表了新的博客《为什么估算这么难?》。

Bob大叔首先抛出一个问题,如何将著名的葛底斯堡演说的237个单词以固定字体和固定行宽写在一张书签上。如果人工执行这个任务,假设每秒钟处理一个单词来寻找合适的断句点,估计5分钟内就可以完成,而且实际花费时间也和估计的差不多。然而,如果要编写程序来做,要花多久?而且是在知晓算法、没有意外情况、没有绊脚石、无需备份和恢复功能的情况下,编写程序要花多久时间?

Bob大叔提醒说:程序只不过是遵循某个过程的具体指令,而这个过程是已知的。在动手写程序之前给出3个估算,最佳情况、最差情况和正常情况。根据Bob大叔的统计,大部分人需要花上30-45分钟,也有人用了15分钟,还有人用90分钟。这样,很多人之前的估算与实际花费相差悬殊。其中一个原因,他们基于手工任务看似简单来进行估算的。

Bob大叔回忆某个下午和Kent Beck采用测试驱动开发来结对编程写这个算法。他们估计这需要10-15分钟,结果花了30分钟却毫无进展。在被迫接受这个体验后思考,为什么这算法这么难?为什么把如此简单和直观的过程写下来这么难?

其实,人类是目标导向的,在分解文字时,人类不会遵循一个过程,而是不断评估输出,然后调整做法直到正确为止,因此会预估5分钟之内完成。而过程是盲目的,它不管输出是否正确。如果过程错了,那输出结果也会错。人类不了解过程,不了解过程的难度如何。人类不是电脑,做事的时候不会遵循过程,所以无法比较过程任务和手工任务的复杂性。这就是估算为什么难,而且经常犯错的一个原因:任务看上去简单,人们基于这个表面现象来估算,之后却发现写出过程实际上是多么复杂。人们估算不准是因为估算了错误的东西。

回到分解长字符串的例子。每次分解一行,记录下分解位置和选择这个位置的原因。将其概括为三个不同的场景:

  1. 如果单词长于10个字符,在第10字符处断词。
  2. 如果第11个字符是空格,在第11字符处断词。
  3. 从第10个字符向回查找,如果找到一个空格,就在该处断词。

这些场景仍然需要被组成一个过程,但是至少知道这个过程有几个部分组成,从而使估算更容易。

这个故事的寓意是任务看似容易被人类解决,却经常被描述为复杂的过程。所以估算时,确保不要被简单的表面现象所迷惑。深入进去,尝试列举出过程所包含的场景数量。

博文显示估算失真有多容易。人脑不善于回答抽象问题,往往替换实际问题为一个直觉问题。而直觉在寻找答案时,如同博文所说,以期望结果的产生来考虑问题,不关注未知或可能出错的东西,而是关注那些能够理解的东西。

博文引发大量讨论。有人认为分解过程为小的片段并无价值,有价值的是知道哪类问题是困难的和为什么困难。也有人认为多练习有助于提高估算准确度,或者让有经验的人而不是新手估算。然而经验最可以依靠,却仍然可能出错,除非项目与之前完全一样。

除了博文所讨论的原因,还有人认为,团队水平、办公室政治、企业缺乏变更控制,也都成为导致估算不准确的原因。

更多的人吐槽:在实际中,估算往往发生在没有明确需求可以参考的时候,更不用说之后不断变化的需求、未知因素、代码基础中隐藏的陷阱。因此固执地遵循最初的时间表也使得估算看起来是不准确的。而且开发人员面对来自于客户和经理的压力时,往往倾向于低估时间表。

InfoQ的读者们,你们对于估算有什么样的经验?什么时候估算得准确,什么时候又不够准确呢?


给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

办公室政治,没有需求 by 普 南

办公室政治和需求的不确定确实对估算造成很大影响,另外破坏规则的永远都是制定规则的。

大多数评估忽视了过程 by 曹 力文

在分解文字时,人类不会遵循一个过程,而是不断评估输出,然后调整做法直到正确为止,因此会预估5分钟之内完成。大多数评估忽视了过程。

对估算难度的直观解释 by 朱 敏

讨论贴里面有人给出了一个相关链接,里面有人形象直观的解释了为什么估算难(不准)的问题。我翻译了一下:www.cnblogs.com/jonyzhu/articles/2480524.html ,推荐。

最佳的“算法” by 朱 敏

从原文讨论贴里面,我找到这个“算法”,使用 (g)Vim:Ctrl + v, :set textwidth=13, Shift-V, gq
我觉得这是最佳的解决方案了!真是厉害啊!

推荐个不错的参考书 by cui ping

Software Estimation: Demystifying the Black Art
作者是Steve McConnell
在他的经典著作Rapid development里也能找到简略的相关内容

完全一样的项目不存在 by shi andy

然而经验最可以依靠,却仍然可能出错,除非项目与之前完全一样。
这不可能的。完全一样还开发个什么劲啊,直接用不就好了。

中国的项目都是那人堆出来的,什么估算不估算的? by shi andy

中国的项目都是那人堆出来的,什么估算不估算的?估算有问题,就加人月,不能加人,就加月,反正到时候出来就行了。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

7 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT