与许多古老的职业相比，人们从事软件开发的时间并不长。但就在这短短的几十年中，人们根据软件行业的经验，并从其他行业(如建筑业、制造业)借鉴，总结了不少“最佳实践”。特别是最近十年以来，这些最佳实践似乎分裂成为两大阵营:重型方法学和敏捷方法学。这两大阵营的拥护者都不少，并且领军人物都是德高望重。

　　软件项目的目标

　　在讨论这些最佳实践之前，先明确一下软件项目的目标，因为所有的最佳实践都是为实现项目目标服务的。Alistair Cockburn在他的著作《敏捷软件开发》中指出，软件项目的目标有两个，取得当前项目的成功并进行积累，为后续的项目做准备。

　　关于第一个目标，一个比较麻烦的事情就是如何定义成功。一般来说，大家认为在预算范围和进度计划之内交付客户想要的产品，项目就算是成功的。但这样的理解似乎过于初级。Dewys Lasdon曾指出，“我们的工作不是用限定的费用及时地给客户他想要的东西，而是给他从未梦想过的东西;当他得到的时候，他意识到这就是他一直想要的东西。”如果你结合iPod取得的成功来看，就能很好地理解这段话的含义了。

　　关于第二个目标，主要有两层意思。第一层意思是“锻炼队伍”。在项目中，团队共同工作一段时间，进行了许多“战术配合”方面的练习，大家相互之间更有默契。对于个人来说，通过具体的开发实践，学习了不少新知识，也积累了经验。

　　第二层意思是为后续项目提供积累。后续项目可能是运维项目，也可能是产品的下一个版本，或其他项目。不少项目开发工作对于后续项目有重要意义，如项目文档和回归测试套件等。如果你曾接手过别人的项目，或者只是花时间读过别人的程序，就一定会对此深有感触。

　　顺便提一下，项目的第二个目标不一定是次要目标。对于某些领航项目或概念验证项目来说，为后续项目提供经验积累就是项目的首要目标，也是项目成功的衡量标准之一。

　　RUP

　　根据IBM的官方说法，“Rational Unified Process是一个灵活的软件开发流程平台。借助它可配置的构架，RUP 使你能够只选择和部署项目的每个阶段需要的流程构件。RUP 平台以业界公认的软件工程最佳经验为核心，它包含配置 RUP 以满足项目特定需求的工具。从这种意义上说，RUP 是一个软件开发方法框架，以及一个公认的、灵活的、实用的流程平台，用于成功的软件项目。” RUP提出了六项最佳实践:

　　1. 迭代的开发软件

　　2. 需求管理

　　3. 使用基于构件的体系结构

　　4. 可视化软件建模

　　5. 验证软件质量

　　6. 控制软件变更

　　让我们来看看其中的需求管理。一项调查(James Martin，“An Information Systems Manifesto”，Prentice Hall，1984)表明56%的缺陷其实是在软件需求阶段被引入的。而这其中的50%是由于需求文档编写有问题、不明确、不清晰、不正确导致的。剩下的50%是由于需求的遗漏导致的。更重要的是，许多需求缺陷直到很晚才被发现。而缺陷发现得越晚，修复缺陷所需的代价就越大。所以在传统软件工程方法中，非常重视需求工作，甚至称这部分工作为需求工程。

　　需求工程的主要出发点是减少需求中的缺陷，从而降低项目风险。Joel Spolsky 指出:“首先，没有编写规格说明是软件项目中你所承担的一个最大的、不必要的风险。”特别是在外包项目中，绝大多数客户都不会同意没有需求规格说明书的开发方式，因为这样做风险太大，实在不值得冒这个险。

　　需求工程的另一项重要使命是发现机会，即发现创新的产品，为用户提供更多价值的机会。如果你草率对待需求工作，将丧失这种机会。例如，在我们进行业务流程分析时，应该适当关注企业流程再造，业务管理创新，实现更多客户价值的机会。只有这样，才能可能做出Dewys Lasdon所说的客户“从未梦想过的东西”。

　　需求工程中的一个重要方面是管理需求的可追踪性，即从项目的总体目标追踪到业务用例，再追踪到实现用例和具体需求，最后追踪到实现和测试的能力。如果忽视了这个方面，项目的开发可能会偏离方向。

　　我们在编写需求时，常常会用到一些文档模板，如需求规格说明书模板和用例模板。某些模板非常全面、细致，以至于某些部分我们初看上去甚至觉得可以忽略掉。但是当你打算忽略掉模板中的这些部分时，千万要小心，因为模板的主要作用之一就是降低遗漏需求的风险。

　　有一次一名项目经理打算在开发团队中引入用例模板，查找了一些资料之后，写了一个草稿让我复查一下。我发现他的模板中没有用例的使用频度，问他时他说，觉得没有太大作用就裁掉了。于是我告诉他，用例使用的频度对系统的设计和实现有很大的影响，这属于系统的非功能需求，不能省略。

　　如果你想进一步了解需求工程，推荐你读一下《掌握需求过程》这本书。