1在互联网时代，交付速度是当今软件开发的主题。

十年前，项目通常要持续好几年，并且项目阶段是以月来衡量的。

如今，多数团队的项目周期是按月来衡量的，而项目阶段则减少到几周甚至几天。

任何需要长远规划的东西都将被抛弃，比如大量的前期软件设计和详细的需求分析。

超过项目阶段平均周期的任务将不复存在。

跟代码冻结（Code Freeze）以及数周的手动回归测试说再见吧！变化频率如此之高，文档很快就会过时。

不断更新详细需求说明和测试计划（Test Plan）需要投入大量精力，相当浪费。

那些以往在日常工作中依赖于此的人们，如业务分析师或者测试人员，在这个每周迭代的新环境中经常会无所适从。

开发人员原本以为不会受到纸质文档缺失的影响，现在却要把时间浪费在不必要的返工与功能维护上。

他们不是花时间去制订宏伟的计划，而14 是要浪费数周的时间去修正有问题的产品。

在过去的十年里，软件开发社区致力于使用“正确”的方式来构建软件，关注使用技术实践和思想来确保质量。

但是，正确地构建产品和构建正确的产品是两码事。

我们要二者兼顾才能取得成功。

14图1-1 实例化需求说明可以帮助团队构建正确的软件产品，而技术实践可以确保正确地构建产品 想要有效地构建正确的产品，软件开发实践必须满足以下几点。

保证所有项目干系人和交付团队的成员都对需要交付哪些东西有一致的理解。

有准确的需求说明，这样交付团队才能避免由模棱两可和功能缺失造成的无谓返工。

有用来衡量某项工作是否已经完成的客观标准。

具有引导软件功能或团队结构变更的文档。

传统意义上，构建正确的产品需要庞大的功能需求说明、文档以及漫长的测试阶段。

如今，软件每周都要有交付，这一套已经行不通了。

我们寻求的方案要能带来如下好处。

避免过度说明需求从而产生浪费，避免花时间在开发前会发生改变的细节上。

有一种可靠的文档，可以解释系统的行为，据此我们能容易修改系统行为。

可以有效地检查系统行为与需求说明的描述是否一致。

以最少的维护成本维持文档的相关性与可靠性。

适合短迭代和基于流的过程，这样能为即将开展的工作提供即时足够的信息。

第1章 主要优点14图1-2 对于敏捷项目，构建正确文档的关键因素乍一看，这些目标似乎互相冲突，但有很多团队已经成功地达成了所有目标。

在为本书做调研时，我采访了30个团队，他们完成了大约50个项目。

我试图找出一些模式与通用做法，并挖掘出这些方式背后的基本原则。

这些项目的共同思想，定义了一种构建正确软件的好方法：实例化需求说明。

实例化需求说明是一组过程模式，它帮助团队构建正确的软件产品。

使用实例化需求说明，团队编写的文档数量恰到好处，在短迭代或基于流的开发中可以有效地协助变更。

实例化需求说明的关键过程模式将在下一章介绍。

本章我将阐述实例化需求说明的好处。

我将使用实例化需求说明的风格来进行阐述，而不是以理论介绍的方式来构建一个案例，我将展示18个真实的例子，它们都来自于那些大大受益于实例化需求说明的团队。

在开始之前，我想强调一下，在一个项目中很难孤立地看待某种思想的影响或作用。

本书所描述的实践，可以与已经开展的敏捷软件开发实践[例如测试驱动开发（TDD ）、持续集成以及使用用户故事做计划等]共同使用，而且可以增强其他实践的效用。

当我们转而去看那些有着不同背景的项目时，很多模式浮现了出来。

我采访的团队中，有些在实施实例化需求说明前一直使用敏捷过程，而有些团队则是在过渡到敏捷过程的过程中实施了实例化需求说明。

大多数团队使用基于迭代的过程，例如Scrum 和极限编程，或者是基于流的过程，例如看板。

但是有些团队，尽管他们使用了这些实践，但他们的过程以任何标准来看都不是敏捷的过程。

然而，他们大多都收获了如下类似的收益。

更有效地实施变更。

他们拥有活文档——系统功能的可靠信息来源——让他们得以分析潜在变更的影响，同时可以有效地分享知识。

更高的产品质量。

他们清晰地定义了预期，使得验证过程很有效率。

更少的返工。

他们在需求说明上协作得更好，并确保所有团队成员对预期达成共识。

14同一项目不同角色的活动协调得更好。

改善协作形成定期的交付流程。

在接下来的4个小节中，我们将通过现实世界的例子，近距离地审视这些收益。

1.1 更有效地实施变更在为本书做调研的过程中，我获得的最重要的经验是关于活文档（living documentation ）的长期收益的——事实上，我认为这是本书的一个最重要信息，本书广泛地涵盖了这部分内容。

活文档是系统功能的一个信息源，它与程序代码一样可靠，但更容易使用和理解。

活文档帮助团队共同分析变更所带来的影响并讨论潜在的方案。

团队还可以为新的需求扩展已有的文档。

长此以往，可以使需求说明和实施变更更有效。

大多数成功的团队都发现活文档的长期收益是实施实例化需求说明所带来的结果。

总部设在美国西得梅因市的爱荷华州助学贷款流动资产管理公司（Iowa Student Loan Liquidity Corporation ，下文简称Iowa Student Loan ），在2009年进行了一项相当重要的商业模式变更。

过去一年，金融市场动荡使得贷款方几乎无法为私人学生贷款找到资金来源，因此，许多贷款方被迫放弃私人学生贷款市场或改变自己的商业模式。

该公司适应了当时的市场。

它从银行和其他金融机构募集资金来支助私人助学贷款，而不是使用债券收益。

Tim Andersen 是一位软件分析师，同时也是一名开发人员，他说为了有效地适应市场，他们不得不“有声有色地进行系统核心大检修”。

在开发软件时，他们的团队把活文档作为一项主要机制来编写业务需求文档。

活文档系统让他们可以探悉新需求所带来的影响、帮助他们确定所需14的变更，而且可以确保系统的其余部分仍旧正常工作。

他们当时只花了一个月时间就对系统实施了根本性的变更并将其发布到了生产环境，活文档系统是做这项变更的根本。

Andersen 说：任何未进行这些测试（活文档）的系统，都必将导致开发停顿和重写。

在加拿大魁北克省的蒙特利尔市，Pyxis 技术公司的Talia 项目团队也有类似的经验。

Talia 是企业系统的一个虚拟助理，它是一个拥有复杂规则、能与员工交流的聊天机器人。

从最初开始，Talia 团队就使用实例化需求说明来构建一个活文档系统。

一年之后，他们不得不从头开始编写虚拟代理引擎的核心——而此时，正是在活文档方面的投资大显成效的时候。

Talia 的产品总监Andr é Brissette 是这样说的：如果没有活文档，任何重大重构都无疑是自寻死路。

他们的活文档系统使得团队在变更完成时可以自信地说，新系统具有和老系统一样的功能。

该活文档系统还能帮助Brissette 管理并追踪项目的进度。

总部位于伦敦的现场音乐消费性网站Songkick 的团队在重新开发网站活动摘要时，使用了一个活文档系统来协助变更。

他们意识到目前的摘要系统无法扩展到所需的容量，活文档在重新构建摘要系统时就提供了有力的支持。

Phil Cownas 是Songkick 的CTO ，据他估计，因为拥有了活文档系统，他们的团队在实施变更时节省了至少50％的时间。

据Cowans 所述： 因为我们拥有让人满意的覆盖率，并且我们确实信任这些（在活文档系统里的）测试，所以我们很有信心可以快速地对基础结构进行大的变更。

我们知道，系统功能不会改变，即使变了，测试也会发现。

ePlan Services是一个养老金服务机构，位于科罗拉多州的丹佛市，它的开发团队从2003年开始就已经使用了实例化需求说明。

他们构建并维护一个金融服务系统，该系统涉及众多的项目干系人、复杂的业务逻辑以及复杂的监管需求。

在项目开始三年之后，其中一位经理搬去了印度，而对于系统遗留部分，有些内容是只有他才掌握的。

根据ePlan Services的测试人员及Agile Testing:A Practical Guide for Testers and Teams①一书作者Lisa Crispin的描述，当时，团队努力地学习那位经理所拥有的知识并将其构建成活文档。

活文档系统帮助他们获得了业务流程的专业知识，并立即提供给所有的团队成员。

他们借此消除了知识传递的瓶颈，可以有效地支持并扩展系统。

在比利时Oostkamp的IHC集团，病人管理中心项目组实施了一个活文档系统，并取得了类似的结果。

该项目开始时重写了一个大型机系统，它是从2000年开始的，目前还在进行中。

Pascal Mestdach是该项目的方案架构师，他说团队从中受益匪浅：当时遗留系统中的一部分功能只有少数几个人了解，而现在情况已经好很多了，那14是因为团队拥有一套针对那部分功能的、不停增长的测试套件（活文档），它描述了该遗留系统的功能。

当专家休假时，还可以从活文档系统中寻找问题的答案。

对其他开发人员来说，可以更清晰地了解软件中某部分的功能。

并且还是测试过的。

——————————①该书中文版名为《敏捷软件测试：测试人员与敏捷团队的实践指南》，已由清华大学出版社于2010年出版。

——译者注这些例子阐述了活文档系统如何帮助交付团队分享知识并应付人员变动。

它还使得业务可以更有效地响应市场变化。

我将在第3章里对此做更具体的说明。

1.2更高的产品质量实例化需求说明可以改善交付团队成员之间的协作，促进商业用户更好地参与，并为交付提供清晰客观的目标——大幅提高产品质量。

有两个突出的案例，分别来自Wes Williams[来自世博控股（Sabre Holdings）的敏捷教练]以及Andrew Jackman[为法国巴黎银行（BNP Paribas）的一个项目工作的顾问开发人员]，他们将描述之前失败过多次的项目如何通过实例化需求说明走向成功。

本书中描述的方法帮助他们的团队克服了业务领域的复杂性，之前这种复杂性是很难处理的。

同时还帮助他们确保了交付的高质量。

在世博控股，Wes Williams工作的项目是一个为期两年的航班订票项目，团队分布在全球各地，流程又是数据驱动的，这使得项目十分复杂。

项目有3个团队，30名开发人员，分布于两个洲。

据Williams说，系统头两次构建都失败了，但是第三次使用实例化需求说明后就成功了。

Williams说：14我们在一家大客户（一家大型航空公司）上线时缺陷非常少，在（业务验收）测试阶段只有1个缺陷是比较严重的，是故障切换（fail-over）相关的问题。

Williams认为实例化需求说明是他们取得成功的一个关键因素。

除了保证高质量外，实例化需求说明还有助于建立开发人员和测试人员之间的信任。

14在法国巴黎银行，Sierra 项目是另一个很好的例子，可以展现实例化需求说明如何带来高质量的产品。

Sierra 是一个债券的数据仓库，整合了一些内部系统、评级机构和其他来自外部的信息，并将它们分发给银行内部的各种系统。