实战大规模敏捷

关键点

• 大规模敏捷需要尊重所有参与者，也需要成员间互相尊重。
• 大规模敏捷需要根据团队成员与手头项目的情况来调整执行方式。形式服从功能。
• 大规模敏捷需要对数据与团队成员的输入做出积极响应。
• 大规模敏捷需要在所有层级中开展行动导向的会议。这些行动包括移除特定任务的障碍与人际交流中的障碍。
• 大规模敏捷需要深层次的合作、交流与承担责任的文化氛围。

敏捷团队只是企业敏捷开发和测试环境的要素之一。当企业需要更高水平的开发和测试能力或应对更大的项目时，可以在企业层面将各自独立的敏捷团队整合到同一敏捷环境中。

人们认为，把几个敏捷团队放在一起根本不可能共同去实施一个项目，但这并非事实。在团队层面敏捷能够优化队伍、提升效率以产出更多价值和更好的成果；类似地，企业规模的敏捷开发能够在项目层面获得相同的效果。这也就是采用大规模敏捷的最大原因。

通过大规模敏捷，各个团队可以共同集中资源、安排优先事项，共同为整个项目承担责任，而不是只关注自己的团队或特定的任务。然而要做到这一点实非易事。从职场文化上来看，这就像是要求财务部门为了公司的高级目标而自愿退居市场部门身后一样。不仅如此，财务部门还得向市场部门贡献自己的时间与专业技能来帮助后者创造绩效！财务报表先放着，必须先把产品宣传册搞出来！呵呵……

我们曾同一家在线礼品市场的领军级电商企业（年营收 5 亿美元）合作。他们成功实现了大规模敏捷，过程中也遇到了人们能想到的各种障碍，并进行了相应的调整。这家客户并没有循规蹈矩，而是在实践大规模敏捷的过程中寻找适合自身的方案与最佳实践，选择了行之有效的路线并一路随时修正方向。与他们合作并见证他们克服挑战的过程开拓了我们的视野。我们明白了哪些东西是有用的，哪些是不切实际的，及怎样做才能成功实现目标。

迁移到大规模敏捷环境

这家电商企业有 6 个敏捷团队，他们各自独立运作，但都在为同一个项目提供支持。这个项目包含多个功能驱动型团队（如登录、结账、礼品选项、消息、交付、支付、账单和评价），这些团队的工作彼此交错，服务对象则是一些相互关联的线上品牌。各个团队皆为敏捷团队，习惯了沟通、合作与责任分担。但要把这种合作氛围扩展到他们熟悉的领域之外却是团队未曾接触的理念。从敏捷到大规模敏捷的区别，就像是从国家内部的省份间合作到国与国之间的国际合作一样。
总体上，大规模敏捷需要更高层次的思维、包容与耐心。

但相比大规模敏捷遭遇的挑战，放弃它带来的成本似乎更高。因为这些团队之间没有实现敏捷，随之而来的沟通障碍与效率低下的团队合作让敏捷环境的许多优势丧失殆尽。从头至尾，整个项目沦落到几乎没能实现和交付一项明确的功能。客户希望通过企业层面的大规模敏捷让整个项目得到广泛认可。

这家公司将 6 个包括 3 至 10 人的独立队伍整合为一个团队。主要的方式是为整个项目设置具有明确指标的短期迭代；并根据迭代、技能差异、团队依赖来灵活安排团队成员贡献他们各自的技能。他们没有特意去塑造某种大规模敏捷的形式，而是以循序渐进的方式来调整团队和安排会议，根据团队反馈与数据分析结果来逐步前进。

与此同时，各个团队依旧保有自己的每日站会（daily standup），有自己的 scrum master 和技术领导。大规模敏捷的目的并不是淘汰独立团队的形式，而是让各个团队能够为同一个项目协作努力。

从开始阶段到项目过程中，这家电商企业部署了一些工具，应用了一些实践方法以实现大规模敏捷：

单一的任务列表：一开始 6 个团队都有自己的任务列表。开始大规模敏捷后他们就把所有团队的列表合而为一。大家需要像在自己团队内部那样来安排优先事项，但因为涉及到多个子团队，他们要设法让优先事项、关联事项都对彼此透明。单一的任务列表解决了这个问题。现在大家依照同一份任务列表实施敏捷行动，由此引出了产品委员会。

产品委员会：产品委员会基于战略层面运作，每天召开一小时的会议。通过专注于以下领域，委员会在所有团队间维持敏捷文化氛围：

• 最高优先事项

• 当前的迭代（sprint）活动

• 未计划事项

• 需要在项目层级和跨团队层面做出的决策

• 为下一次迭代所做的准备，包括两种情况：

  • 某个团队需要其他团队的协作来完成下一次迭代。例如 A 团队要完成迭代 15 中的任务需要一些 B 团队在迭代 14 中的成果。
  • 在团队之间重新分配资源：根据之后迭代的情况，团队可能需要一些自身当前不具备的技能。这时就需要考虑在必要时，将各团队或团队成员集中起来以完成最优先事项。

产品委员会的最重要角色是引入与增进文化氛围的变迁，这种有些戏剧化的改变就是从部门或团队级的敏捷升格为项目层级的敏捷。结果当然可能出现某种状况：例如完成项目的最优路线中，A 部门的需求需要让位于 B 部门，甚至在必要时为后者贡献时间与技能。所有利益方都必须意识到这一点并支持这种做法。

Scrum of scrums：如同产品委员会从战略层面制定单一的任务列表一样，各团队的 scrum master 也需要有机联合为同一个 scrum master 服务。由此引出所谓“scrum of scrums”。在大规模敏捷环境中代表各个团队的 scrum master 组成一个小组。小组在战术层面运作，专注于执行。小组每两天碰一次头，讨论各项预期、需要克服的障碍和任何团队内部或团队之间的各种问题。

引入“产品委员会”和“scrum of scrums”时，公司遭遇了团队成员的一些质疑。很多团队成员想到的是官僚作风，所谓“委员会的决定”之类。事实上，如果成员不能全心参与到这些会议，不把它们当作一种通向开放和无私分享的途径，不去共同探讨优先事项、技能组合、面临的障碍和机遇，这些委员会也就形同虚设。大规模敏捷要起效靠的是将好的商业实践应用到项目中，重要的是实际行动而非纸上谈兵。

这家客户为平息对产品委员会和 scrum of scrums 的质疑而采取的一项重要的附加手段，不是减少会议频率，而是开更多的会！召开这些额外的临时会议的目的是为了消除个体层面的怀疑。这么做是为了强调一个观点，这家客户实施大规模敏捷实质是优先看重人力资源，且项目的成功取决于此。因此企业的行动需要增强这种优先级，不仅体现在管理层面，更要体现在所有层级的每一位团队成员。由此发起了两类会议：“精益咖啡会议”（lean coffee session）和“敏捷咖啡会议”（agile coffee session）。这些会议为所有团队的成员提供了非正式的途径来讨论各种话题，包括技术上或人际关系方面的事项、担忧和建议。这些会议有助于有机扩散大规模敏捷的文化，这种扩散并非从上至下，而是相反。

敏捷教练（稍后进一步讨论）在转变团队成员对会议的看法上扮演了关键角色，这些会议不只是理论争辩和观点分享，更多的是作出决策和即时行动。与会成员发现这些会议导向了实时行动和开放交流后，他们就乐于参与其中了。

主动汇报：很多团队成员习惯于将数据收集当作被动的汇报工具，与他们的日常工作无甚关联。但在大规模敏捷环境下，只有实时应用收集到的团队数据才会有效促进项目进展。由此引入了主动汇报。类似地，敏捷教练会帮助团队成员将数据视为主动而非被动的工具。

大规模敏捷需要同时在宏观和微观层面收集数据，并进行数据分析和实时响应。这家企业的案例里，统计信息和数据来自整个项目和所有为项目提供支持的团队。这些数据包括如下内容：

• 故事分数（story point）的完成数量（即 Velocity）
• 按照原因对积压的用户故事（user story）进行分类（例如“被阻塞的”）
• 团队之间的依赖
• 根据以往的迭代执行效率来预测项目的完成情况

这一层级的汇报需要一些企业级的工具，这些工具用来在项目、团队和成员层级收集数据。这家公司之前就使用 TFS 进行代码与 bug 追踪，结果他们发现拿它用于项目层级的报告也挺容易。重点在于这套工具需要应用到所有层级，用在所有种类的报告与回顾上，不能拿 Excel 工作簿或者 Word 文档来应付了事。

在项目、团队与迭代层级的回顾阶段会进行数据分析。根据分析结果采取的行动包括合并、拆分团队和调动团队成员。精益咖啡会议和敏捷咖啡会议有助于让这些转变更加平滑自然。

敏捷教练：这家公司请到了外部的敏捷教练，不过根据不同案例中技能组的情况，外部和内部人员都可以充任这一角色。本案例中，请到的敏捷教练引入并激励了企业的敏捷文化，鼓励并促成了团队的表现，并引导团队学会与内部、外部的团队、管理者与其他利益方进行协作。在团队成员改变固有思维和接受新理念的过程中敏捷教练起到了关键的作用。

大规模敏捷过程中不该出现的问题

为了让 6 个敏捷团队有效协作，这家领军级电商必须解决一些遗留问题：

未能将人员置于比项目更高的优先地位：在这家客户成功实施大规模敏捷的过程中，由项目至上的文化转变成人员至上的文化是核心要素。如果没有这种核心的转变，公司不可能得到团队与部门内部必要的信任和尊重，自然也就无法有效完成任务和迭代。咖啡会议就是用来促成这一变化的。所有层级的担忧都应该得到听取和重视，这样所有人才会愿意去信任上层体系。

未能有效处理数据：大规模敏捷中的主动汇报与回顾能反映出问题所在，乃至揭示处理它们的方法。通过研究数据，公司发现往往问题的根源和解决方案的瓶颈恰恰来自于抱怨这些问题最多的人身上！正是经过分析的数据证明了这一点。

未能使用可扩展规模的工具：公司里有的敏捷团队想用 Excel 工作簿来实施大规模敏捷。对于这种情况来说
工具就成了瓶颈。让所有团队都迁移到 TFS 环境是至关重要的。

未能实现协调一致与透明化：有些项目参与者觉得开会是浪费时间，不管会议是开发层级、scrum master 层级还是利益关系方层级。他们认定会议上大家不会开诚布公，开会也不会直接引发行动。因此，委员会与 scrum of scrums 在透明原则下作出的努力与进展，成为了提升项目参与度的不可或缺的要素。

未能给团队成员设置敏捷成果的考核标准。实现大规模敏捷是体系与人员的职责，最终的成功需要两者共同努力。这家公司发现他们需要提供、选择、参与、撤出和调动各种资源来激发团队活力。公司对内部与外部利益方定下了考核标准，如果团队成员不能提供所需的技能，缺乏应有的态度，他或她就是项目成功的阻碍，会被立即调到其他项目中。公司会主动拒绝或调动这些人员：

• 一门心思只想着在自己擅长领域干活表现，对其他事情不管不顾的成员
• 对适应持续变化的环境不感兴趣的成员
• 不想与同事持续沟通，获取信息和反馈结果影响了项目总体效率的成员

成功之路

企业级大规模敏捷事关交付与控制。这家公司的成果正是交付与控制的结果：

• 在规模化初期，开始的两个迭代用来建设团队、组建工具、设置产品列表。第四个迭代开始交付。第六个迭代起团队开始持续交付。Velocity 数据能够了解和预测各个团队何时交付自己负责的功能。
• 大规模敏捷开始之前几乎没有明确的功能得以实现和接受。随着大规模敏捷开始实施，积压的用户故事比例从 80% 降到了 50%，直至最终下降到了稳定、可接受的 10% 以下。

数字摆在这里，而与这些数字同样重要的是一种协作、信任和充满信心的文化；这种文化是实现这些数据所反映成果的关键因素，并最终成就了一个规模更大、更加忠诚敬业的队伍。平台根据团队成员的特质与项目情况进行调整，使得雇员能够亲身体会大规模敏捷的成果。这家客户不仅成功完成了项目，更是形成了能够实现更多类似成就的企业文化。

作者介绍

Yousef Awad是 Integrant 的 CEO，他在开发、数据库管理和项目管理方面有着亮眼的从业经历。Integrant 有超过 130 位员工，提供定制的.NET 软件开发服务和测试团队，帮助 IT 部门掌控项目，有效扩展内部团队。除了 Integrant 的事业之外，Yousef 还热心于让儿童和青年体会编程的力量。Yousef 正在努力为低龄儿童开设代码课程，为他们提供手把手的指导。他欢迎相关的探讨，可以通过 info@integrant.com 与他联络。

查看英文原文： Agile Scaling in Action

感谢薛命灯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。