苏格兰皇家银行的LeSS实践

如何扩展Scrum以满足大型组织的需求？

我是在有机会带领实现一个供应商平台时面临这个问题的，该平台拥有广泛的能力来更好地帮助我们服务并取悦我们的客户。

我想要采用Scrum，部分是因为它提供了客户焦点并能帮助更有效率地实现这个平台，从而将符合我们客户和用户的最大利益。

我还需要考虑的其他问题：

• 该产品需要支持新兴和现有的OTC衍生品和抵押品管理法规要求。如果我们不能经常且有把握地发布更新，那么交付将被视为失败。
• 我们需要位于不同地点的多个Scrum团队才能交付产品。
• 我们需要理解如何处理我们不直接使用，但属于供应商软件包-因此可能有间接依赖-的所有功能。
• 我们处于一个不断发展的组织中，需要应对持续的变化，并必须将客户和用户放在第一位。

与此同时：

• 供应商平台的定制化或扩展部分的代码质量，是保持低变更成本的关键。
• 我们有一些出色的人事经理，他们也将参与其中，带他们走上这一旅程可能会证明有好处。

从Scrum开始

组织内有众多团队专注于产品交付敏捷性，我（通过内部Scrum工作组）与他们交谈了他们所面临的挑战，以及他们认为为了跨团队和跨团队工作，Scrum框架应怎样“妥协”。显而易见的是，我需要勇气，一些优秀的团队，高级管理层的支持以及与一种前所未有的扩展方式。

我阅读了提供了有用见解的《分布式Scrum指南》（Distributed Scrum Primer），然后读了LeSS书籍，《精益和敏捷开发大型应用指南》和《精益和敏捷开发大型应用实战》。 很快，我就意识到有一个框架,可以涵盖很多的我所知道对于大规模Scrum交付所必需，并且它很可能满足我们的需求，即LeSS。

组织架构

我们导入LeSS的路线是循序渐进的，运用了一些基于其他团队的事实和趣闻的系统思考。 我们知道必须翻过、而且得翻好的第一个障碍是组织结构。

苏格兰皇家银行（RBS）是一家跨国公司，此次交付需要两大洲的三个不同城市合作。每个大洲都有各自特定的技能组，英国主要具有分析、项目管理、基础设施和后台运营技能。印度主要具有软件开发、测试和发布技能。

交付团队实际上的传统架构“应该”是这样的：

• 1名项目经理负责命令和控制：
• 业务分析师编写需求文档并将其移交给。。。
• 位于其他地点的技术业务分析师帮助翻译从业务分析师（BA）移交过来的需求文档，以便。。。
• 位于两个地点的开发都可以解读要求做什么，并交付组件。。。
• 然后，内部测试组织的一组测试人员将进行测试，以确保这些组件结合在一起成为特性，并且这些特性满足他们对用户和其他干系人需求的解读。

实际上的架构看起来像这样：

好吧，我知道这不是一个好主意。我们看过这部”电影”太多次了，它不漂亮，很少有一个幸福的结局。

因此，我知道架构不应该是这样的，并且有了一个由多技能成员组成真正跨职能Scrum特性团队的愿景，但是必须要说服大家。最早的主要争论之一是。。。

组件团队还是特性团队？

我们不打算在短期内转变为完全成熟的特性团队。为什么？因为要完成真正的以客户为中心的端到端特性

• 对组织中其他团队和组件的依赖数量很多
• 他们对改变成提交到共享代码（或“内部开源模式”）的方式-即我们打算在该平台上采用的方式-的意愿度未知
• 在给定时间段内能够发起这一变革的人数使得很难一步到位。于是剩下的问题就成了，我们能走多远？

公共组件组架构

我们的平台打算在将来被其他业务功能使用，因此我们必须尽一切努力确保可以共享的任何组件或特性都具有良好的质量（健壮性、可扩展、设计良好），并且容易理解。

我接触到创建一个公共组件临时组的概念，该临时组将由特性团队的轮换成员组成，并由一个非轮换的长期“组件导师”（管家）领导。

这将使系统的公共组件可以被多个特性团队的一些成员交付和理解。一旦轮换时间到了，他们便会返回他们的特性团队，并尽力将新知识带给团队。这是我们所设想的架构：

围绕组件来创建团队的弊端已有很多记录，尽管组织中的一些人认为这是一个值得尝试的实验，当澄清了该模型中包含的浪费、风险或无效，大家都认同围绕组件来创建团队将使我们走上错误的道路。我们决定不尝试公共组件临时组的做法。

新组的初始架构

通过以团队作为组织的建造单元、最大程度地减少浪费并意识到前述要点，我们创建的架构如下：

滚石不生苔-让我们来点动力

我们现在处于特性团队正在形成战斗力的阶段，通过多团队参加的设计工作坊来设计共享组件和特性已成为常态，并提升了有效性。

多团队设计工作坊和产品待办列表梳理

我们注意到的一种模式是，多团队设计工作坊越少，产品待办事列表梳理时间就越长，因为我们总是在应该为接下来的Sprint澄清产品待办列表里的“需求”时却进行着设计。

我们努力使参与整体待办列表梳理的团队代表们保持均衡。其中主要原因之一是因为选择了视频会议（万恶相权之轻者，译者注：指综合考虑各种因素下权衡考虑，比如跨洲等），视频会议让白板想法、实例、建模（以及更重要的在建模过程中进行的对话）变得困难。

Sprint评审会

Sprint评审会的最大挑战是怎样使它们简短且关注于特性（feature）。自从安排了一个配备有每天中一半时间可用的专用视频会议功能的团队会议室，我们就总是用它来做Sprint评审。评审将是每个团队轮流来为他们“已完成”的工作寻求反馈。我们团队有一大部分组员还在边交付边学习供应商系统和业务领域，由此很多我们的Sprint评审会不幸变成了团队分享他们所做工作的机会，并且太过关注于技术。

所以我们做了什么？

• 有一段时间我们在Sprint评审会开始之前预留时间让团队互相分享他们的工作。
  • 这给了团队们一个机会来提供反馈并学习整组共同交付的特性。
• 我们竭尽全力让主题专家（被替换的平台的前用户）100％分配来帮助整个组。
  • 这提供了很大的帮助，在许多有关业务领域和运营环境的细微差别上给予了团队专家反馈。
• 我们采取的最有效的一项措施是进行系统建模活动，作为整体回顾会的一部分。
  • 通过建模、对话和讨论的过程，在着手研究“如何在Sprint评审会上保持对特性的关注”这一问题描述时，每个人都能理解了有许多变量在起作用，以及为何没有唯一的根因（某些人最初会这样认为）。

各团队自己的回顾会

我们发现各个团队自己的回顾可以像单团队Scrum那样进行。

我们想在这方面做些实验，所以我们尝试了：

一个单团队回顾会和一个多团队回顾会

一个多团队回顾会 - 所有团队都使用视频会议加入了位于同一地点的团队。

这些实验很有帮助，它们帮助我们理解，回顾会在对团队有针对性时是最有价值的，并且我们分享那些对整个产品交付相关的点，在。。。

整体回顾会

整体回顾是LeSS里提供为数不多的单团队Scrum扩展至多团队应用之一，也是我们从中学到最多的事件之一。此事件的价值是不可否认的，通过团队成员、产品负责人和支持团队的经理的参与（而不是只限于ScrumMaster们，有些人会容易想成这样安排），才能对实验中的成功与失败形成真正的共识。

在我看来，这一事件对于真正长期的成功至关重要，因此，我们将继续努力以从中获取最大的学习收获。我发现对我的学习最简单的总结有以下几点：

• 避免过于程序化。引导一个任何类型（团队或整体）的良好回顾（并使其保持新鲜感和活力）都是个挑战。我们发现，这很容易变成状态汇报，很容易花费大量时间来比较每个团队回顾的总结却收效甚微。当我们本来可以。。。
• 使用诸如因果回路图（系统模型）之类的建模技术来促进对话和更好理解大家对整个产品开发系统的看法（但要记住，模型永远不会反映真相，系统的唯一正确模型是系统本身）。
• 团队间的紧张情绪有时会上升。在进入回顾会时假设每个团队成员都已尽最大努力这个观念在有众多团队的时候容易被遗忘。整体回顾会可以是发现和强调这些紧张关系的机会，令人欣慰的是，对Scrum的精通和引导技能推动我们渡过了这些波涛汹涌的水域。

Sprint计划会一和二

在以前单团队Scrum时，Sprint计划会非常直接。我们只进行一次Sprint计划会议，不需要区分Sprint计划一（设定方向、澄清故事中的谁/什么/为什么）以及Sprint计划二（怎么做和做设计）。当你开始扩展规模时，很明显，在为团队提供下一些要交付的产品待办条目时，产品负责人（无论是临时性“伪”产品负责人还是其他的）必须保持高效。

LeSS重申了Spint计划会议一和二的区别，这样做有助于让我们记住，产品负责人应通过排优先级来设定方向，这是产品负责人的核心职责。 我们有多个团队共享一个产品负责人，最初（没有遵循LeSS指导）是不将Sprint计划分为两个部分的，这导致了产品负责人过于注重细节，因此减少了团队间的协作和提问。这样最终会削弱团队的学习能力，并减慢了与成功或失败的最终决定者 - 客户和用户 - 建立关系。

每日站会

尽我们所能，让各团队的Scrum站会一个接一个进行，但我们从来没能对上过时间，这让我觉得这么做不是一个太理想的方式。那么我们尝试了什么呢？

• 全部在电话会议上
  • 经常有人在家远程工作，或者来自其他地点的另一个团队的成员想要加入。为了保持在同一环境，我们想试着让所有人都参加电话会议（而不是某几个）。有一种感觉，这不是进行Scrum每日站会的最佳方式，但我们想用证据来证明这种感觉是对的。没法看见对方、没有在同一焦点（物理板）上、如果通过办公桌上的电话接入注意力被分散的几率也会增加，从而导致大家干自己的事和同步不高效，不用说，这样的方式并没持续很长时间。

• 通过视频会议进行每个团队“Scrum of Scrums”的每日站会，即每个团队的一名代表参加其他团队的每日站会，分享他所在团队的事情。
  • 我们可能没有尝试这种方式足够长时间，但是通过让每个人都在VC会议室中围绕着电子板，似乎使每日站会变得更像是个会议（部分原因是我们无意识中把人和家具与更传统的会议关联起来）。有面对面的交流非常好，如果能把物理板推进房间会有所帮助，但是环境不允许，这让我们找到了最适合我们的方法。

• 一个团队围绕在他们的Scrum板，并通过VoIP连接其他团队代表的无线耳机（可能他们站在自己的物理板旁边）。
  • 这使团队能够感受到他们信息传播的热量，并在他们自己以及与其他团队之间分享有用的信息。围绕着物理板站着让事情朝着正确的方向走，而让其他代表通过电话接入给了他们一种在墙上“飞”的感觉。代表们分享信息时保持站立使这种感觉持续着，这样创造了简洁高效的会议。

没有尝试过的是：

• 各团队独自站会（没有其他团队的代表参加）
  • 原因：各团队之间没有同步，这会使信息只是以拉动的方式传播，甚至更糟的是会使人们通过工具而不是口头的方式进行交流（时间过得很快，如果错过了跨时区中不多的重叠工作时间，通常会导致以文字交流）

产品待办列表梳理

在我看来，LeSS带来的对Scrum的最好扩展是明确把产品待办列表梳理（PBR）定义成一个事件，并添加了整体PBR（可选）和多团队PBR的结构。我们一直以来都尝试一个PBR，所有团队的所有人和临时伪产品负责人共同参加。对于我们的临时伪产品负责人而言，只有一个PBR让他进入到比他本应该达到的更细节的程度（对于规模化的产品负责来说这样的情况并不好或）；同时对于团队而言，只有一个PBR的话一次腾出这么多时间太难了。

LeSS建议的有一个较短的整体PBR可以实现：

• 产品方向得以传达，并提出为此所需要梳理的产品待办条目
• 一起来拆分大的条目，必要时可以进行轻量的分析
• 整体评估的能力，从而帮助我们保持相对的故事点数在各个团队中有相同的含义（又称为“故事点”校准，例如，帮助确保在一个团队的8个故事点不会是另一个团队的3个故事点，我们使用一个“故事点”矩阵来协助实现）。

对我们而言，这意味着大家一起30-45分钟先做整体PBR，然后与用户和主题专家一起做几个单团队PBR或者一些多团队PBR，由各团队自行决定安排。这样就能并行地进行梳理，而且可以把“临时伪产品负责人”释放出来去关注定义下一个产品增量交付的方向。

每个团队一开始都很紧张，担心能否与用户进行有效的互动，以及在临时伪产品负责人无法参加所有PBR的情况下（译者注：因多团队PBR并行），他们讨论、更新和记录产品待办列表条目的速度就会降低。对我而言，道理很清楚，我们的用户是成功或失败的最终仲裁者，没有临时伪产品负责人的影响和指导也许事情可能会在这里或那里变慢，但我们有信心，我们是在朝正确的方向前进，而不是虽然快一点但更有可能朝错误的方向（当人们的意愿受到影响或通过信息源以外的其他人传递时就有这种风险）。

临时伪产品负责人

在接触LeSS框架之前，我们根本没听说过临时伪产品负责人这个角色，但经过解释后却完全合理。在我们开始一起工作的时候，前几个Sprint并不是最棒的，因为对供应商平台的相对经验不足，我们学习了很多；每个新团队也都在学习如何合作。这个时候如果有真正的产品负责人可能会让大家害怕！

我们有个人能沟通传达方向（通过与发起者建立关系并从他那里了解方向），但此人不是真正的决定者，也不是真正的“产品所有者”，为了明确这些，我们采用了LeSS指南中的临时伪产品负责人。他们是临时的，因为想法是尽快将他们替换为产品的真正所有者来作为产品负责人。当然，他们是伪的，因为他们无法决定业务和产品的方向，他们只是传达他人决策的中间人，而不是产品负责人那样强有力而且独立的产品拥有者。

为什么发起者不是产品负责人，就像人们在Scrum中所期望的那样？众所周知，我们的组织在过去几年中经历了一些动荡的时期，而这导致了绝无仅有的改变-这种改变需要我们的高级领导层（包括发起者）专注于遗留事务和新的挑战。对我们来说，这意味着我们的发起者无法投入时间来承担产品负责人的角色。

被足够授权的那位临时伪产品负责人具有丰富的供应商平台交付经验、并与发起人和团队保持良好的关系。这使他能够承担真正产品负责人的一些责任，比如设定优先级、对交付的产品待办条目进行验收（在此之前，需要用户和主题专家先通过或拒绝）。他的背景和在组织中的经验让他做得不错，包括在团队、用户、主题专家和利益相关者之间建立和维护关系。他的正式职衔。。。代理产品负责人。

教练型经理 - 能力建设者

我们坚信需要提高员工的技能，重要的是，我们的经理必须能够专注于提高团队的能力，具有专业的理解力，并且愿意去现场观察（go see）团队正在做的工作。如果我们的经理们不去工作完成的地方现场观察，也不了解大家所面临的障碍，那么他们对于我们产品的价值就很小。我们最初有一个人来担任15人的直线经理，但他发现很难与团队每个人建立个人关系、以及通过教练和辅导帮助他们个人和职业发展。

鉴于此，现在每个特性团队都有一位直线经理，但是尽可能让直线经理在其负责特性团队外（也就是说，很少有人与他们的直线经理在同一个特性团队内）。这些直线经理的职责是在组内教练和辅导从而构建能力，同时与原始经理一起工作以了解和优化整体。

接下来呢？

我们认为基础已经到位，于是深入研究了LeSS框架，并列出要做工作的清单：

• 确保客户是我们正在做的事情的核心
• 测试驱动开发（TDD）和验收测试驱动开发（A-TDD）可帮助减少待验证工作的排队和交接，提高代码质量，提高需求质量，提供早期反馈并使我们能够更快地行动。
• 推动持续集成并拥有持续交付的完美愿景
• 设计一种方法让我们有尽可能和生产环境一样的环境，以便尽快部署并进行测试。
• 创建合适层次的透明度，目标是让中级和高级管理层能基于拉动获取进度、用户反馈和阻碍等信息。

总是先测试，经常使用实例

“宁可更好地培训他们，冒着他们离开的风险；而不是没有培训，让他们留下来。”

在此过程的早期，我找到了一位出色的跨职能交付经理来担任Scrum Master。 我们着眼于了解如何为供应商平台实现自动验收测试，我们得知该平台最适合以屏幕抓取的方式做自动测试。

我们选择了Fitnesse，一款基于Wiki的以FIT（译者注：FIT为集成测试框架）为基础的自动测试工具。我们发现，通过在Fitnesse和供应商应用程序之间创建一些“胶水”，我们能够使大量功能和非功能测试自动化。测试的创建和执行立即成为我们“完成的定义”的一部分，在我们知道这些概念之前我们其实已经在推广A-TDD和“实例化需求”了。

举个例子：我们的销售团队一直在与潜在客户进行交流，他们问我们是否可以通过多种不同方式拆分每日现金付款。当被问到团队中谁来“写需求”时，我说没有一个人来干这个：相反，我们要做的是让几个团队成员与你坐下并通过例子了解哪些配置是最可能的，这样我们能交付销售团队所需要的，并避免任何不必要的浪费（例如，极不可能或永远不会发生的极端情况）。

在一周的时间内，团队有了8个实例化的场景，并且排好了优先级准备下个Sprint做。这些实例直接被放进Fitnesse，我们先看到它们失败了，从而为成功设定了标准。到Sprint结束时，我们交付了他们所需要的，潜在客户被告知我们团队可以做到，并且我们团队的代码潜在可交付并至少在每次构建过程中都经过测试。

上线障碍

要上线，我们必须满足许多约束条件（例如灾备恢复、标准化的用户角色和权限报告等）。在上线之前，我们应该有一套尽可能和生产环境一样的类生产环境，以便每个功能都可以部署到那里并由用户进行尝试。

我们决定进行实验； 除了一个团队外，所有团队都将继续交付用户功能，而那一个团队将致力于构建所需的目标部署基础设施（尽可能贴近最终线上的实际需要）。

我们发现我们能够在四个为期两周的Sprint中实现大部分所需的基础设施。我们还发现，现在我们有了一支团队清楚基础架构剩余要做的工作。实验成功了吗？反思一下，我们应该付出更多的努力来定义成功意味着什么：

• 多少基础设施才足够？
  • 我们本可以通过保持原有团队并在此期间指导他们的方式来提供所需的大多数基础设施。这将导致有更多的人贴近这项工作，有更好的对基础设施的共享理解甚至可能更好的解决方案。
• 实际使用前先重用
  • 如果原始团队完成了工作，那么他们会使用新的基础设施，而不是工作完成后再移交。
• 当团队被要求专注于客户特性以外的事情，他们觉得自己的价值不高
  • 相反，当团队除了功能交付外没有被要求处理其它任何事情，他们会觉得自己的价值更大。

我们吸取了以下教训：“假”的进展就是没有进展，相比实际发生的分工方式，我们足够小以至于我们应该以更好的方式来处理它 - 通过与产品负责人达成一致的意见来排产品待办列表（使团队能够在特性交付之外处理基础设施工作）。也许这就是我们那时的成熟度，有更多的传统项目思维在其中，但是就像有人曾经对我说的：“只有你没有从中学习才是失败”，当然我们学习了。

完成的和未完成的工作

创建“完成的定义”（DoD）是已知需要的，创建“未完成的工作”列表则在起初是未知的。LeSS帮助我们了解，明确在我们和生产环境之间未完成的工作也是同样重要和有帮助的（在我们的语境中）。

就我们而言，协作来创建是唯一的选择，因此我们举办了一个工作坊，向团队介绍了“未完成的工作”（已经定好了“完成的定义”）的概念，并花费了不到一个小时的时间来收集所有我们认为会归入此类（未完成的工作）的事情。我们把列表放到Wiki上，它提供了通往更大敏捷性的途径，并易于让所有人理解。

我们逐渐缩小了未完成的工作的列表，结果使“完成的定义”变大了，但我们始终没能克服所选第三方平台和不断增长的基础设施需求所带来的一些技术挑战。

朝着完美，持续改进

回顾会中重复出现的一个主题是，如何保持产品待办条目颗粒度尽量小，同时依然是以用户为中心的功能。为什么？好吧，我们迈出的每一步都让大家对供应商平台有更多的了解，而大颗粒度的待办条目似乎使学习变得更加困难，从而导致进展更难。

为了学习并不断前进，“探针”变得越来越有用。最初，其中一些是“假探针”-也就是分析。 因此，我们为应如何处理它们设置了一些基本规则：

• 应该编写一些代码或进行一些配置，以便有东西可以看到、和展示学习成果如何被应用
• 如果团队觉得满意了，完成探针时创建的验收测试应该放入Fitnesse。如果还不行，他们可以没有验收测试继续进行，但工作不能提交回主干（见下文）。
• 一般来说，被改变的内容将保留在其自己的分支上，不会被合并到主干中，这意味着这些代码不必可以上生产，而我们的总体代码库质量（我们使用Sonar和Squale来对代码进行质量评级，帮助我们衡量代码质量）不会因此受到影响。

教练

随着时间的流逝，很明显，这些团队和组织中的其他人正在努力变得敏捷（主要是通过使用例如LeSS和Scrum的框架），而为了给这些团队提供支持并加速他们通往更高效的状态，我们建立了敏捷教练社区。我们的愿景是提供内部公共培训，并建立有意义的、持久的教练关系。要成为该社区的成员，你必须证明自己：

1. 热衷于以增量和迭代的方式向客户和用户交付价值
2. 渴望改善自己和组织，以及组织中的人员和团队
3. 有一定的相关经验
4. 自愿参加

随着各团队的Scrum Master们发挥了积极作用来提供和接受培训与指导，社区在不断发展。随着时间的流逝，越来越多的团队找到我们，希望帮助他们以LeSS框架和原则迈向敏捷之路。

LeSS通过以下方式帮助了我们

在这个故事即将结束之际，我想与大家分享一个总结，对我们来说这次旅程中最重要的学习是什么，以及LeSS如何帮助了我们：

• 它告诉我们，让每个团队都有自己的回顾会，然后再让团队代表和其他人进行整体回顾会。
• 它提供了有关组织结构和经理角色的建议和明确指导。
• PBR(产品待办列表梳理)的结构并建议进行多团队PBR，除非已经明确只有一个团队有能力接受某特定待办条目（例如，当我们有一个团队在做基础设施）
  • 没有帮到我们的是花费了太多时间来制定和维护事件时间表。LeSS没要求这么做，而且也不是我们真正需要的。
• 允许我们对整个系统进行建模、讨论、理解和改进。
  • 该模型可能最终被抛弃，但是为其进行的讨论和辩论是无价的。
• 在框架中明确说明需要CI（持续集成）、TDD（测试驱动开发）、A-TDD（验收测试驱动开发）
  • 我们一直在宣传这样做的好处并建议团队这样做，LeSS明确指出，为了扩展和同步代码，必须强制执行这些做法。
• 向我们介绍了整个团队拥有一份产品待办列表和一个Sprint的价值。
  • 团队“异步”Sprint来补偿是行不通的：它会造成排队、浪费、并增加周期时间。一个Sprint产出同一增量意味着需要更多地专注于技术卓越和代码同步，这很有挑战但确实是正确的做法。

总结

将Scrum扩展到一个大型组织中多个团队开发同一产品是可行的，对我们来说做到这一点的最佳框架是LeSS。我们收获了很多经验而且有些地方其实可以做得更好，但我们也有很多成功的地方并学习了很多。通过更快、更有效地推出供应商平台，并在业务的其它部分采用这种方法，相信最终将使我们的客户越来越受益。