【外评】我们为何不擅长估算软件项目
好吧,我就直说了:
对任何重要的软件项目进行精确估算都是不可能的。
现在,你们当中肯定有不少人读到这句话会觉得我疯了。 也许我是疯了。但总得有人说出我们都知道是事实却不愿承认的事实。
听着,关于如何更好地估算软件项目,已经有数不清的书籍、数不清的会议、数不清的咨询时间和写不完的博文。我明白这一点。我们都在认真工作,全力以赴,试图安抚那些想知道新功能何时准备就绪的饥渴的老板。我们都会根据会议日期而不是软件实际准备就绪的时间来设定最后期限。
但最根本的一点是,我们根本做不到。好吧,我们能做到–事实上,我们一直在这样做–但我们做不好。换句话说,我们总是错的。
我的意思是,我们不断花钱,参加研讨会,阅读博客和书籍。我们请来高薪聘请的顾问,他们装出一副了如指掌的样子。但情况始终没有好转。我们做得很烂,我们一直以为我们可以改进,以为下一个流行真的会是灵丹妙药。但我们不承认自己知道的事实:我们根本无法对软件项目进行有把握的估算。
我们都做过这样的项目,我们以为会花很长时间,结果却花了两倍或三倍的时间。你可能参与过一个项目,该项目只用了预期时间的一半就完成了。但是,在实际的、最初的估算时间内完成的项目却非常罕见和奇怪。然后,当我们应用霍夫斯塔德定律(”即使考虑到霍夫斯塔德定律,花费的时间也总是比你预期的要长”)并将估算时间翻倍时,事实证明这也是错误的。
出现这种情况是有原因的。最突出的一个原因,也是我认为大多数人最难接受的一个原因是,每个软件项目都是独一无二的,都有自己的一长串 “未知数”。你可以花无数个工时对一个项目进行规划、制定战略、分块、折叠、纺线和肢解,但你仍然不知道在实际编写代码时会遇到哪些困难。有些你认为具有挑战性的事情最终会变得很容易。但最常见的情况是,你会大大低估项目中某些特定方面所带来的挑战。
当然,之所以会出现这种情况,是因为一般的软件管理者总是认为,通往目的地的道路会是一条平坦笔直的高速公路,一路上天气晴朗。而事实根本不是这样。需求不断变化,项目规模却从未缩小。人们会突然请假。其他项目或优先事项干扰。销售部门需要一个小小的调整来完成一笔重要的交易。从头到尾,没有什么是顺风顺水的。从来没有。
我有一个拥有计算机工程专业高学历的朋友,每当我这样说,他都会很生气,但真正的问题是,软件开发并不是一门工程学科。相反,它是一个深陷于不断变化的人类欲望、相互影响的个性和动力、不断变化的客户理解以及不科学的解决方案的过程。软件开发是一个创造性的过程,而不是一个科学的过程,创造性的工作不可能被提炼为可知的步骤和可重复的系统。
嘿,我知道这很难听。 企业–我指的是客户–不想听到 “嗯,我们真的不确定什么时候能为您提供”。他们会寻找那些会告诉他们想听的话的供应商,即使这完全是胡扯。 公司要赚钱,就必须尽早创造价值。新功能的演示实际上必须在特定日期的会议上进行。
我们需要想办法接受并忍受这一点。我之所以这么说,是因为我认为,作为一个行业,我们已经对软件估算的圣杯进行了长达数十年的探索,而且我们将永远如此。但是,我们永远也不会找到答案。我们就是不会。在我们认清这一点之前,我们将挣扎、挣扎,继续告诉自己一些明知不可能的事情。
我没有解决办法,我甚至怀疑是否有解决办法。接受这一点是面对一个永远不会消失的问题的第一步。
本文文字及图片出自 Why we suck at estimating software projects
你也许感兴趣的:
- 具有魔法的 H.264
- 多用户环境中的 rootless Docker
- 【外评】微软的人工智能聊天机器人将 “回忆 “您在其新 PC 上所做的一切
- 【外评】苹果需要解释重新出现已删除照片的错误
- 你需要知道的现代 CSS 技巧(2024 年春季版)
- 使用 :has() 作为 CSS 父选择器及其他更多内容
- 【外评】大科技公司致欧盟:“去死”
- npm又被滥用,灰产用《庆余年2》盗版资源——把开源公共基础设施的羊毛薅秃了
- 【外评】如果您没有在 Edge 中使用必应,微软现在会说您的电脑需要 “修复”
- Chrome 浏览器开发工具(DevTools)现在使用双子座(Gemini )来帮助处理控制台中的 JavaScript 错误
你对本文的反应是: