BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Ben Linders 关注 23 他的粉丝 ,译者 魏星 关注 0 他的粉丝 发布于 2017年4月25日. 估计阅读时间: 27 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

关键结论

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

在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)关注我们。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT