实例化需求的优点

文/Gojko Adzic

在互联网时代，交付速度是当今软件开发的主题。十年前，项目通常要持续好几年，并且项目阶段是以月来衡量的。如今，多数团队的项目周期是按月来衡量的，而项目阶段则减少到几周甚至几天。任何需要长远规划的东西都将被抛弃，比如大量的前期软件设计和详细的需求分析。超过项目阶段平均周期的任务将不复存在。跟代码冻结（Code Freeze）以及数周的手动回归测试说再见吧！

变化频率如此之高，文档很快就会过时。不断更新详细需求说明和测试计划（Test Plan）需要投入大量精力，相当浪费。那些以往在日常工作中依赖于此的人们，如业务分析师或者测试人员，在这个每周迭代的新环境中经常会无所适从。开发人员原本以为不会受到纸质文档缺失的影响，现在却要把时间浪费在不必要的返工与功能维护上。他们不是花时间去制订宏伟的计划，而是要浪费数周的时间去修正有问题的产品。

在过去的十年里，软件开发社区致力于使用“正确”的方式来构建软件，关注使用技术实践和思想来确保质量。但是，正确地构建产品和构建正确的产品是两码事。我们要二者兼顾才能取得成功。

图1-1　

图1-1　实例化需求说明可以帮助团队构建正确的软件产品，而技术实践 可以确保正确地构建产品

想要有效地构建正确的产品，软件开发实践必须满足以下几点。

• 保证所有项目干系人和交付团队的成员都对需要交付哪些东西有一致的理解。
• 有准确的需求说明，这样交付团队才能避免由模棱两可和功能缺失造成的无谓返工。
• 有用来衡量某项工作是否已经完成的客观标准。
• 具有引导软件功能或团队结构变更的文档。

传统意义上，构建正确的产品需要庞大的功能需求说明、文档以及漫长的测试阶段。如今，软件每周都要有交付，这一套已经行不通了。我们寻求的方案要能带来如下好处。

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

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

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

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

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

图1-2　

图1-2　对于敏捷项目，构建正确文档的关键因素

乍一看，这些目标似乎互相冲突，但有很多团队已经成功地达成了所有目标。在做调研时，我采访了30个团队，他们完成了大约50个项目。我试图找出一些模式与通用做法，并挖掘出这些方式背后的基本原则。这些项目的共同思想，定义了一种构建正确软件的好方法：实例化需求说明。

实例化需求说明是一组过程模式，它帮助团队构建正确的软件产品。使用实例化需求说明，团队编写的文档数量恰到好处，在短迭代或基于流的开发中可以有效地协助变更。

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

在开始之前，我想强调一下，在一个项目中很难孤立地看待某种思想的影响或作用。本文所描述的实践，可以与已经开展的敏捷软件开发实践[例如测试驱动开发（TDD）、持续集成以及使用用户故事做计划等]共同使用，而且可以增强其他实践的效用。当我们转而去看那些有着不同背景的项目时，很多模式浮现了出来。我采访的团队中，有些在实施实例化需求说明前一直使用敏捷过程，而有些团队则是在过渡到敏捷过程的过程中实施了实例化需求说明。大多数团队使用基于迭代的过程，例如Scrum和极限编程，或者是基于流的过程，例如看板。但是有些团队，尽管他们使用了这些实践，但他们的过程以任何标准来看都不是敏捷的过程。然而，他们大多都收获了如下类似的收益。

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

更高的产品质量。他们清晰地定义了预期，使得验证过程很有效率。

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

同一项目不同角色的活动协调得更好。改善协作形成定期的交付流程。

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

更有效地实施变更

在做调研的过程中，我获得的最重要的经验是关于活文档（living documentation）的长期收益的——事实上，我认为这是一个最重要信息，本文广泛地涵盖了这部分内容。活文档是系统功能的一个信息源，它与程序代码一样可靠，但更容易使用和理解。活文档帮助团队共同分析变更所带来的影响并讨论潜在的方案。团队还可以为新的需求扩展已有的文档。长此以往，可以使需求说明和实施变更更有效。大多数成功的团队都发现活文档的长期收益是实施实例化需求说明所带来的结果。

总部设在美国西得梅因市的爱荷华州助学贷款流动资产管理公司（Iowa Student Loan Liquidity Corporation，下文简称Iowa Student Loan），在2009年进行了一项相当重要的商业模式变更。过去一年，金融市场动荡使得贷款方几乎无法为私人学生贷款找到资金来源，因此，许多贷款方被迫放弃私人学生贷款市场或改变自己的商业模式。该公司适应了当时的市场。它从银行和其他金融机构募集资金来支助私人助学贷款，而不是使用债券收益。

Tim Andersen是一位软件分析师，同时也是一名开发人员，他说为了有效地适应市场，他们不得不“有声有色地进行系统核心大检修”。在开发软件时，他们的团队把活文档作为一项主要机制来编写业务需求文档。活文档系统让他们可以探悉新需求所带来的影响、帮助他们确定所需的变更，而且可以确保系统的其余部分仍旧正常工作。他们当时只花了一个月时间就对系统实施了根本性的变更并将其发布到了生产环境，活文档系统是做这项变更的根本。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是该项目的方案架构师，他说团队从中受益匪浅：

当时遗留系统中的一部分功能只有少数几个人了解，而现在情况已经好很多了，那是因为团队拥有一套针对那部分功能的、不停增长的测试套件（活文档），它描述了该遗留系统的功能。当专家休假时，还可以从活文档系统中寻找问题的答案。对其他开发人员来说，可以更清晰地了解软件中某部分的功能。并且还是测试过的。

这些例子阐述了活文档系统如何帮助交付团队分享知识并应付人员变动。它还使得业务可以更有效地响应市场变化。我将在第3章里对此做更具体的说明。

更高的产品质量

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

有两个突出的案例，分别来自Wes Williams[来自世博控股（Sabre Holdings）的敏捷教练]以及Andrew Jackman[为法国巴黎银行（BNP Paribas）的一个项目工作的顾问开发人员]，他们将描述之前失败过多次的项目如何通过实例化需求说明走向成功。本文中描述的方法帮助他们的团队克服了业务领域的复杂性，之前这种复杂性是很难处理的。同时还帮助他们确保了交付的高质量。

在世博控股，Wes Williams工作的项目是一个为期两年的航班订票项目，团队分布在全球各地，流程又是数据驱动的，这使得项目十分复杂。项目有3个团队，30名开发人员，分布于两个洲。据Williams说，系统头两次构建都失败了，但是第三次使用实例化需求说明后就成功了。Williams说：

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

Williams认为实例化需求说明是他们取得成功的一个关键因素。除了保证高质量外，实例化需求说明还有助于建立开发人员和测试人员之间的信任。

在法国巴黎银行，Sierra项目是另一个很好的例子，可以展现实例化需求说明如何带来高质量的产品。Sierra是一个债券的数据仓库，整合了一些内部系统、评级机构和其他来自外部的信息，并将它们分发给银行内部的各种系统。许多系统和组织使用相同的术语，表达的意思却不尽相同，这导致了许多误解。最初两次实现系统的尝试都失败了，据Channing Walton说，团队中的一个开发人员促使了第三次尝试的成功。第三次努力的成功部分归功于实例化需求说明帮助团队处理了复杂性问题，并且确保了团队的共识。最终的产品质量令人印象深刻。项目从2005年上线以来一直在运行，Sierra项目的顾问开发人员Andrew Jackman说：“生产环境中没有出现大的问题。”现在Sierra项目中的大多数工作人员都不是项目启动时的那些人，但是质量水平一直都很高。

Bekk咨询公司在为一家大型法国银行支行开发租车系统时也取得了类似的成果。Aslak Hellesøy曾是那个团队的成员，还是Cucumber——一个支持实例化需求说明的热门自动化工具的创造者，据他说，尽管现在维护这个软件的是一个全新的团队，但他们在系统上线后的两年中却只发现了5个缺陷。

Lance Walton曾在一家大型瑞士银行伦敦分行的一个项目中担任过程顾问，这个项目是要开发一个订单管理系统，开始的几次也都失败了。Walton进入这个项目时，大家都认为实现这个系统需要至少和开发团队一样大的支持团队。他的团队使用了实例化需求说明，项目开始9个月后就交付了生产系统，一天内就通过了业务验收测试，之后6个月内没有发现任何缺陷。Walton说新的系统不需要额外的支持人员，成本比预期要低，而且团队更早地交付了成品。相比之下，他们旁边的团队需要10倍于开发团队的支持人员。Walton指出：

现在团队依然每周发布一次，用户总是对它非常满意。从质量上看，它棒极了。

实例化需求说明的技术不仅仅适合于新建项目，同时也适用于改建项目。建立起值得信赖的文档、清理遗留的系统，都需要一定的时间，但是团队很快就能看到诸多的好处，并对新的交付充满信心。

还有一个不错的例子是伦敦摩根大通的外汇交易系统。Martin Jackson是该项目的自动化测试顾问，他说业务分析员预计项目会推迟，然而事实上，项目提前两个星期就交付了。高质量的产品让他们成功地在一个星期内完成了业务验收测试阶段，而不是原先计划的4个星期。Jackson说：

我们部署好系统后，系统工作正常。业务人员向董事会报告说这是他们经历过的最好的用户验收测试（UAT）。

实例化需求说明还使Jackson的团队在项目开发晚期快速实现了“一次重大的技术改动”，提高了计算的精确度。Jackson称：

FitNesse套件（活文档）覆盖的所有功能，通过了完整的系统测试和用户验收测试，在生产环境上线时也没有发现任何缺陷。系统测试时发现了几个核心计算组件以外的错误。业务人员之所以觉得用户验收测试非常好，是因为出现计算错误时，我们都非常确定根本问题是在计算代码的上游。使用了FitNesse后，很容易诊断出缺陷的根源，从而可以更加利落快速地交付到生产环境中。

科罗拉多州丹佛市的惠好公司有个软件开发团队，他们编写并维护一些工程应用和木制框架的计算引擎。在使用实例化需求说明以前，结构工程师通常不会参与到软件开发过程中，即使团队正在处理一些复杂的科学计算公式和规则。这导致了一些质量问题和延误，由于使用这个引擎的应用程序有好几个，计算过程变得更加复杂。项目的软件质量保证主管Pierre Veragen认为发布前的艰难时期会拖累项目，版本发布出去后很少会没问题。

实施实例化需求说明后，团队现在和结构工程师合作制定需求说明，并自动化验证结果。当有变更需求进来时，测试人员和结构工程师一起得出期望的计算结果，并在开发开始前用实例把结果记录在需求说明中。之后批准变更的工程师会编写需求说明和测试。

Veragen说新方法的主要好处是他们在做改动时有信心了。到2010年初，他们的活文档系统中已经有超过30 000个检查，而且几年内都没有发现大的缺陷，现在已经停止追踪缺陷了。Veragen指出：

我们不需要（缺陷数）这个指标了，因为我们知道它不会再回来了……工程师们喜欢测试先行的方式，并且能直接访问自动化测试。

Lance Walton参与过一家大型法国银行伦敦分行的信用风险管理程序的开发。项目刚开始的时候，有外来的顾问帮助团队采用极限编程的实践，但是他们没有采用任何实例化需求说明的做法（虽然极限编程包括客户测试，这个与可执行的需求说明很接近）。6个月后，Walton加入了这个项目，他发现代码质量很低。虽然团队每两个星期都会有交付，但是写出来的代码使验证变得很复杂。开发人员只测试最近实现的功能，随着系统的增长，这样的做法就不够了。“当有版本发布时，大家都紧张地围坐着，想确保所有功能都能正常运行，并且期望可以在几个小时内发现一些问题。”Walton如此说。在实施实例化需求说明后，产品的质量和人员的信心都有了显著的提高。他补充道：

我们十分确信我们发布的版本没有问题。我们高兴地部署完以后就出去享受午餐了，不用再担心是否会出问题。

与此形成鲜明对比的是，英国贸易者传媒（Trader Media）集团的网站重写项目停止使用实例化需求说明后，却遭遇了质量问题。起初团队协作完成需求说明和自动化验证。在管理层的压力下，他们为了更早更快地交付更多的功能而没有继续下去。测试团队的主管Stuart Taylor说：“我们注意到质量出现了大幅下滑……以前我们（测试人员）很难找到缺陷，而后来我们却发现一个用户故事会有四五个缺陷。”

并不局限于敏捷团队

不是只有敏捷团队才可以从协作制定需求说明中获益。在Bridging the Communication Gap一书中，我建议在更为传统的结构过程中应用类似的实践。

英国Sopra集团的高级测试顾问Matthew Steer帮助一个大型电信公司的第三方离岸软件交付伙伴实现了这些实践。他们意识到项目需求定义不明确后，决定作出改变。Steer比较了实施实例化需求说明前后一年的交付成本。不出意料，这些项目使用瀑布方式开发，没能达到零缺陷的级别，但是这些改变“提高了上游缺陷的发现率，减少了下游的返工和成本”。Steer说：

我们在软件生命周期早期发现的很多缺陷，传统上要到晚期才能发现，这足以证明这个方法行之有效。缺陷数在生命周期的晚期有明显的下降，而在早期则有所提升。

最后结果是，交付成本仅在2007年就节省了170万英镑。

减少返工

一般来讲，频繁地发布会促进快速反馈，使得开发团队能够更快地发现错误、修复错误。但是快速迭代并不能避免错误。通常情况下，团队实现一个功能时会有三四次反复。开发人员称，这是因为客户在拿到产品试用前并不知道自己想要什么。我并不这么认为。使用实例化需求说明后，通常团队第一次实现的就是客户所要的，无需返工。这可以节省大量的时间，并使得交付流程更具可预测性、更加可靠。

位于伦敦的英国天空广播公司（British Sky Broadcasting）的天空网络服务（SNS）部门负责宽带和电话的服务配置（provisioning）软件，它的业务流程和系统集成都极为复杂。该部门由6个团队组成，他们使用实例化需求说明已经有好几年了。据他们的资深敏捷Java程序员Rakesh Patel说：“当我们说交付时，确实是能马上交付的。”并且该部门在Sky公司内具有很高的声望。Patel曾和其他公司的团队一起工作了一段短暂的时间，他对两个团队做了比较，他说：

他们（其他公司的程序员）每次在迭代（sprint）快要结束的时候才把软件交给测试人员，测试人员总是发现问题并退回给程序员。而在这里（Sky），我们不会如此反复。如果有错误，我们会编写一个测试，而后在开发过程中使测试变绿——要么通过，要么不过。我们可以当场发现问题。

其他不少团队注意到了返工的大量减少，其中包含LeanDog，它为一家美国大型保险机构开发聚合应用软件。他们的应用软件为很多大型主机和基于Web的服务提供统一的用户界面，而且由于拥有来自全国各地的大量项目干系人，该软件变得更加复杂。最初，在需求方面，该项目遭受了很多功能缺失的问题。Rob Park是LeanDog里帮助团队转型的敏捷教练，他说：

刚开始理清头绪时，我们需要澄清需求，而后我们发现不得不切实做些改变。

该团队实施了实例化需求说明，结果需求说明改善了，返工也减少了。据Park说，虽然当程序员针对某个故事卡开展工作时，有些问题还要向业务分析师咨询，但是“问题已经大为减少，而且重复性工作少了，只剩下不同的问题”。对他来说，实例化需求说明最有价值的方面在于“当着手实现一个故事时，你可以领会它的意图，并了解它的范围。”

很多团队还发现在开发周期的起始阶段，使用实例化需求说明会让需求更加精确，这样管理产品功能清单（product backlog）会更加容易。例如，能够尽早识别太含糊或有太多功能缺失的故事，这样可以防止以后出现问题。如果没有实例化需求说明，团队经常要到迭代中期才发现问题，这会中断流程而且需要耗费时间重新讨论——在大公司，决定功能范围的项目干系人往往无法轻易预约到。

实例化需求说明能帮助团队建立一个协作制定需求的过程，这可以减少迭代中期的问题。此外，实例化需求说明适用于短迭代，并且不需要花费数月的时间来编写冗长的文档。

Ultimate软件公司位于佛罗里达州的韦斯顿，对于它的全球智能管理（Global Talent Management）团队来说，减少返工是一个主要的优点。协作制定需求说明在专注开发工作方面有着显著的影响。据Ultimate软件公司的资深测试开发工程师Scott Berger所述：

在团队认可一个故事之前，与产品负责人一起审核测试场景可以使工作小组（产品负责人、开发人员和测试人员）澄清模棱两可或缺失的需求。有时，会议结果甚至会把故事给撤销了，例如，测试场景会揭露出系统隐藏的复杂性或相互矛盾的需求。有一次，进行这样的讨论之后，大家做出的决定是几乎重新设计整个功能！产品负责人获得了重写和重新分割需求的机会，而不是在开发进行之后，中途停止或取消该故事。通过举行这些会议，我们发现自己的生产力和效率都提高了，因为减少了浪费，而且模糊和需求缺失的程度降到了最低。同时还让团队对预期达成了共识。

大多数团队显著地减少或完全消除了由于误解需求或忽视客户的期望而造成的返工。本文所描述的实践，可以让团队更好地与商业用户打交道，并确保大家对结果达成共识。

作者Gojko Adzic，战略软件交付顾问，专注于敏捷和精益开发，尤其擅长敏捷测试、实例化需求和行为驱动开发。Gojko经常在国际上重要的软件开发和测试会议上发言，并运营着英国的敏捷测试用户小组。最近这十多年来，他一直在财务和能源交易平台、移动定位、电子商务、在线游戏和复杂配置管理系统等行业项目中，从事程序员、架构师、技术指导和顾问等工作。

本文节选自《实例化需求：团队如何交付正确的软件》一书，Gojko Adzic著，张昌贵、张博超 、石永超译，人民邮电出版社出版。