《大规模 Scrum：More with LeSS》访谈

关键结论

• 大规模敏捷需要组织机构减少自身的复杂性。
• 需要一个恰到好处的框架来支持大规模敏捷。
• 所创建的环境鼓励自然涌现的非正式协作。
• 这使得团队开发人员能和客户直接沟通。
• 共同迭代和不断学习才能构建优秀的产品。

在 Craig Larman 和 Bas Vodde 所著的《More with LeSS》一书中，介绍了多团队合作生产一个产品时，如何采用 Scrum 来创建更加简单灵活的组织结构。《More with LeSS》是 LeSS 系列的第三本书（参见 LeSS 的其他书籍），是学习 LeSS 最具体也最基础的入门书籍。这本书还包含了有关采用 LeSS 的经验和见解。

现在可以在线阅读《More with LeSS》第二章。

InfoQ 采访了 Craig Larman 和 Bas Vodde，探讨了如下内容：LeSS 的定义、第三本书如何搭配之前出版的大规模 Scrum 方面的书籍、组织应该如何采用 LeSS、与功能团队合作、为了实现协作顺畅和整体性要怎么做、LeSS 如何看待经理的角色，以及对多站点组织采用 LeSS 的建议。

InfoQ: 可以为不熟悉 LeSS 的人简单介绍下吗？

Craig Larman 和 Bas Vodde：LeSS 是什么？简单地说，LeSS 是合作研发同一个产品的多个团队要使用的 Scrum 原则。

分别介绍如下：

LeSS 仍是 Scrum，是大规模的 Scrum（Large-Scale Scrum）。LeSS 不是新事物或 Scrum 的改进，也不是团队底层或者建立在团队之上的 Scrum。相反，它是关于在多团队场景下，如何实践 Scrum 的价值观、原则、意图、元素和优雅。同 Scrum 和其他按照敏捷定义的框架一样，LeSS 遵循“够用论”。

规模化 Scrum 并不是仅仅用于团队级别的、恰好包含了 Scrum 的特殊规模化框架。真正的规模化 Scrum 是让 Scrum 规模化。

应用于多个团队。这些团队跨功能、跨组件，由 3-9 名热衷于学习的成员组成，每个成员都为完成任务和产品交付而无往不前。

共同创造。 团队成员要一起工作，他们要有共同的目标，在公共 Sprint 里完成一个可交付的产品，以后还可能要持续交付，每个团队都很重视这一点，因为功能团队要负责产品的整体，而不是一部分。

同一个产品。什么产品？一个宽广完整的端到端的以客户为中心的解决方案，使用者是真真实实的客户。产品不是组件、平台、层或软件库。

LeSS 包含以下内容：

规则。即构成基础的一些规则。规则定义了 LeSS 框架的本质，这些规则是能够支持经验过程控制和以整体产品为中心的最低要求。例如，要在每一次 Sprint 时都进行总体回顾。

指南。一套适当的指南，阐明了组织在采用 LeSS 规则时会产生的影响。均基于多年的 LeSS 经验，值得尝试。例如，“采用三原则”。

实验。很多实验有情景要求，甚至不值得尝试。例如，尝试在团队间进行翻译转述。

原则。位于核心的是一套从采用 LeSS 的经验中总结出来的原则，包含了规则、指南和实验的有关信息。例如，要以整体产品为中心。

InfoQ: 在最新的关于 LeSS 的第三本书中，想传达 LeSS 什么样的差异化思想？

Larman 和 Vodde：我们想传达两种不同的思想。（1）自己做主。（2）LeSS 的目的是降低组织的复杂性，而不仅仅是 LeSS 本身。

自己做主

回到敏捷开发的早年，思想领袖们试图传达一个重要理论：够用论。让框架必需的元素集保持极简、刚好够用，这样组织内的人员就能自己做主。他们拥有、在乎和改进自己的想法，而不是借鉴、使用和跟从。团队将学习并创造性地解决问题，创建和发展符合情景的流程和实践。这就像丰田精益精神中挑战每一件事的心态和文化，工人们自己实践形成了自己的组织系统并不断地去完善。

当然，这并不意味着不必再像其他团队学习，他们应该！主要区别在于：传统方式看重流程，有顾问来指导团队并培训应遵循怎样的最佳实践方案。而现在更看重持续发展，团队通过阅读指南来学习早期值得关注的想法，同样也会通过实验来进行革新。

这便是为何 LeSS 被称作 LeSS（除了是 Large-Scale Scrum 的简写）：它更少。或者说，对于在一个产品线上合作的多个团队来说，它简单且够用。

不仅仅是 LeSS

很多人问：“大型复杂组织中要怎样应用敏捷?”

我认为这是一个错误的问题。为什么？

因为传统大型组织的复杂性并非必需的，它们的组织设计造成了这种假象，是一种不必要的复杂性。

这是至关重要的！很多大型群体是由一个个独立的功能团体和组件团队构成的，这就导致了协调混乱的问题。随后人们便会问，现存的这种组织设计，要如何应用“敏捷方法”呢。

这些大型群体是如何变复杂的？一个主要原因是，传统手段通过添加角色、流程、工件来解决问题。每当一个新的想法或一个需要解决的问题出现，就要做加法。添加角色、流程、工件这种传统方法看上去无害，但其实不然。更多的角色会导致更少的责任（和更多的协调沟通工作），流程减少了话语权和改进的空间，工件则拉大了团队和客户的距离。

因此，在 LeSS 中，我们会这样问：“如何简化不必要的大而复杂的组织设计，让组织自身敏捷，而不是去变得敏捷？” 所以，LeSS 能够去除组织的复杂度，对复杂组织的不必要的解决方案进行简化，用简单的方式解决问题。

因此，可以说，LeSS 的作用是降低规模，而不是增大规模。

如果在学习 LeSS 后有人说：“好吧，这里的角色、流程和实践还不够。我们想要一个更大的框架，里边有更多超好的实践。”… 那么他们真是理解错了重点。

InfoQ：为什么决定写这本书？

Larman 和 Vodde：在对 LeSS 前两本书（ LeSS 第一本书， LeSS 第二本书）的意见反馈进行思考时，我们发现虽然给出了很多观点，却鲜少提及如何着手实施，于是决定写第三本《 Large-Scale Scrum: More with LeSS 》, 最初是打算为前两本 LeSS 写一本入门书, 期望能帮助到新手团体。但是最终我们写出的不仅是一本入门书，它包含了不同的内容并且更有趣。当然它仍然是开始学习 LeSS 的最具体最基础的书籍。

InfoQ：这本书的目标读者是谁？

Larman 和 Vodde：这本书适用于在产品开发中希望创建一个自身敏捷的组织（而不是实施敏捷）的任何成员。采用 LeSS 意味着现有的组织设计将发生改变，包括结构、团体、角色、流程以及政策。所以，本书与能够决策组织变动的高级管理层相关…但也与团队成员、教练、Scrum 主管、产品负责人相关，也适合所有想了解 Scrum、LeSS 以及组织的人。

InfoQ：这本书如何与以前出版的 LeSS 书搭配阅读呢？

Larman 和 Vodde：我们原本打算写一本关于前两本 LeSS 的入门书。

最后却写了本不同的书。因为在研究具体如何开始采用 LeSS 时，引发了我们对规模化的最小要素的思考。然后？就有了 LeSS 规则、LeSS 指南以及这本书。书中也包含了 10 年来采用 LeSS 的经验和重要见解，对最重要的部分做了整合、阐明和强调。例如，我们意识到（至少阐明了） 产品定义范围对于规模化和系统优化的重要性，书中包括了关于产品范围的一套重要指南，而这些在前两本书中都没有提到过。

尽管这本书最后同我们原本打算的非常不一样（其实更好！），我们仍强烈推荐它作为学习 LeSS 的入门书。将来，前两本也许会进行修改，加入本书的概念。

InfoQ：如何在组织中采用 LeSS？

Larman and Vodde：首先，采用 LeSS 有一个采用三原则。

1. 专注原则。深入专注，需要把大量精力放在训练、管理支持等方面，从经验中学习，推测未来的变化。
2. 自顶向下、自底向上。自顶向下、自底向上意思是，由于 LeSS 要对组织设计（群组、角色、政策等）做深入的改变，则一定会包括高层管理人员的参与，来实施这些变化。而让成员被动去服从上级发出的命令也许没有效果，这时需要在团队中引进深入学习，激发团队的能量。
3. 自愿原则。 自愿原则，是指成员自愿参与变革，以此带来团队归属感和正能量。

实际操作上采用的方法取决于产品群组的规模。LeSS 中有 2 个框架。简化版 LeSS 框架，适用于 2-8 个团队的产品群体（例如 50 人左右）。大型 LeSS 框架，适用于单个产品超过百人或千人规模的产品群体。
为何提到这点？重申一下，这是因为具体方案会因为采用框架的不同而不同。事实上，两者正相反。

2-8 个团队采用 LeSS

小型群体部署简化版 LeSS 框架，规则是“一次性搞定”，“从一开始”就建立完整的 LeSS 结构。

为什么对于小型 LeSS 框架，要一次性完成呢？有几个原因，但或许最简单的概括是，LeSS 的组织模型在结构、角色、责任、流程、政策和实践等方面均与传统（现存）模型截然不同。不更改结构会造成无数深层次的冲突，其中大部分正是因为只改了名字而未做其他变更引起的。我们曾在《 Larman’s Laws of Organizational Behavior 》(《组织行为的拉尔曼法则》）一文中介绍过这种行为。

因为“仅有”50 人左右，他们可以在“一次性搞定”还没开始前的几个月组织起来准备，这是可以切实去做到的。准备过程包括了解 LeSS 的结构，系统性的思考，深入了解现存问题，让环境和团队为 LeSS 的第一次 Sprint 做好准备。在这本新书的入门指南中，我们讲述了采用 LeSS 的典型步骤。

1. 培训
2. 定义“产品”
3. 定义“完成”
4. 组建合适的结构化团队
5. 由产品负责人进行分工
6. 让项目经理远离团队

在这次的简单介绍中我们就不对细节进行展开了，我们只想强调，第一步“定义产品”是关键。很多事情都以合适的产品定义为前提，LeSS 的基本要求是产品定义要尽可能丰富、以实际的最终客户为中心。在实践中，很多公司都发现他们的产品和原本以为的并不相同。

大型 LeSS 采用

在对 500 人左右规模的多站点组织中采用大型 LeSS，“一次性搞定”的方法不再适用，这种过多更改带来的影响，会让组织无法吸收、学习和适应。因为有模型冲突的问题，我们也乐意看到能一次性完成，但这是不可行的。如果有人有办法，欢迎赐教。

采用大型 LeSS 时最经常被推荐（但不是唯一）的推荐方法是创建一个并行组织，这样能避免模型冲突带来的大多数问题，并同时遵守了三原则中的深入并专注。首先要整理好产品积压需求，然后选择一个以客户为中心的部分来采用 LeSS。这个以客户为中心的部分（在大型 LeSS 中被称作需求范围）基本上由 2-8 个团队构成，可部署小型 LeSS 框架。组织的其余部分仍能像以前一样运作，当然，如果理想，也要持续改进，尤其是在技术方面。

最后我们想给出的采用指南是：工作安全，而非角色安全。如果因为改变观念而失去工作，这对人们是极度不尊重和不公平的。事实上在变革管理方面，你不可能成功实施一个伴随着恐惧的变更，原因是不言而喻的。LeSS 意味着结构、角色和责任会发生深刻变化，自然无法确保一个人的角色安全。

InfoQ：实现新功能时，功能团队可能需要升级很多组件。这是否意味着开发人员需要了解整个系统？

Larman 和 Vodde：对于 2-8 个团队的 LeSS 采用，或许有必要这样。但是对于大型 LeSS 采用，就不太可能了。

不过，首先让我们定义一个术语：功能团队（在 LeSS 中或常见用法中），是一个跨职能以及“跨组件”的团队，为了了解和交付以客户为中心的功能，无所不作。可能包括 UX 调研、分析、设计、架构、组件整合、视频、图片、音频等。为了完成功能，要对所需的任何和全部组件（微服务、应用、层、模块、类…）进行编码。

这是否意味着，对于功能团队的每个产品，开发人员都要了解全部内容呢？答案是否定的。这种“不是…就是…”的看法是软件行业的常见模式，所以计算机从业者通常具有二元思维，是有原因的。因此，我们在几年前第一本关于 LeSS 的书中写了一章《假两难推理》。

假两难推理是说，个人或团队要么只了解某一件事，要么了解所有的一切，但实际上，很有可能不同的团队成员具有不同程度的专业知识，了解不同的模块。因此，为了完成一个功能，团队作为一个整体，需要拥有必要组件的相关知识，但不是每个人都需要了解全部。如果某个组件没有任何人了解，那么学习的时间就到了，学习是 LeSS 组织中一个关键和主导的行为。这并不新鲜，早在 1986 年 HBR（Harvard Business Review）的一篇描述 Scrum 起源的论文中已经定义过“多重学习”是 Scrum 的一个重要特性，意思是学习多层次技能和功能。

另外，一想到要处理不熟悉的代码，非程序员以及经常同垃圾代码打交道的程序员，会觉得这很可怕，令人生畏。但如果使用了 LeSS 在“技术卓越”中建议的 TDD 重要实践，来开发整洁的代码，就不是什么大问题。我们俩（Bas 和 Craig）除了作为 LeSS 的组织设计咨询师和高级管理者一起工作，也依然在亲自作为专业的程序员和其他开发者一起工作（这是一种对跨越职能架构的尝试）。因此，有了多年在开发整洁代码和 TDD 方面的直接经验，我们才敢说出“这不是什么大问题”这样的话。而对于要在遗留有大量垃圾代码的情况下采用 LeSS 这一常见问题，有一套补救指南和实验，包含分组的导师制度、现行架构学习研讨会等。

对于小规模 2-5 个团队采用 LeSS，有人了解代码库中的大部分或全部内容，是相对常见的。产品规模越大，则越不可能。Bas 正参与一个千人规模的大型 LeSS 采用，让一个人去了解每一部分代码是几乎不可能的。不过在这种规模下，也无需如此。为什么？大型 LeSS 由众多以用户为中心的部分构成，相互间有功能相关性，例如“交易处理”和“监管报告”。这些都被称作需求范围。团队倾向于在单个需求上花费更长时间。要注意，这些是客户需求的范围，而不是架构上的组件。即使这些需求不是基于架构组件的，专注在某个需求上（例如监管报告）的 4-8 个功能团队只需关心整个代码库的部分可预测子集也是可能的。这样，他们需要了解的代码便少于整个代码库。

InfoQ：为了让团队之间的协调和整合更加流畅，要做些什么？

Larman 和 Vodde：团队的协调和整合在 LeSS 中非常重要，但 LeSS 的观点通常让人吃惊，因为人们期待的是协作行为（big room planning）、会议（Scrum 的 Scrum）或角色（项目经理、集成型团队）。但是在 LeSS 中完全没有这些，事实上，LeSS 的建议正相反。为什么。两个原因：（1）专门的协调角色会减少大家的协作责任感。（2）我们发现，正式的协作通道常会减少团队发起的、自然涌现的、自组织的、分散的协作，而我们认为这些原本更能提高效率。

如何鼓励团队间的分散式的信息协作方式？基础如下：

• 团队自己决定如何协作
• 功能团队要有共同的目标
• 以产品的整体为中心
• 友好的物理环境和技术环境

我想重点介绍下共同目标。在传统的组织结构中，协作往往是一种令人讨厌的打扰。测试团队发现 bug 时会打扰开发团队。后端团队需要前端进行修改，就要去打扰他们，中断了本来在做的其他事情。而如果沟通协作没那么正式，而是自然地发生，也许就不会令人讨厌，反而让人感到有用和及时。或者，像 Yves Morieux 在关于简化组织结构的 TED 演讲中说的那样，“我们创建的组织结构应该有助于其中每个部分的合作。” LeSS 通过对功能团队的结构重组来创建这样的组织，这些团队无所不做，他们共享代码，并将在 Sprint 结束时交付产品作为共同目标。团队间的协调合作基于他们共同关心的任务，这一切同时发生，为所有参与其中的团队带来了好处，而且与它们直接相关。

具体说下集成：LeSS 提倡先进的开发实践，例如，对主线不断更新进行持续集成，以保证产品在任何阶段的可交付，甚至在任意时刻的可持续交付。在采用大型 LeSS 时，通常首先要做的便是自动化测试、快速构建和自动化部署。

再从宏观上看：协作和集成是紧密相关的，传统上大多数协作都和集成有关。当两个团队想整合他们的工作，他们就需要协作。但是当使用持续集成时，可以将事情反过来。通过持续集成，能轻易地知道有哪些人在同时开发某一部分系统。因为可以共享工作成果，互相协作对双方都有好处。这样，取替用协作来支持集成，我们有了能够实现协作的集成。我们将这种实践称作“用代码交流”。 当然，这样一来，建分支变得比以前更讨厌了。

还有更多的关于加强这种非正式、松散式协作的 LeSS 指南，例如社区、多团队活动、开放空间、出差、分组导师、侦查员。就不在此一一细说了。

InfoQ：LeSS 如何看待经理这一角色？

Larman 和 Vodde：大多公司都有众多不同的经理，我们只关注两种：项目经理和开发经理。

项目管理

在 LeSS 的组织中，项目经理这一角色在产品开发过程中近乎消失了。一部分是因为自我管理型的团队接过了大部分职责，一部分是因为避免在产品开发中使用项目模式。

LeSS 遵循传统的组织理论。如果想增加组织的弹性（敏捷性），可以进行职责委派，从而不会让决策减慢响应。这使组织更扁平，经理的数目也更少。

当然，我们不是在建议辞退所有的项目经理，因为这样做违背了 LeSS 指南中提到的“工作安全而非角色安全”的原则。相反，因为这些人通常都很聪明，可以在组织中找到不同的角色定位或融入团队。

在大型 LeSS 的产品群组中，特别是涉及硬件制造的情况下，可能仍会有最后一个关于产品发布的项目，以及和产品发布活动（如制造物流）相关的管理角色 。在采用 LeSS 时，这些现存的项目角色不会立即改变，不过，越是深入实施持续交付的组织，对项目管理的需求就越少。

开发管理

传统上，这些经理要参与产品从开始决策到生产的过程。在 Scrum 和大规模 Scrum 中，决策移交给了团队，尤其是产品负责人（来自商业部门，他们并不是开发人员或项目经理），生产完全移交给了这些自我管理型的团队。有了自我管理，团队的职责得到扩大，引用哈佛大学杰出的团队研究员 Richard Hackman 的说法，职责中包含了“对流程和进展的管理与跟进”。

在 LeSS 组织中有管理者的角色吗？如果从来不存在管理者（是的，真有这样的公司），那在采用 LeSS 时不需要去增加这样的角色。但是如果已经存在管理者，他们可是很有价值的，不过他们的角色可能会改变。他们不专注在每日的产品生产中，而是注重提高产品开发体系中的价值传递能力。通过实践去发现、鼓励暂停和修复以及对一致性的实验，管理者这一角色要对产品开发体系做出改进。

InfoQ：对多站点组织采用 LeSS 有什么建议？

Larman 和 Vodde：我们为客户采用 LeSS 的大部分经验都来自超大型或多站点的产品群组（分布地点通常包含亚洲、欧洲和美洲），因此这对我们来说是一个熟悉的领域。我们的首要建议是尽量避免这种情况。人们常认为这在当今世界是不可能的，但这仍是一个选择。许多非常优秀的产品都是同地点开发，这是有道理的。

也就是说，多站点产品是可以采用 LeSS 的。重要的是，一个功能团队应在同一地点办公。为什么？一提到这种成员在不同地点办公的分布式团队，几乎无一例外地会感觉这并不算真正的团队，而像各自忙着自己事的一群人。好的团队不是这样工作的，好的团队是有高度凝聚力的社交单元，有共同目标，互相学习，时刻都在一起工作，会在白板上进行团队设计研讨，结众编程，无序结对编程等。因此同地点办公有巨大的好处。

现在如果整个开发部门要分布在 7 个城市，只有 7 个人，我们便只能接受分散这个事实。但是考虑一个典型的大规模多站点情形，也许有 200 人共同开发一个产品，50 人负责站点 1，50 人负责站点 2，以此类推。这种情况，没有理由再让一个 7 人左右的团队不在同一地点，因为每个地点都有超过 7 个人。

所以 LeSS 中多站点开发的基础是：每个功能团队要在同一地点。如果站点 1 有 3 个团队，站点 2 有 5 个团队，也是完全可以的。这种情况下，剩下的关键问题便是如何围绕不同站点的团队展开协作。不幸的是，没有魔法能够消除团队分散的痛处，减少痛苦的方法也已有共识，包括视频会议、存储共享，Slack 这样的工具，频繁出差等。

InfoQ: LeSS 如何支持组织的持续改进？

Larman 和 Vodde：持续改进应该由谁来做？传统上讲，改进的行为是独立于团队，由专门的改进人员推动的。质量人员、安全人员、程序顾问、自由人，无论怎么称呼他们吧。这几乎无法带来真正的改善，因为他们没有足够重视，也看不到工作中的真正痛点。

显然，答案应该是“每个人”。但如何让组织中的每个人都进行持续改进呢？他们需要关心自己如何工作，他们要能够掌控自己的工作方式。这样我们就回到了开头讨论的“自己做主”这个话题了。当员工掌控了自己的工作，对工作效果做出快速反馈，被鼓励并被赋予了做这件事的权利，那么就能做到持续改进。

为了实现这些，框架应避免给出所有情况下的答案，以防产品部门只会照做。相反，产品部门应该边实验边改进。因此，框架只给出了一个最小的结构，允许有透明度、允许反馈和做实验。因此…

More with LeSS，不仅仅是 LeSS。

关于《More with LeSS》的作者

在结束了失败的街头音乐家职业生涯之后，Craig Larman转行学习计算机科学，主攻人工智能领域（并有了一点自己的成就）。他与好朋友兼同事 Bas Vodde 一起创立了 LeSS 并合著了三本 LeSS 的书籍：《Large-Scale Scrum: More with LeSS》、《Scaling Lean & Agile Development: Thinking & Organizational Tools for Large-Scale Scrum》、《Practices for Scaling Lean & Agile Development: Successful Large, Multisite & Offshore Product Development with Large-Scale Scrum》。

在意识到不喜欢湿冷的气候之后，Bas Vodde独自一人从荷兰旅行到了新加坡，在那里他一边练习 uitbuiken（荷兰语，字面意思为超越，类似于冥想，指在人吃饱之后坐下来放松身心，以利于食物的消化）艺术，一边以教练、程序员、培训师和作者的身份帮助人们进行产品的敏捷和精益开发。他是 LeSS 和教练组织的联合创始人，分别在组织、团队、个人 / 技术实践三个方面有所建树。十多年来，他为软件开发、Scrum 和现代敏捷实践培训了数千人。

查看英文原文：《 Q&A on Large-Scale Scrum: More with LeSS 》

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

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