采访和书评：实用的大规模敏捷开发方法

在《实用的大规模敏捷开发方法（A Practical Approach to Large-Scale Agile Development）》一书中，作者Gary Gruver、Mike Young 和Pat Fulghum 讲述了在惠普Laserjet Futuresmart 固件这个大规模软件开发项目中应用敏捷和精益原则的故事。

作者在书中说明了为什么选择了敏捷，当他们决定实现敏捷实践的时候抱有什么样的期望。他们首先关注的是业务需求，这让他们更好地理解敏捷可能带来的好处，并在采用敏捷和精益实践的时候保持关注点。该书还描述了他们如何实现敏捷，选择了哪些实践，未选择哪些实践，以及如何在整个过程中不断调整实践的方式。

这本书描述了大规模敏捷实现，并讲述了实施敏捷的具体细节。从书中我们可以得知，惠普Laserjet Futuresmart 固件采用敏捷的路并不平坦，但很值得。

该书提供了节选下载（第二章）。

InfoQ 的 Ben Linders 采访了《实用的大规模敏捷开发方法》一书的两位作者 Gary Gruver 和 Mike Young。

InfoQ：在书中你们说拥有六大敏捷和精益原则。为什么你们选择这六个原则呢？为什么只选择六个呢？

Gary：我们只是觉得这六个原则在我们的经验中最重要。这种组合来自于我们在精益和敏捷方面的工作经验。

Mike：我们试验了很多，正如 Gary 所说，有些会比另一些更有效，而这些特定的原则最有效（如果对业务没有帮助，就不要做；如果有效，就一直做下去）。所以我们让它们成为组织的底层关注点。我们选取了很少量的关注点，这也符合精益原则。我们开始时实际上只列举了五个，因为只有某些内容在现实世界中生效时，才值得采纳，所以我们添加了第六个，因为它真的是最重要的（实际参与者应该定义敏捷或精益实践）。原则经常最后会变成实践，当那种情况发生的时候，它必须是让工程师或者程序员感到愉快甚至激动的。

选择第一个（减少日常费用或浪费）是因为我们经常抱怨这种情况。我们有太多需要做的，时间永远都不够，所以我们专注于所有会拖延我们而不会让我们接近总体业务目标的事情。

选择第二条原则（不要把我的盘子填的太满）不仅仅是因为这是精益的本质，而且是因为这是最难遵守的一条原则，因此需要大家的关注。总是会有这样不断增长的业务需求，由于经理和工程师总是想要取悦于上层管理层和市场部，所以我们需要特别关注这一点，否则我们会重新陷入困境，最终只能是降低我们的产出和质量（直觉上好像不是这样，但事实的确是这样）。

选择第三条原则（满足瓶颈的需要）是因为我们之前并不是那样。在开始这种转换之前，每个人都是根据为团队贡献多少来度量的，而不是根据他们对总体起到了多大的帮助。我们非常相信 Goldratt 很久之前的经典书籍《目标》，其中他谈到了 Herbie，他是最慢的徒步旅行者，当整个团队满足 Herbie 的需要时，他们会走得更快。那非常有效！

选择第四条原则（尽早、频繁地集成）是因为第六条（实际参与者应该定义敏捷和精益实践）。我们设置了多个看起来不可能的愿景，第一个就是“让开发者的生产力提高十倍”。开发者最大的抱怨就是集成时间太长。所以我们决定解决这个问题。另外，持续集成也是总体敏捷体验的信号。

关注第五条原则（计划节奏），是因为我们需要对更广泛的业务设置正确的期望。之前我们被要求，在介绍产品之前，每年都要对每个产品发布极具信心的一系列完整特性。这样我们就会把所有开发任务停止两周甚至更长时间，把所有人切换到计划模式，然后得到接下来一年间我们要完成的详细设计，然后对其进行切分，并计划相关资源。即便是我们在这个活动中确立了“插队特性”，当我们发现更多工作，有些人跳槽，或者市场部提出最后一分钟的高优先级请求时，我们也会停滞而无法响应。而且因为我们已经提交的内容，日程表会被打乱。所以我们把计划工作颠倒过来，感谢市场部对我们的信任，我们重置了期望——你不会因为计划更多而得到更多。频繁、短的计划周期很关键，它可以让组织专注于交付当前优先级的内容，并让提出需求的人在提交新的输入时敏捷起来。现在我们使用 4 周的计划节奏，这让我们在四周的 Sprint 中，基于上个阶段学到的内容，专注于工作并对其进行排序（这样最大的挑战和业务上最紧急的就是优先级最高的）。

InfoQ：在你开始敏捷旅程的时候，先是调查了“组织吸收变更的能力”。你是怎样做的呢？

Gary：这是一次挑战，而且总是那样。作为组织的领导者，我需要经常明确它能够做什么。接受太多任务，而总是无法完成，这永远都不会让团队感到成功。这真的是一个学习的过程，是我们的微型里程碑目标演进的一部分（编者注：微型里程碑是在惠普用来表示四周敏捷 sprint 的术语）。开始时，我们会在每个微型里程碑过程中接受比我们所能做的更多的任务。在每个月结束时，我们都会评审已经完成的任务，并为下个月设定新的目标。随着时间的推移，我们对组织的能力有了更真实的认识，这使得对任务进行优先级排序更困难。让我们感觉每个月都不错的原因在于，确定真正好的、实际的优先级和目标需要花费一些时间。这些目标不仅仅是对故事的总结。

Mike：在这点上我认同 Gary 的观点。Gary 对于组织什么时候接受了过多任务有很敏锐的感觉。所以，我们会退回到需要的地方。那很有趣。我们对可能会对开发者有提升的“变更”的关注越多，每个人能够并且期望吸收的变更也就越多。这是完整的 WIFM 概念（What’s In It For Me? 我的能量有多大？） 一旦团队了解所处的进度，并了解当达到那里时会有多好，他们总是会要求更多改变。Gary 是我们的梦想家，经常会遵循惠普的创始人（Bill 和 Dave）最喜欢的实践，也就是 MBWA（Managing by Wandering Around，走动管理），走到开发者的工作间里面，发现哪些事情进展顺利，哪些不顺利，并且我们会据此持续调整变更的比率。

InfoQ：书中提到了你们的架构师“会有意识地做出会破坏代码的变更，直到架构正确”。你们的软件开发者对此反应如何？

Gary：开发者会找我抱怨。作为领导者，我需要支持他们，但破坏短期的指标，换来长期的可支持的平台，是非常值得的。这很难，因为当表面上的数字受到影响时，我可能会受到上层组织的批评，但那是要做的正确事情。对于管理技术债务，那是一种有效的方式吗？ 那并不是管理技术债务的唯一方法，但它真的会起到一些帮助。我很高兴地发现，尽管这有时会很痛苦，但架构师还是推动了这件事。

Mike：一旦每个人都看我们认真对待这件事，他们就会做出响应，把架构整合作为每日关注的一部分。

InfoQ：你既试过自顶向下的方式来实现敏捷，也试过自底向上的方式。你最终选择了哪种方式呢？为什么？

Gary：那是一种平衡。领导团队每个月都会把握总体目标，并检查小型（阶段性）的里程碑。同时，我们会检查指标，并和工程师们花费大量的时间来了解什么有效、什么无效。针对要修正什么的大多数好主意都来自于底层（例如，做实际工作的人）。也就是说，领导需要驱动、倾听并基于听到的内容转换关注点。

Mike：我们之前使用的自顶向下的方法失败，是因为感觉是被迫的。我们之前使用的自底向上的方法失败，是因为无法获得推动力或者资金。只有拥有非常关心要将其变成现实的执行负责人和主管（并为其提供资金）时，我们才会做。成功的关键有两方面：从上到下的兴致和责任，以及在第一线的想法来使其成为现实。Gary 提出我们叫做“幻想”的东西（像“如果我们能够在一小时内构建和集成会怎样？”【实际上花费了整整一周】；或者“如果我们每天晚上都跑一遍所有测试”【实际上花了六周】）。他会和组织中的领导分享这些观点，他们会说他疯了，不过几周后他们回来，告知所能做的细节。所有这些愿景都专注于让工程师和开发者的生活更美好，而不是管理层的。那就是成功的关键。就是愿景加动力。

InfoQ：你引入了一种新角色，系统工程师。为什么要引入这个角色，它对于敏捷地工作有什么帮助呢？

Gary：它切实地让我们把计划从一种在特定时间区间内对每个人都会发生的主要瀑布式事件，变成一种不断获取需求不断实现的过程。专注于需求的一群人不需要进行上下文切换，当开发者准备好进行下一个系列工作时，系统工程师就会领导特性启动会议，讲述对业务部门所要求的需求的清晰定义。

Mike：我对此非常热衷，因为我管理系统工程师团队多年。Gary 描述得非常好。在敏捷中，拥有即时的用户故事定义是有效的开发流的关键。另一种比较大的影响是，业务部门中请求大多数用户故事的利益相关者（市场部、客户服务部等）和一个真实的人有很紧密的关系，那样他们就可以信任他，并且知道那边谁会为业务和客户做最正确的事情。以及谁能够有效地建立起业务部门和技术群体之间的桥梁。

InfoQ：你是如何管理美国和印度团队之间的敏捷协作呢？ 哪些手段有效，哪些无效，为什么？

Gary：协作是在管理层级和个人层级来处理的。我们让印度的团队成员成为美国团队的扩展。让他们在美国工作一段时间，从而了解他们的团队。然后把那种工作关系变回电话和邮件的形式。在管理层级，我们每两周就会召开视频会议，期望所有展现的问题都由双方的第一级管理层达成一致意见。如果管理团队不同意或者意见不一致，最大的可能是从彼此的团队中听到了不同的声音。我们努力确保第一级的经理们知道，带着不同的故事“请父母判断”是不可接受的，所以要说出来。

Mike：让美国的团队确信他们的工作没有处于危险之中也很重要。我们之前有过一些情况，美国的开发者们很担心，会“教会徒弟，饿死师傅”。多年过后，随着每个人都意识到，全球化不仅会创造出更多的灵活性，而且让工作和机会依然完整，那就创建出一个强大的团队。Gary 的观点很正确，创造出相互信任的关系非常重要，当工程师和经理能够彼此了解的时候，就会出现令人惊奇的效果。在关键的时刻，你可以日以继夜地工作以完成任务。这样就让人们更清楚地了解到，拥有清晰的优先顺序以及实时的自动化度量非常重要。如果你需要依赖于每日会议，它就会破坏所有人的工作和生活之间的平衡。

InfoQ：“真实世界的敏捷结果”一章描述了我们使用敏捷所达到的一些好处。它提到研究和开发与开发者生产力都得到了提升。可否请你详细阐述一下？

Gary：我们的关注点是要驱动开发者的生产力。你可以用我们在本书中展现的多种方式对其进行度量。另一点值得注意的是，当人们从那种开发环境转到更加传统化的软件开发组的时候，会发生什么。我曾经指导过多位员工，他们最终离开 FutureSmart Firmware 到其他组或者公司，他们的反应非常类似。没有大规模自动化测试和带有持续集成的过程（像自动回退），他们不知道如何工作了。他们感觉缺少保护措施，所以努力达到和之前在这个环境中一样的生产方式。

Mike：有生产力的开发者都是快乐的开发者。当他们感觉对生产力的关心正驱动了业务决定，会感觉得到支持，并会更有积极性。

InfoQ：如果公司想要变得更敏捷，要迈出的第一步是什么呢？

Gary：从一位敏捷作者来说这听起来有些滑稽，但是我推荐的第一件事是永远不要为敏捷转型制定计划。这是必败之仗。组织中总是会有人说，他们读过一些书，里面说想要敏捷，就意味着你要做什么什么事。对于“什么什么事”有太多可能，你永远都不会完成，从而永远都不会成功实施敏捷。尽管如此，在敏捷工具箱中有很多不错的工具，你可以用来帮助转换你的业务。

第一步是确保你清晰地理解了你的业务目标和价值定位。我也经常看到一些追求敏捷的人，努力为业务主管编写收益的文档。你应该首先确立清晰的价值定位，那样就不会对如何度量价值有任何疑问。

接下来的步骤是基本的基于活动的会计手段，评估你当前是如何使用资源的。然后你知道你想要做什么，在系统中什么地方造成了浪费。那时，你可以首先查看敏捷工具箱，看在哪里能够让你的资金获得最大回报。从个人角度，我几乎总是从自动化测试和持续集成过程开始。如果你还没有那些过程，我不知道你如何满足“完成”的定义，而那对于所有敏捷工作来说都很重要。

Mike：业务常犯的另一个严重错误（除了“为了敏捷而敏捷”之外）是想一口吃个胖子。建立一个实际、按优先级排序、能够在 4 周的 sprint 中完成的目标是关键所在。在我们的敏捷世界中什么都不存在，除了完成当前的四周 sprint，以及为下一个 sprint 做粗略的计划。如果你在 Sprint 专注于正确的事情（最后会获得能够工作的演示程序），那么你就向业务展示出，你真的可以交付所需要的内容，并且你开始理解作为组织你所能够交付的内容。

关于书的作者

Gary Gruver之前曾担任 HP’s LaserJet Core Firmware Lab 的主任工程师，他在 HP 工作了 22 年。他当前是 macys.com 的副总裁，负责发布、质量保证和运维。Gary 擅长“管理到指标”的方法，把所有人团结到一般的可度量的目标周围，而不需要大量会议和协作的负担。当然，他最重要的角色是在特别忙的 sprint 期间，为所有在周末加班来完成关键特性的人购买午餐。它最大的爱好是和家人一起骑自行车和滑雪（他已经结婚，并有两个女儿）。

Mike Young是一位高级程序经理，指导多个分布式团队的每日工作。Mike 已经参与了 HP LaserJet Printers 的开发 17 年，之前曾为 Hughes Aircraft Company 设计了卫星控制系统。他还是敏捷方法的最积极提倡者之一，在没有人真正意识到是在做敏捷之前，帮助组织实施这种方法。他的爱好就是和家人（他已经结婚，有两个女儿和两个儿子）一起打壁球。在敏捷领域，我们发现程序经理应该花费大多数时间观察度量数据，并在背后悄悄协调，以满足瓶颈的需要。在我们的 spint 检查点时，我们希望让幻灯片最少，让解决问题和新用户故事的演示最多。

《实用的大规模敏捷开发方法：HP 如何对 LaserJet FutureSmart Firmware 转型》，Gary Gruver、Mike Young 和 Pat Fulghum 著，Pearson/Addison-Wesley Professional, 2012 年 11 月出版，ISBN 0321821726, Copyright 2013 Pearson Education, Inc. 想要获得更多信息，请访问出版商的网站。

查看英文原文： Interview and Book Review: A practical approach to large-scale Agile development