乐者为王

Do one thing, and do it well.

为什么我们不能用估算房屋同样的方法估算软件项目

英文原文:http://www.summa-tech.com/blog/2009/01/28/why-we-cant-estimate-software-project-the-same-way-we-estimate-houses

把构造软件类比成建造房屋是非常有用的,但也有缺陷。

尽管软件建设和住宅建设都是工程实践,但比起软件,我们在估算建造房屋的成本和精力方面更成功。

词汇障碍

因为我们大多数人一生都住在房子里,我们开发了一套定义良好的、可以理解的、几乎通用的词汇来描述和讨论关于我们称之为家的地方。当被问及我们的房子是什么样子的,我们可以很容易地回答。当计划一所新房子时,我们可以极其肯定地讨论我们想要什么,并确信建筑师和工程师会明白我们谈论的,反之亦然。我们可能不明白水管设施和电气细节,但我们知道电源插座要放在哪里,知道房间的大小,知道要有多少车库门。

当我们谈论软件时,就不是那么有效了。有太多来自业务和技术方面的新术语,我们需要依赖于现实世界中的类比去解释它们。不仅发生在业务和技术人员之间,甚至还发生在业务人员和业务人员,技术人员和技术人员之间。我们不习惯于去描述软件需求因为所有软件的抽象,在估算时沟通经常受到噪音、误解、缺乏眼界的影响,增加了真正需要构建的不确定性。

物理

现实世界有非常强大和稳定的规则,比如重力,这些规则会在盖房子的时候施加约束。我们知道我们必须在构建二楼前先完成地下室。我们不能在地基完成后增加层的数量。在水管设施铺设后更改浴室的位置将会是非常非常昂贵的。

在软件项目中,我们生活在一个较少规则的世界里,就像《黑客帝国》。从技术上讲,我们可以在同一时间构造所有的应用层。它可以被设计成使用不同的数据库,运行在不同的服务器,或支持不同的语言。它可以通过浏览器、手机、或其它无线设备访问。选项几乎是无穷无尽的。

正是这种自由和灵活性,在过去的40年里驱动了软件的巨大的进步,但在同时,它也是无数软件项目失败的原因。至关重要的是需求要面对现实,让它们遵守一些基本规则,即使它们不受宇宙物理规律的约束。

程序

物理和几千年建设的结合已经带来了如何去建造一座房子的一套可靠的程序,虽然总是会有新的材料和改进的技术,核心概念都是相同的。油漆房子的过程几百年来几乎没有变化。

我们仍然处于软件工程的早期阶段。大量的“直觉”仍在估算软件时使用,实际情况是直觉还没有被证明非常有效。

材料和标准

只有数量有限的材料能被实际地用在建造房屋上。从技术上来讲,可能有成千上百的选项去建造一堵墙:夹板、混凝土、钢铁、沙子、玻璃,但在家具建材零售店里这些选项是非常有限的。涂料的类型,门窗的模型很多但有限。当购买一个水槽时,它很容易兼容已有的水管设施的几率非常高。电器有着相同的电压,灯泡也是兼容的。计划建造一所房子的一切都是兼容的,材料更是普及的,把不确定性降低到了非常小的水平,提高了估算的准确性。

软件行业确实有一些标准,但是它们处于层的最低水平,例如网络协议和文件系统。服务器和产品的集成仍处于布线阶段,XML和Web Service还有很长的路要走,在它们和建筑业达到相同级别的兼容性前,如果这是可能的。

各种各样连接到数据库和构建软件的选项和方法增加了复杂性,提高了每个人参与软件构建工作的学习曲线。我不是说所有这些选项都是不好的,但它确实给估算阶段增加了不确定性,所以产生了复杂性。

角色

每次我路过建筑工地,都会看到很多帽子,一些在积极工作,一些在等待时机采取行动。但最好的部分是我从来没有见过有人同时戴两顶帽子。角色界定的很明确,工人们专业从事于非常具体的领域。

在大型软件项目中也有一些角色被定义,但还远远没有达到建筑业相同级别的专业化。通常团队成员需要戴上很多帽子,结果是,有时候他们会执行那些他们不是专家的任务,这就增加了他们提供的估算的不确定性。

“很多帽子”现象的一个很好例子是“Webmaster”,该角色用于描述那个做网页设计、创建动画图片、编写HTML和Perl代码、配置数据库、管理网络和邮件服务器的家伙。幸运的是现在Webmaster是个很少使用的术语,因为所有这些活动现在都分配给了不同的角色,像网页设计师、DBA,程序员和系统管理员。我们确实在走向专业化,但还是有很长的路要走。

我并不是建议我们停止使用“让我们像建造房屋那样构造软件”的类比,但我们必须意识到这个比喻的局限性。一旦我们知道局限性我们将能更好地定位讨论这一差异,以及提供建议如何解决它们。

Comments