内容简介：《大规模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》。
在意识到不喜欢湿冷的气候之后， Bas Vodde 独自一人从荷兰旅行到了新加坡，在那里他一边练习uitbuiken（荷兰语，字面意思为超越，类似于冥想，指在人吃饱之后坐下来放松身心，以利于食物的消化）艺术，一边以教练、程序员、培训师和作者的身份帮助人们进行产品的敏捷和精益开发。他是LeSS和教练组织的联合创始人，分别在组织、团队、个人/技术实践三个方面有所建树。十多年来，他为软件开发、Scrum和现代敏捷实践培训了数千人。
查看英文原文：《 Q&A on Large-Scale Scrum: More with LeSS 》
感谢薛命灯对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号： InfoQChina ）关注我们。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
- 《Storm Applied》书评与作者访谈
- 《Storm Applied》书评与作者访谈
- 作者访谈：分布式敏捷框架指南
- 《Cassandra权威指南》第二版书评及访谈
- Renee Troughton访谈：领导力的敏捷模式
- 访谈 | 整网安全 锐捷的核心安全观
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
