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

内容简介：《大规模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的典型步骤。

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

在这次的简单介绍中我们就不对细节进行展开了，我们只想强调，第一步“定义产品”是关键。很多事情都以合适的产品定义为前提，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》。

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

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

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

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

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。

码农书籍

Single Page Web Applications

Michael Mikowski、Josh Powell / Manning Publications / 2013-9-30 / USD 44.99

Code for most web sites mostly runs on the server. When a user clicks on a link, the site reacts slowly because the browser sends information to the server and the server sends it back again before di......一起来看看《Single Page Web Applications》这本书的介绍吧!

码农工具

图片转BASE64编码

在线图片转Base64编码工具

MD5 加密

MD5 加密工具