一个典型软件项目的故事

ACME公司的Widgets系统出了点问题。这个系统被他们用来管理器材的库存，当初设计时没考虑到如今这样大量的数据的增长。他们的员工因为这个问题备受折磨。很显然，需要想办法解决这个问题，让系统恢复正常。

经过对本地软件公司的一番筛选，ACME联系到了Hamster软件公司，看看他们能否解决这个库存系统中的问题。他们很喜欢Hamster软件公司的网站，他们没有任何软件开发的经验，但根据网站的外观，他们估计这个软件公司能解决他们的问题。这件事上他们并没有做错，但也不是很对。

于是，ACME公司和Hamster软件公司开始讨论如何解决他们库存系统中的问题。私底下，Hamster软件公司的开发团队知道以前从未处理过类似这样的问题，然而，他们有一群很能干的小伙，他们相信一定能把这个问题解决掉。

基于一个不符合实际情况的预估，ACME公司和Hamster公司达成协议一起努力来解决问题。这是他们犯的第一个错误。Hamster公司的开发团队认为，对现有的软件进行简单的修改就能满足他们的需求，并在此假设上制定出了工程估算。

起初，按照ACME公司认可的设计方案，Hamster公司的开发进展神速。不久之后，事情看起来，他们的确是有可能按照最初的设计预算来完成任务。

除了有一些bug需要解决。

起初的bug都很小，就Hamster公司设定这种一日千里的开发速度而言，ACME公司理解，开发进行中的软件不可能做到十全十美。他们很高兴能开始使用改造中的系统，对于出现的问题，开发团队已经有了更好的方案，所以，看起来，边改造边使用是没有问题的——尽管有些bug存在。

但是，Hamster软件公司的小伙都很能干。没有人希望bug的出现，但因为开发团队专注于解决扩容问题、写代码来升级系统，所以，有时候，很容易会发生一些意想不到的事情(bug)。随着开发的进行，项目规模的扩大，记住代码中各种编写策略的背后原因变得越来越困难，但是，他们是群能干的小伙，没有他们处理不了的问题。

Richard Hammond——Hamster公司的创始人之一，是一个优秀的程序员，他对这个项目做出了巨大的贡献。一天，Richard收到了来自Fifth Speed公司的聘请，Fifth Speed公司是一家非常出名的软件公司，Richard无法拒绝。Hamster公司的开发团队很沮丧，但对于这种事情，他们无能为力，只好顶着压力继续开发。

如果这些bug之前一些麻烦，而Richard的离去相当于火上浇油。他的脑袋里装有大量的关于每个东西为应该如何运作的知识，而现在，软件只能在没有他的情况下独自完成工作。各种征兆开始显露，Hamster公司开发的软件里有些东西并没有按要求运行。

Bug成倍增加。每一次新的版本的发布看起来都会导致越来越多之前已经完成的功能不能用。

作为解释软件应该做成什么样的唯一参考来源的规格说明书，如今已经增长到没有哪个人能单独掌握。

ACME公司距离他们解决库存系统问题的目标看起来是越来越遥远。每一次新版本的发布都是一次前进，但也是一次后退。他们用这个系统来提升他们的业务，但bug不仅影响了员工的使用，而且影响到了客户。

公司实际业务上的损失有这些bug的很大功劳。没错，ACME公司库存系统原始问题已经解决了，但却引入了其它问题，算起来得不偿失。这个庞大的系统本以为能解决ACME公司所有的问题，但现在看起来更像是一个负担，而不是资产。它每月还在不断的吞噬巨大的财力用于维护，远看不到尽头。

可不幸的是，这是如今大多数软件项目的现状。糟糕的计划，没谱的预算，无休无止的“维护”，使得我们软件开发世界对真正的软件项目失去信心。

只有我们共同努力，以整个行业之力，才能改进软件项目中估算和不切实际的期望等相关问题。

在试图解决问题前，一定要尽量理解问题。

测试你的代码，即使不为自己，也是为下一个接手你工作的人。[本文英文原文链接：The story of a typical software project. ]

来自: 外刊IT评论 http://www.aqee.net/