1.1 更有效地实施变更

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

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

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

任何未进行这些测试(活文档)的系统,都必将导致开发停顿和重写。

在加拿大魁北克省的蒙特利尔市,Pyxis技术公司的Talia项目团队也有类似的经验。Talia是企业系统的一个虚拟助理,它是一个拥有复杂规则、能与员工交流的聊天机器人。从最初开始,Talia团队就使用实例化需求说明来构建一个活文档系统。一年之后,他们不得不从头开始编写虚拟代理引擎的核心——而此时,正是在活文档方面的投资大显成效的时候。Talia的产品总监Andre? Brissette是这样说的:

如果没有活文档,任何重大重构都无疑是自寻死路。

他们的活文档系统使得团队在变更完成时可以自信地说,新系统具有和老系统一样的功能。该活文档系统还能帮助Brissette管理并追踪项目的进度。

总部位于伦敦的现场音乐消费性网站Songkick的团队在重新开发网站活动摘要时,使用了一个活文档系统来协助变更。他们意识到目前的摘要系统无法扩展到所需的容量,活文档在重新构建摘要系统时就提供了有力的支持。Phil Cownas是Songkick的CTO,据他估计,因为拥有了活文档系统,他们的团队在实施变更时节省了至少50%的时间。据Cowans所述:

因为我们拥有让人满意的覆盖率,并且我们确实信任这些(在活文档系统里的)测试,所以我们很有信心可以快速地对基础结构进行大的变更。我们知道,系统功能不会改变,即使变了,测试也会发现。

ePlan Services是一个养老金服务机构,位于科罗拉多州的丹佛市,它的开发团队从2003年开始就已经使用了实例化需求说明。他们构建并维护一个金融服务系统,该系统涉及众多的项目干系人、复杂的业务逻辑以及复杂的监管需求。在项目开始三年之后,其中一位经理搬去了印度,而对于系统遗留部分,有些内容是只有他才掌握的。根据ePlan Services的测试人员及Agile Testing: A Practical Guide for Testers and Teams1一书作者Lisa Crispin的描述,当时,团队努力地学习那位经理所拥有的知识并将其构建成活文档。活文档系统帮助他们获得了业务流程的专业知识,并立即提供给所有的团队成员。他们借此消除了知识传递的瓶颈,可以有效地支持并扩展系统。

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

在比利时Oostkamp的IHC集团,病人管理中心项目组实施了一个活文档系统,并取得了类似的结果。该项目开始时重写了一个大型机系统,它是从2000年开始的,目前还在进行中。Pascal Mestdach是该项目的方案架构师,他说团队从中受益匪浅:

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

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

目录