特征团队使用 LeSS，每个迭代交付你的产品

Craig Larman 在 Agile Eastern Europe 2015 会议上就大规模 Scrum（LeSS）发表了主题演讲。InfoQ 针对 LeSS 对 Larman 进行了采访，主要关于什么使得 LeSS 不同于其它规模化框架、使用经验过程控制提高组织敏捷。

同时 Larman 还解释了组织如何与特征团队合作，并举例说明了团队和干系人如何直接与客户和用户接触，如何协作实现每个迭代交付产品。

InfoQ：你能为 InfoQ 读者简要介绍一下 LeSS 框架吗？

Larman：LeSS 是规模化 Scrum。是将 Scrum 原则和理念应用到同一产品线的多个团队中。包括经验过程控制、每次迭代可交付（通常是交付中）的产品（提高了透明度，构建了强反馈环，允许及早交付价值）、和自管理团队——包括工作在同一产品线上的多个团队之间的自管理。

作为综合学习资源，读者可以在 less.works 网站中找到所有有关 LeSS 的资料，包括视频、图表介绍、案例研究等等。

InfoQ：什么使得 LeSS 不同于其它大规模敏捷方法，比如 SAFe 和 DAD？

Larman：LeSS 不是“包含在各个团队之中，与 Scrum 略有差异的 Scrum”。似乎在一些规模化方法中，“规模化框架包含 Scrum 就像消防员控制火情一样”引用自 Michael James。不如说，当多个团队以一种大规模、一致的 Scrum 方式工作于同一生产线时，LeSS 解决了如何应用 Scrum 原则和要素，并且是那些鼓励经验过程控制、透明性、自管理团队、系统最优化等的原则和要素。

第二个关键要素是 LeSS 非常简单。LeSS 内的定义非常少。但是这些定义又极其重要。为什么呢？我有 Rational 统一软件开发过程（RUP）的背景，（在 20 世纪 90 年代）我发现在导入方面，拥有大量指示（prescription）和定义的框架（比如 RUP）往往不起多大作用。原因之一是产品种类过于繁多；有很多情景因素和原力。一个高度定义的工艺处方（process recipe）方法真的不起作用；它不够情景化。另一个原因是强规范性的框架会抑制学习与适应，而学习与适应又是经验过程控制的关键要素。框架的另一个问题是对员工，包括可能特别对高级经理定义了很多的“答案”，这会多少让他们觉得“嗯，我们已经为这个问题买了解决方案。我们不需要深入理解根源问题和系统，学习用我们特有的方式改善它们。相反，我们只需要让新采用的工艺处方和新聘请的专家教练解决组织设计问题。”但是，这不会导致好的结果。

因此，Less 跟 Scrum 一样，只包含了非常少的元素。这不是它的弱点或者疏忽。这是有意为之，因为意识到需要强有力的经验过程控制和学习，和因为大量情境中不同的团队，通用的或者具有详细规范性的框架不能解决根本问题。因此出现了更侧重学习与适应、较少定义的过程，并且这是件好事。因此我们的口号是“不只是 LeSS（More With LeSS）”。

但是，这里有一个非常有趣的见解和关键点：由于“更少的指示”似乎是个很不错的注意，因此合乎逻辑的结论就是基本上没有定义、细节、或者指示。例如，在学习型组织运动中，只有“系统思考”、“自我超越”等等原则。这些都非常的棒！但是，如果你进入一个大型的传统电信基础设施设备组，然后仅仅对他们讲”嘿，兄弟们！转变！系统思考！自我超越！”好吧，什么都不会改变的。为什么会这样？因为组织处在 Shu 环境下或者改变阶段。他们需要最低限度的具体的指导。

这就是我在职业生涯中看到的：当处理 Shu 环境下的组织时，变革系统可以是过分详细的或者未指定的。它们之间有个最有效点“刚刚够的具体指导就可以做出真正的变革，不需要再多。”我们和其他许多人一样，感觉并观察到 Scrum 恰好就是那个最有效的点。对于那些安于现状的系统，为了发起变革，实现透明和经验过程控制，它包含了刚刚够的具体结构。LeSS 也一样，对于大规模团队：拥有刚刚够的具体指导可以发起系统变革，实现真正的透明和经验过程控制。并为每一个独特团队在特定情境下的学习和适应留下了广阔的空白空间。

另一个使 LeSS 不同于其它方法的是其强大的整体产品关注能力。例如，多个团队之间只有一个共享的产品 Backlog，只有一个整体的产品负责人，并且多个团队工作于同一个迭代，实现每个迭代交付可交付的产品。这对于系统最优化、透明性和专注整体产品非常重要。相反，如果每个团队都有他们独立的所谓的“产品”Backlog，就会大大减少透明度，增加局部优化，和其它形式的碎片。

除了我的这些回答，读者们不妨阅读 less.works 网站的“ Why LeSS？”文章。

InfoQ：你提到 LeSS 包括经验过程控制。你能解释一下组织如何使用它提高敏捷？

Larman：首先，明确含义：经验过程控制（EPC）意味着没有指定（任何）特定技术、过程或者实践的元过程框架。相反，它强调的第一主题是透明性、检验和适应。

对于使用 EPC 的组织而言，第一步是 _ 做减法（subtractive）_。组织必须放弃对对他们问题极其重要的解决方案和那些购买后只需要安装和遵循的系统的信赖。他们必须放弃对规定的、明确的流程的依赖，因为领域内的答案比如产品开发有其固有的复杂性和可变性，具有高度学习的必要性。

为了使用 EPC，下一步是 _ 做加法（additive）。最终人们必须在 _ 遵循明确的工艺处方之上添加学习与适应，将其作为核心价值和驱动力。

另一个做减法的要素是移除影响透明度的障碍，比如有关揭示真正发生了什么的奖励或者敏感的处罚，而不是“遵循计划”的文化。我把它称为“管理可变性而非隐藏可变性”的文化。只有影响透明性的障碍被移除，EPC 才能蓬勃发展。

当你成功引入 EPC 后，你能得到什么？根据定义，组织不断地试验，能够学习与适应组织系统，对反馈做出响应。当首要机制是基于 EPC 的一个学习型组织时，团队结构、流程、技术、场所、角色和职责都可以进行修订和根据试验变化。这是组织设计外循坏的真正的敏捷，通常这种组织设计被导入 LeSS 的团队围绕和交叉。

当然，LeSS 团队在内循环进行迭代，这种组织敏捷性意味着团队可以花费较低的代价和较少的时间改变方向，因为组织结构和流程并没有整合到组织内部。

那么，LeSS 团队可以 _ 为了变化而变化 _。这就是敏捷。

InfoQ：你在 Agile Eastern Europe 的主题演讲中建议与特征团队合作，而不要使用组件团队。你能详细解释一下为什么？

Larman：首先，明确一下我们的术语，组件团队是从事代码的一个子集或者一个组件的团队。与组件团队相关的是专用代码。例如一个由 5 名程序员组成的从事用户界面层的团队，和一个由 6 名程序员组成的从事服务器端子系统——X 的团队，等等。

在进一步分析之前，我想解释清楚组件团队没有“好”或者“坏”之分。组织设计内团队的优劣取决于团体为什么优化系统。例如，军事防御团体为了最大保密性或者最大化对“整体”的无知决定优化组织设计（为了产品开发）。单一的功能团队和筒仓需要进行大量的传递工作，从而实现对优化目标的支持，并且每个团队仅仅做了工作的一部分。并且由哪个团队完成这个工作也会成为争论点。

但是，通常，产品组希望优化系统从而缩短概念兑现的周期时间。或者为了组织敏捷性，或者其它原因！但是有趣的是当就此目标分析当前设计时，设计与目标往往是不一致的。

例如，一个团体是否由组件团队构成，关键是看一个完整的端到端客户需求是否是跨多组件，比如“前端和后端”。当然在大规模开发中通常不止 2 个组件，可能有 5 或者 10 个组件。因此在这种情况下，必须如何组织工作？让我们从端到端需求分析开始，谁做？它不可能是其中一个组件团队，因为我们甚至不知道会涉及哪些组件团队，即使我们知道，这种分配看上去也有点武断。因此与之相反，我们在做这项工作的组件团队前面贴上“需求分析”组标签，并创建一个文档转手给组件团队。谁来做端到端测试？5 个组件团队中的哪一个？目前尚不清楚。因此我们给做端到端测试的组件团队贴上测试组标签。实际情况更加复杂，但是我简化了分析。关键是将组件团队的选择作为设计中的一个约束，然后创建一个连续的生命周期过程，在单一功能团队之间建立筒仓，将工作转手给其它组，建立弱反馈环，更多的在制品，和更多的信息散布。

现在，这个结构跟特征团队相比有更多的计划延期、开销超支。如果人们真的希望为了缩短周期时间，而优化组件团队的组织系统，那么这个模型与目标就不一致。同样，如果你想在系统中引入大量的变革，成本和变革开销将比特征团队模型要高很多。因此，如果目标是为敏捷优化，那么它与该目标就不一致。

我想再次强调一下，这与好坏无关。与组织设计是否与系统优化的目的一致有关。

但是这是否意味着 LeSS 是否应该只有特征团队，没有组件团队呢？不是的。

LeSS 包含了原则和思维工具的概念，这是 LeSS 的基础。包括：系统思考，精益思维，排队论和假两难推理（False Dichotomy）。人们通常会把一种想法或者指导方针，比如“如果希望缩短周期时间或者提高敏捷性，相对组件团队更倾向于特征团队”，将这种表述错误理解成“在 LeSS 中，你只能使用特征团队”，这种理解就犯了假两难推理的思维错误。相对肤浅的“A，不是 B”或者“A 好，B 不好”这种表述，我们建议一种更加细致入微的见解。

更多这个主题的相关信息，可以阅读特征团队和组件团队。

InfoQ：你能举例说明产品负责人、团队和干系人在每日协作的基础上，如何使用 LeSS 方法实现每个迭代交付产品？

Larman：因为 LeSS 强调专注整体产品，并且多个团队共享一个产品 Backlog（而不是每个团队一个所谓的“产品”Backlog），因此只有一个总的产品负责人。

因此这个问题就变成“一个产品负责人如何与所有团队协作，实现每个迭代交付产品？”

在 LeSS 中一个重点是产品负责人是“真正”的产品负责人，他不是业务分析师或者项目经理的另一个名字。比如，她是产品经理，负责产品和投资回报率。所以这个真正的产品负责人有一个显著的向外的侧重点，关注客户和竞争对手等等。但是，由于产品负责人同时还需要向内关注团队，那么她如何能够避免超负荷工作呢？

在 LeSS 中一个关键答案是产品负责人专注方向和优先级（或者 Scrum 中的“排序”）而不是细节和说明。在 LeSS 中，所有细节的发现和项目的说明都应该尽可能让团队（通常 Scrum 跨职能、跨组件团队都是由多种技能的人组成）直接与真实客户和用户沟通完成。

尽管产品 Backlog 细化（PBR）是一个关键耗时的活动，但是产品负责人却不需要深入参与细节，为即将到来的迭代准备好事项。比如在 LeSS 中，她可以在一次 Sprint 中，参加为时 3 小时的全部的 PBR会议，与所有团队的代表讨论大方向和优先级，同时进行轻量级的分析。但是进一步的事项细化都是在随后的单独的（或者多团队）PBR 会议上完成的，在 PBR 会议上，团队通过直接与客户和用户协作，完成大部分细节的细化。

通过这种方式，产品负责人就不会成为团队和真实用户之间的瓶颈或者间接层。相反，她是一个媒介，帮助团队和用户直接沟通。这会给减少工作传递，信息散布，提高团队和用户的共创等等带来很多优势，并且它减少了产品负责人的投入精力。

再回到原来的问题，在 Less 中另一种互相协作实现每个迭代交付产品的方法是通过 持续集成。多年来我意识到几乎没有人知道持续集成意味着什么。我走到一个客户面前，问道“你们有做持续集成吗？”你知道他们是怎么回答的吗？“哦，是的。我们有一个构建服务器！”但是这几乎与持续集成没有一点关系。

我想与大家分享一下持续集成令人惊讶的含义：连续不断地集成.。

这几乎与构建服务器没有关系。一些团体可以 _ 从 whazoo 中移除 _ 构建服务器，但是，如果比如开发者正在签出代码，并且打算在与其他人的代码合并之前，将代码签出一段时间（比如说几个小时），那么就会出现 _ 延迟 _ 集成。或者开发者从事独立的分支，那么也会出现延迟集成。

因此，在 LeSS 中，我们必须有真正的持续集成，必须改变开发者行为。例如，尽可能缩短签出和合并每个人代码的周期时间，比如每个 TDD 周期为 5 分钟。并且所有团队应该避免分支，共同工作于“主干”。

在 LeSS 中，为了实现每个迭代交付产品的要求特别严格。这会带来更多的“在代码中协调”而不是“在计划中协调”。它更多地将人们推向一种的“拉重于推（pull over push）”的工作模式中。

这个问题的另一方面是围绕架构进行协调。在 LeSS 中，我们为跨团队问题推荐社区，例如，我们推荐一个设计 / 架构社区来构建敏捷建模，比如协调有关广泛设计的设计问题。社区成员都是在一起进行每个迭代的常规特征团队的成员或者是常规特征团队所必须的成员。

最后，回到当前迭代计划的具体问题来创建并在迭代结束时交付。在迭代规划 1 中，唯一的产品负责人决定事项的顺序，并提供给所有的团队。然后，在迭代计划 1 中，她列举她提供给所有团队的事项（就像把卡片放在桌上），之后她置身事外，让团队自组织来决定自己负责哪些事项，迭代计划 1 是所有团队（或者所有团队的代表）共同参加的一场普通会议。这非常的简单。

然后每个团队进行他们自己的迭代计划 2，基本跟一个团队的 Scrum 一模一样。但是，如果团队之间需要很多的协调工作，就需要有人将他们组织到一块，增加沟通。

对于寻求更完整的答案，读者可能会发现 LeSS 框架的详细说明会起到帮助。

InfoQ：你能举例说明组织如何做到使得团队直接面对客户和用户工作的？

Larman：当然可以，例如我最近在 JP Morgan 为导入 LeSS 而一起共事的一个小组。 InfoQ 有篇文章对该故事进行了详细描述。针对你的问题，重点是传统小组扮演的团队和用户之间的间接层角色被移除。在这种情况下，业务分析和项目经理组也被移除，例如，前业务分析师加入常规特征团队，并逐渐成为多元化才能的工作者。然后在每次迭代的 PBR 会议中，亲身实践的用户（比如银行交易处理分析员）会加入与一个或者多个团队面对面交流。

企业如何做到这一点？通过较高的管理层同意改变组织设计进行支持，然后通过 Scrum Master 和产品负责人鼓励改变行为，实现团队和用户的沟通。

InfoQ：有没有 InfoQ 读者可能感兴趣的有关 LeSS 的新发展？

Larman：我们在 2008 和 2010 年出版了前两本 LeSS 书籍。它们都是“ha-level”的书籍（Shu-ha-ri 隐喻），阐述了针对不同环境的 600 种试验方法。

自那以后，LeSS 引起了人们极大的兴趣，因此我们试图让人们更加容易地导入，和更好地支持它。所以很快我们将出版第三本 LeSS 书，更多的是 Shu 级别的前传和概述，并且 less.works 网站可以作为此书的一个在线补充。

关于受访者

Craig Larman是 _ 大规模 Scrum (LeSS)的共同创始人 (与 Bas Vodde 一起)，是一位关注企业导入和用 LeSS 进行超大型产品开发的组织设计顾问。除了成为早期的 Certified Scrum Trainer 之一外，从 2004 年开始，他还帮助许多集团进行 LeSS 导入，例如 J.P. Morgan、爱立信、UBS、施乐、bwin.party、BML、ION Trading、印度 Valtech 等。他是即将出版的新书 _Large-Scale Scrum: More with LeSS、以及另外两本 LeSS 书籍 _Scaling Lean & Agile Development:Thinking & Organizational Tools_ 和 _Practices for Scaling Lean & Agile Development:Large, Multisite, & Offshore Product Development with Large-Scale Scrum_ 的作者之一（都是与 Bas Vodde 一起）。

查看英文原文： Using Large-Scale Scrum (LeSS) with Feature Teams to Ship Your Product Every Sprint