软件项目的目标
在讨论这些最佳实践之前，先明确一下软件项目的目标，因为所有的最佳实践都是为实现项目目标服务的。Alistair Cockburn在他的著作《敏捷软件开发》中指出，软件项目的目标有两个，取得当前项目的成功并进行积累，为后续的项目做准备。
关于第一个目标，一个比较麻烦的事情就是如何定义成功。一般来说，大家认为在预算范围和进度计划之内交付客户想要的产品，项目就算是成功的。但这样的理解似乎过于初级。Dewys Lasdon曾指出，&ldquo我们的工作不是用限定的费用及时地给客户他想要的东西，而是给他从未梦想过的东西当他得到的时候，他意识到这就是他一直想要的东西。&rdquo如果你结合iPod取得的成功来看，就能很好地理解这段话的含义了。
关于第二个目标，主要有两层意思。第一层意思是&ldquo锻炼队伍&rdquo。在项目中，团队共同工作一段时间，进行了许多&ldquo战术配合&rdquo方面的练习，大家相互之间更有默契。对于个人来说，通过具体的开发实践，学习了不少新知识，也积累了经验。
第二层意思是为后续项目提供积累。后续项目可能是运维项目，也可能是产品的下一个版本，或其他项目。不少项目开发工作对于后续项目有重要意义，如项目文档和回归测试套件等。如果你曾接手过别人的项目，或者只是花时间读过别人的程序，就一定会对此深有感触。
顺便提一下，项目的第二个目标不一定是次要目标。对于某些领航项目或概念验证项目来说，为后续项目提供经验积累就是项目的首要目标，也是项目成功的衡量标准之一。
RUP
根据IBM的官方说法，&ldquoRational Unified Process是一个灵活的软件开发流程平台。借助它可配置的构架，RUP 使你能够只选择和部署项目的每个阶段需要的流程构件。RUP 平台以业界公认的软件工程最佳经验为核心，它包含配置 RUP 以满足项目特定需求的工具。从这种意义上说，RUP 是一个软件开发方法框架，以及一个公认的、灵活的、实用的流程平台，用于成功的软件项目。&rdquo RUP提出了六项最佳实践:
1. 迭代的开发软件
2. 需求管理
3. 使用基于构件的体系结构
4. 可视化软件建模
5. 验证软件质量
6. 控制软件变更
让我们来看看其中的需求管理。一项调查(James Martin An Information Systems Manifesto，Prentice Hall，1984)表明56%的缺陷其实是在软件需求阶段被引入的。而这其中的50%是由于需求文档编写有问题、不明确、不清晰、不正确导致的。剩下的50%是由于需求的遗漏导致的。更重要的是，许多需求缺陷直到很晚才被发现。而缺陷发现得越晚，修复缺陷所需的代价就越大。所以在传统软件工程方法中，非常重视需求工作，甚至称这部分工作为需求工程。
需求工程的主要出发点是减少需求中的缺陷，从而降低项目风险。Joel Spolsky 指出:“首先，没有编写规格说明是软件项目中你所承担的一个最大的、不必要的风险。”特别是在外包项目中，绝大多数客户都不会同意没有需求规格说明书的开发方式，因为这样做风险太大，实在不值得冒这个险。
需求工程的另一项重要使命是发现机会，即发现创新的产品，为用户提供更多价值的机会。如果你草率对待需求工作，将丧失这种机会。例如，在我们进行业务流程分析时，应该适当关注企业流程再造，业务管理创新，实现更多客户价值的机会。只有这样，才能可能做出Dewys Lasdon所说的“客户从未梦想过的东西”。
需求工程中的一个重要方面是管理需求的可追踪性，即从项目的总体目标追踪到业务用例，再追踪到实现用例和具体需求，最后追踪到实现和测试的能力。如果忽视了这个方面，项目的开发可能会偏离方向。
我们在编写需求时，常常会用到一些文档模板，如需求规格说明书模板和用例模板。某些模板非常全面、细致，以至于某些部分我们初看上去甚至觉得可以忽略掉。但是当你打算忽略掉模板中的这些部分时，千万要小心，因为模板的主要作用之一就是降低遗漏需求的风险。
有一次一名项目经理打算在开发团队中引入用例模板，查找了一些资料之后，写了一个草稿让我复查一下。我发现他的模板中没有用例的使用频度，问他时他说，觉得没有太大作用就裁掉了。于是我告诉他，用例使用的频度对系统的设计和实现有很大的影响，这属于系统的非功能需求，不能省略。
文章来源于领测软件测试网 https://www.ltesting.net/