第2章 LeSS

构建“设计”的方法有两种：一种是简单到明显没有缺陷，一种是复杂到没有明显缺陷。

——C. A. R霍尔

但团队Scrum

Scrum是一个“经验-过程-控制”开发框架，在这个框架中，跨职能的自管理团队以迭代增量的方式开发产品。在每一个时间固定的Sprint中产出一个潜在的可交付的产品增量，理想情况下产品增量是要发布的。产品负责人只有一个，负责最大化产品的价值，确定产品待办事项列表（Product Backlog）中的条目优先级，并根据持续的反馈和学习成效以自适应的方式来确定每个Sprint的目标。小团队负责实现Sprint目标；对团队是否可以承担单一的专门化角色未加限制。Scrum Master教授团队成员为什么要使用Scrum以及如何从中获取价值，指导产品负责人、团队和组织如何应用Scrum，并充当了一面镜子的作用。这里没有项目经理或团队领导这类角色。

经验性过程控制需要透明，指的是可交付产品增量的短周期开发和审查过程中的透明度。它强调对产品及其创建方式的持续学习、检查与调整。它基于这样一种认识，即开发中既详细又程式化的过程过于复杂和动态，这会妨碍人们对过程的质疑、参与和改进。

《Scrum指南》和《Scrum简章》中强调的是一个团队，而不是很多团队一起工作。这自然会引发人们对大规模Scrum情形的思考。

2.1 LeSS概述

LeSS也是Scrum——大规模Scrum（LeSS）并不是全新的或改进的Scrum。它不是每个团队在基层使用的Scrum，也不是层次化组织结构中置于顶层的什么东西。相反，其所涉及的是如何在大规模环境（context）下尽可能简单地应用Scrum的原则、目的、要素及其所表现出的灵活和优雅。与Scrum和其他真正的敏捷框架一样，LeSS是一种为能产生重大影响而生的“简单方法”（参见第3章）。

扩展Scrum不是一个特别的、可伸缩的框架，它只包括团队级别的Scrum。真正的扩展Scrum是Scrum可扩展的方法。

LeSS应用于许多团队——跨职能、跨组件、全特性团队，由3～9名注重学习的人员组成，他们完成所有工作——从UX（用户体验）设计到代码编写，再到视频交流——以完成各项条目，创造出可交付的产品（参见第4章）。

LeSS在于协同工作——团队之所以协同工作，是因为他们有一个共同的目标，即在一个共同的Sprint阶段结束时共同实现一个可交付产品，而这一点每个团队都会时刻关注，因为他们是负责交付整体产品而不是产品局部的特性团队（参见第13章）。

LeSS用于生产一个产品——什么样的产品呢？一个清晰完整的、端到端的、以客户为中心的、有真正客户使用的解决方案。它不是组件、平台，也不是什么层或者库（参见第7章）。

2.1.1 背景

2002年克雷格撰写《敏捷与迭代开发》（Agile & Iterative Development）一书时，许多人还认为敏捷只适合于小团队。当时，我们俩就对将Scrum应用于大型、多地点和离岸的开发非常感兴趣，并且我们不断收到来自各方的越来越多的这类请求。因此，自2005年以来，我们一直与客户合作以扩展Scrum方法。如今，两个LeSS框架（小型LeSS和巨型LeSS）已为全球不同领域的大型集团所采用：

❑电信设备领域——爱立信和诺基亚通信

❑投资和零售银行领域——瑞银

❑交易系统领域——ION交易

❑营销平台和品牌分析领域——Vendasta

❑视频会议公司——思科

❑在线游戏（下注）公司——bwin.party

❑离岸外包公司——Valtech印度

从规模角度看，什么算是典型的大型LeSS案例呢？在一两个地点有五个小组也许可以算作大。我们参与过这种规模的项目：从几百人，到一个巨型LeSS（超过一千人），有很多个开发地点，数千万行C++代码，还有专门定制的硬件。

进一步学习LeSS

为了帮助人们学习，加之与客户合作的经验，我们在2008年和2010年先后出版了两本书，讨论了如何利用LeSS框架进行扩展敏捷开发：

1. 《精益和敏捷开发大型应用指南》（Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum）——解释了LeSS的思想、领导力和组织设计的变化。

2. 《精益和敏捷开发大型应用实战》（Practices for Scaling Lean & Agile Development:Large, Multi-site & Offshore Product Development with Large-Scale Scrum）——根据我们与客户合作的经验，分享了LeSS具体的试验成果，以及在产品管理、架构、规划、多地点、离岸、合同等方面的试验成果。

本书是LeSS系列的第三部，是一部前传和入门书，将综合阐明和强调什么是最重要的。

除了这些书之外，从LeSS网站（less.works）中还可以找到更多的在线学习资源（包括书籍章节、文章和视频），以及课程和辅导方面的信息。

2.1.2 试验、指南、规则、原则

前两本LeSS书强调的是：在产品开发中没有最佳实践，而只有在特定环境中最适合的实践。

实践是在环境中形成的；毫无顾虑地宣称这些实践是“最佳的”会让它们与动机和环境脱节，继而变成纯粹的仪式性活动。推广所谓的最佳实践会扼杀学习、提问、参与和持续改进的文化，因为人们会想为什么要挑战最好的东西呢？

因此，早期的LeSS书籍分享了我们和我们的客户尝试过的试验，我们不断鼓励人们去了解和应用这一试验思想。但随着时间的推移，我们注意到这种试验思想存在两个问题：

❑新团体做出了对自己有害的不明智决定，以非预期的方式采用LeSS，并带有明显的问题；例如：团体为每个团队创建一个需求领域（Requirement Area）。哎哟！

❑新团体会提出，“我们从哪里开始？什么最重要？”等问题。可以理解他们没有学习关键的基础知识。

基于这种反馈，我们进行了反思，并重回到Shu-Ha-Ri的学习模式：Shu——遵从规则，学习基础；Ha——打破规则，探索场景；Ri——全面掌握，开创新路。在Shu层面的LeSS采用中，我们利用简单框架提供的规则来启动经验性过程控制和整体产品聚焦。这些规则定义了两个LeSS框架，随后将对两者进行介绍。

LeSS总结并建立在这些要点之上，其内容包括：

❑规则——用于启动和形成基础的规则。规则定义LeSS框架，框架支撑经验性过程控制和整体产品聚焦（原则）。例如，每个Sprint举行一次全体回顾（Overall Retrospective）。

❑指南——一组繁简适中的指南。可有效地指导如何采纳LeSS规则，也是试验的一部分；这些指南基于多年的LeSS应用经验，值得尝试，并且其包含了一些技巧性提示。指南通常很有帮助，但同时也需要不断改进；例如，指南：三个采用原则。

❑试验——许多试验都是非常情境化的，甚至可能不值得去尝试。例如，尝试……团队翻译。

❑原则——一组从LeSS应用经验提炼而来的原则，是LeSS的核心，指导着规则、指南和试验；例如，整体产品聚焦。

如右侧LeSS全图是观察LeSS的个好方法。

LeSS全图展示的内容将作为我们介绍LeSS的顺序：

1. LeSS原则（principles），下一节。

2. LeSS框架（frameworks，由规则定义），本章其余部分。

3. LeSS指南（guides），本书其余章节。

4. LeSS试验（experiments），已经在前两本LeSS书中介绍。

2.1.3 LeSS原则

LeSS规则定义了LeSS框架。但这些规则具有极简主义的特征，并没有说明特定环境下如何应用LeSS。LeSS原则为人们制定这些决策提供了基础，参见下图。

大规模Scrum也是Scrum——它不是新的被改进的Scrum。确切地说，LeSS研究的是如何在大规模环境中尽可能简单地应用Scrum的原则、规则、要素和目的。

透明度——基于有形的“完成”条目、短周期、协同工作、共同定义，以及对工作场所恐惧的消除。

以少为多——我们不想要更多的角色，因为更多的角色会导致团队的责任感更弱。我们不想要更多的工件，因为更多的工件会导致团队和客户之间的距离更远。我们不想要更多的流程，因为更多的流程会导致团队学习更少，团队对流程的所有权更弱。相反，我们希望拥有更少（很少）的角色和更负责任的团队，希望拥有更多以客户为中心的团队以便用更少的工件构建更有用的产品，希望拥有更少的既定流程让团队拥有更多的流程所有权和更有意义的工作。我们要的是以少为多。

整体产品聚焦——一个产品待办事项列表、一个产品负责人、一个可交付产品、一个Sprint——无论是3个团队还是33个团队。客户希望在有内聚力的产品中提供有价值的功能，而不是在分离的部件中提供技术性的组件。

以客户为中心——专注于了解客户真正的问题并解决这些问题。识别付费客户眼中的价值观。从客户的角度减少等待时间。增加并加强与实际客户的反馈回路。每个人都需要知道他们今天的工作如何与付费客户直接相关，如何让付费客户受益。

持续改进以求完美——完美的目标是：始终以几乎无成本、无缺陷的方式创建和交付产品，让客户感到满意，让环境得到改善，让生活更加美好。为实现这一目标，团队需要不断地做谦逊和激进的改进试验。

精益思想——创建一个组织体系，其基础是认可管理者作为导师来应用和教授精益思想，设法改进、促进“停止与修复”（stop-and-f ix）实践，并认可“现场观察”（Go See）观念，加入尊重他人和不断挑战现状的改进心态这两大支柱，所有观念和行动都应朝着完美目标前进。

系统思维——观察、理解和优化整个系统（而不是局部），并使用系统建模来探索系统的动态。避免将重点放在个人和单个团队的效率或生产力上。客户关心的是整体的从概念到盈利的周期时间和流程，而不是单个步骤，而且局部优化某一个部分几乎总是会对整体优化产生负面影响。

经验性过程控制——持续检验并调整产品、过程、行为、组织设计和实践，使其以适合当时环境的方式发展。这样做是需要的，而不是遵循一套所谓的最佳实践，因为这样的实践忽视了具体环境，使后续活动变成了某种仪式，阻碍了学习和变革，压制了人们的参与感和主人翁感。

排队论——了解排队系统在研发领域的行为，并将这些洞察应用于管理队列大小、队列数上限、多任务处理，以及可变因素等。

2.1.4 两个框架：LeSS和巨型LeSS

大规模Scrum有两个框架：

❑LeSS,2～8个团队

❑巨型LeSS,8个以上团队

LeSS这个词主要指常规的大规模Scrum和小型LeSS框架。

魔术数字8

事实上，8并不是一个神奇的数字，如果一个组织能够成功地在超过8个团队中应用小型LeSS框架，那太棒了！但我们还没见过……当然这只是一个从经验上观测得到的上限。在某些情况下，比如多地点、缺乏外语经验且目标复杂的团队，团队数确实应该少于8个。

不论哪种情况，有时总会出现以下临界点：（1）单独一个产品负责人不再能掌控整个产品的目标；（2）产品负责人无法在外部和内部重点之间做出平衡；（3）产品待办事项列表过于庞大，单独一人难以胜任。

当团体达到这个临界点时，就应该考虑从小型LeSS框架转变为巨型LeSS框架。另一方面，我们建议最好先变得更好、更小、更简单，然后再变得更大。

两种框架的共同点

LeSS框架和巨型LeSS框架有着一些共同的要素：

❑一个产品负责人和一个产品待办事项列表

❑一个跨所有团队的共同Sprint

❑一个可交付的产品增量

本章的以下两部分将分别解释这两个框架；先是小型LeSS框架，接着是巨型LeSS框架。

2.2 LeSS框架

2.2.1 LeSS框架概述

小型LeSS框架适用于一个（并且只有一个）产品负责人，该角色负责该产品，并且在共同的Sprint中管理团队的一个产品待办事项列表，为整体产品的交付不断优化。LeSS框架中的元素与单团队Scrum大致相同：

角色——1个产品负责人，2到8个团队，每1到3个团队1个Scrum Master。关键的一点是，这些团队都是特性团队——真正的跨功能和跨组件的全面型团队，他们在代码共享的环境中协同工作，每个团队都竭尽全力实现既定的要完成的条目。

工件——每个团队都有一个潜在的可交付产品增量、一个产品待办事项列表和一个单独的Sprint待办事项列表。

事件——整个产品的一个共同Sprint；共同的Sprint针对所有团队，并以完成潜在可交付产品增量结束。细节将在接下来的故事以及单独的章节中进行说明。

规则和指南——基于经验性过程控制和整体产品聚焦原则的简单扩展框架所支持的规则。指南可能会很有用。

2.2.2 LeSS故事

学习LeSS——阅读具有深度的论述是诸多学习方法中的一种，喜欢这种学习方式的读者可以跳到介绍巨型LeSS框架的那一节，然后再跳到后面的章节。其他喜欢通过故事来学习的人请继续阅读。

简单的故事——这些故事并不探究我们在咨询时经历过的大规模开发的复杂性，也不探究从政治到优先级等方面的内容。故事的匣子将会在后面的章节中打开。这里的故事简单明了，旨在介绍LeSS Sprint的基本知识。如果读者想看惊心动魄的对话和戏剧，那就读读讨论“精益”的图书。

规则和指南——在故事旁边列出了相关的LeSS规则和指南，这样就把规则/指南和故事关联了起来，有助于读者理解。

两个角度——下面是两个具有关联性的故事，同时侧重两个关键的角度，以方便简要地介绍一些流程：

1. LeSS Sprint过程中团队的工作流。

2．以客户为中心的功能条目的工作流。

2.2.3 LeSS故事：团队的流动

这个故事关注的是团队在Sprint中的工作流，而不是条目的工作流。实际上，Sprint中的大部分时间是用在开发任务上的，而不是会议上。然而，这个故事强调了会议和互动，其目标是了解多个团队如何在LeSS事件中一起工作，以及他们每天都是如何协调的。

马克走进交易团队的工作室，一看见米拉，便听她说道：“早上好！提醒大家一下，我们团队是这个Sprint的团队代表，Sprint计划第一部分会议在10分钟后开始。”“对”，马克回道，“大房间见。”

提示：每个Sprint轮换一次团队代表。

Sprint计划一

到制定共同Sprint计划一的时间了。大房间里坐着来自该产品组5个团队的10名团队代表。他们都参与了一个交易债券和衍生品旗舰产品的开发。交易与利润团队的Scrum Master山姆也在场。他的任务是观察并根据具体情况进行指导。

规则：只有一个产品级Sprint，并非每个团队都有一个不同的Sprint。

早些时候，所有团队中的每一个人都参加Sprint计划一。当产品组不太善于准备和弄清工作条目，也不善于建立跨团队知识体系时，这种方法比较有用。那时，Sprint计划一要确定很多重要问题。但是最近这种情况有了很大的改善，于是这个小组开始尝试轮换代表的做法。这种做法使会议变得简单而快速，因为通常只会有几个小问题出现。如果新的方法运行不佳，那么它可能会在一个全体回顾会议上被提出来，并为此在Sprint计划中创建一个试验项。

保罗走进来说：“大家好！”保罗是产品负责人，也是主要产品经理。他在一张桌子上放了22张卡片，说道：“这里有一些主题，都很重要：德国市场、订单管理和监管报告。我已按我认为的优先顺序排好了序。我想在座的每位都能理解为什么这些是优先事项，因为我们在进行产品待办事项列表梳理时已经讨论了很多次。但如果还不清楚，请再问一次。”

规则：Sprint计划由两部分组成：Sprint计划一由所有团队共同制定，而Sprint计划二通常由各个团队各自制定。多个团队可以在一个共享空间中为紧密相关的条目一起制定Sprint计划二。

米拉和马克一起走到其他代表的桌前，挑选了两张与德国市场债券有关的条目卡片。在过去的两个Sprint中，他们的团队在单团队产品待办事项列表梳理（PBR）研讨会上已经仔细地澄清了这些条目。

规则：Sprint计划一需要产品负责人和团队或团队代表参加。他们一起试探性地选择每个团队在该Sprint中要做的条目。

他们还挑选了两个与订单管理相关的条目，交易团队和利润团队对它们都很清楚。这两个团队曾在多团队PBR研讨会中一起讨论过这两个条目。为什么现在又要让他们来做呢？当时团队希望尽可能晚地在未来的Sprint计划中作出“团队到条目”的选择。这样可以提高团队的敏捷性——易于应对变化——并且使他们对整体产品的知识越来越广泛，从而进一步促进自组织协调（参见11.1.4节）。

提示：由团队选择他们要做的条目。

一分钟后，来自利润团队的玛丽看了一眼另一个团队的卡片，问他们的代表：“你介意我们做这个吗？我们在上一个Sprint中做的事情与这个非常相似，我敢打赌我们能很快完成。你愿意换这个德国市场条目吗？”他们同意了。

提示：不要预先为团队划分条目。

几分钟后，团队根据他们的兴趣、优势，以及对相关条目进行分组的愿望来选择和交换工作条目。

山姆（Scrum Master）说：“我注意到利润团队有4个条目，并且优先级最靠前。会有问题吗？”随后进行了快速讨论，小组意识到，如果利润团队进展不顺利，产品的某一个最优先条目可能会完不成。因此，他们决定把一些具有最高优先级的条目分配给多个团队（根据哪些团队对哪些条目了解得更多），从而保证最重要的条目更可能按时完成（参见6.1.3节）。

提示：分散高优先级条目。

代表们总共挑选了18张卡片，剩下了4个优先级最低的条目。保罗查看这几个没有被选的条目卡，并拿起其中两张，说：“这两张在这个Sprint对我非常重要。也许我应该给它们更高的优先级，但我当时没有这么做，现在我想改变主意。让我们想想办法，把它们与你们已经选择的条目交换一下。当然，如果哪个团队运气好，完成得快，到时他们也可以挑选这些还没有被选上的条目。”

这个问题得到解决后，保罗说道：“好吧，让我们花点时间总结一下那些不得不看的问题。大家知道，我一直在集中精力确定优先级，而且大多数人对这些条目的细节了解得比我多，所以让我们看看可以一起做些什么来清理一下不太重要的事情。”

规则：团队识别一起协作的机会，并澄清最终的问题。

与此同时，米拉、马克和其他人还在努力思考最后一些小问题，为他们即将开发的条目做准备，并在房间四周墙上的挂纸上写下一些问题。保罗在房间里走来走去，与不同的人进行讨论。计划会议上人人都有贡献。大约30分钟后，所有小问题都已回答完毕。

提示：分散便于澄清。

这一组人站成一个圆圈来总结并结束这次会议。没有人提出任何需要协调的事项，所以山姆最后说道：“我看到交易团队、利润团队和非衍生品团队已经得到了一些密切相关的订单管理条目。”米拉说：“嘿，那让我们把交易团队、利润团队和非衍生品团队放在一起来作为多团队Sprint计划二吧。我们有机会一起工作了。”所有人都没有意见。会议结束。

团队和多团队Sprint计划二

中间休息了一会儿后，五个团队中有两个团队举行了各自团队Sprint计划二的会议，以创建自己的Sprint待办事项列表，为自己在该Sprint的工作做设计和计划。

规则：每个团队都有自己的Sprint待办事项列表。

相比之下，交易团队、利润团队和非衍生品团队聚在一个大房间共同举行两个团队的Sprint计划二会议，因为他们将要实现的条目具有强相关性——他们在以前的多团队PBR中也一起澄清过这些条目——并且他们预见了密切合作的价值。

规则：多个团队可以在一个共享空间中为紧密相关的条目一起制定Sprint计划二。

他们花了10分钟一起讨论和确定共同的工作（共同的任务），并找出了设计的问题。然后开始了一个30分钟固定时长的设计会议，大家同意采用可视化会议方式：在白板上多画草图。在此期间，还发现有更多的工作可共享，并将其一一写在白板上。

提示：全组设计与共享工作会议。

叮！30分钟到了，仍有许多细节未被探索到，但是团队希望继续，于是各个团队分散到大房间的不同角落，继续各自的Sprint计划二，更进一步地讨论详细设计问题，并创建自己的Sprint待办事项列表卡片。进一步协调时采用“叫喊”（just scream）技巧，是LeSS中“交谈”（just talk）技巧的一种先进变体（参见12.1.4节）。

在谈话过程中，团队意识到需要举办一个深入的多团队设计研讨会，并同意在当天晚些时候举行（参见13.1.2节）。

多团队设计研讨会

经过前面的Sprint计划，并做了短暂的休息之后，交易团队的米拉和马克，以及来自利润团队和非衍生品团队的几个人一起举办了一个时间箱式的为期一小时的多团队设计研讨会，更深入地探讨了大家都存在的一些常见设计问题，这样可以确保他们的开发工作能够更顺利地进行。大家站在一个大型白板周围，一起勾画和讨论设计方法和常见的技术任务，使其变得更为清晰和一致。幸运的是，讨论的结果并没有严重影响他们现有的Sprint计划，不过他们对项目的流程感到不太满意，因为他们意识到，他们早该预测到这些大的设计问题需要尽早解决的必要性。

需要协调和不断交付的开发活动

在Sprint计划完成之后，团队开始开发已确定的条目，团队强调通过代码进行交流（参见13.1.4节）。所有团队都在不断地集成代码。在对所有团队的所有代码进行持续集成的过程中，通过检查其他人在开发组件中的变更来为各团队创造合作的机会（参见13.1.5节）。这是很有用的一件事，因为小组能够通过代码集成的方式通知和支持与其他团队或其他人员的协调。

例如，在Sprint的第二天一早，交易团队的开发人员马克就可以在本地提取最新版本，并快速检查与他们正在开发的组件相关的最新变更。他发现利润团队的马克西米兰添加了一些新代码，但他知道马克西米兰所在的团队正在开发与自己密切相关的条目，所以并没有感到惊讶。代码中有信息表明需要尽快协调，并给出了需要交谈的人的名字，于是他立即走到大厅那边的利润团队跟前，与他们交谈如何共同努力来从彼此的工作中获益。

规则：建议非集中式和非正式的协调而不是集中式协调。

不光对交易团队的条目，实际上对每个团队中的每个条目，他们在开始开发解决方案代码之前都编写了自动验收测试用例。因此，除了持续集成代码之外，他们还集成自动化测试用例。这些验收测试会由团队成员频繁运行，因此当其中任何一个失败时，团队就会立即被通知去协调。代码会告诉他们，“嘿！出问题了！你需要讲讲是什么问题，并把它解决掉”。

当然，团队的持续集成、自动化测试以及构建中断时的停止和修复还带来另外一个主要好处，那就是，他们的产品或多或少地持续保持着一种立即可以进入生产环境的状态。可以看到，并不需要单独设立集成团队或测试团队，因为那样做的话反而会产生延迟，增加切换开销和过程的复杂性。

规则：完美的目标是通过改进“完成”的定义，在每个Sprint中（或者更频繁地）产出可交付的产品。

全体回顾

在该Sprint的第二天，山姆和其他Scrum Master、产品负责人保罗、部门经理以及大多数团队的代表聚在一起，对上一个Sprint进行了一次时间上线设为90分钟的全体回顾会议。

为什么他们不在新Sprint开始之前举行上一个Sprint全面回顾会议呢？本来是可以的，但Sprint通常在周五结束，新的Sprint在周一开始（山姆的建议则是Sprint结束和开始的边界为周三和周四）。并且在上周五，他们举行了Sprint评审和团队级回顾两个会议，若要在那天结束时再举行一次全体回顾会议，人们恐怕就没有精力了。所以他们选择在下一个Sprint开始时举行全体回顾会议。山姆个人对这种拖后的做法持不同意见——他宁愿Sprint计划晚些开始，也应把它放在全体回顾会议之后——但他希望大家都能慢慢认识到这一点。

规则：在团队各自回顾之后举行一次全体回顾，以讨论跨团队和全系统范围内的问题，并建立起改进试验。出席会议的人应包括产品负责人、Scrum Master、团队代表和经理（如果有这样的角色）。

他们在关注一个全系统范围的问题，即整个小组内如何在Sprint阶段开展协调、共享信息和解决问题？应该如何对此进行改进？以前他们尝试过Scrum of Scrum会议，但发现这种会议不是非常有效。山姆介绍了开放空间的技巧，大家同意在这次Sprint中做一次尝试（参见14.1.5节）。

协调活动

第四天出现了LeSS中的各种协调想法。

和常规的Scrum方法一样，在LeSS中，每个团队每天都有一个Scrum会议。为了支持交易团队和利润团队之间的协调，米拉作为一名侦察员来观察利润团队的日常Scrum，然后把她所学的知识带回到自己的团队。反过来，来自利润团队的某个成员也做同样的事情（参见14.1.3节）。

规则：如何进行跨团队协调由团队们来决定。

正如在全体回顾中所商定的，小组需要举行一次45分钟的开放空间会议，以进行协调和学习，之后便进入饮料和零食时间。山姆作为开发空间会议主持人在会中指导小组如何举行开放空间会议。会议欢迎每个人参加，但大多数团队只会派出几名代表。来自交易团队的米拉和马克加入了会议，会议决定小组可以尝试每周举行一次开放空间会议（参见13.1.11节）。

来自多个团队的测试社区志愿者聚集在一起，用了半个小时的时间来听取玛丽关于试用一个新自动化验收测试工具的建议。大家对这个建议表示赞同，于是玛丽主动让她的利润团队在下一Sprint中来做实际的试验工作，他们对这一技术兴趣盎然（参见13.1.6节）。

提示：建立架构社区。

米拉是设计/架构社区成员之一。在这个Sprint中没有针对整体架构的设计研讨会，但她希望在下一个Sprint中能保留半天的刺探（Spike）时间，专门讨论一些新技术。她将自己的想法发布在社区协作工具上，并建议采用Mob编程方式一起进行讨论，以便大家相互分享和共同学习。

构建系统报告了一个奇怪的错误。该停止与修复了！这个Sprint由交易团队易负责，这个错误发生的地方正好是马克的次级专长之一，所以他自愿修复它，并要求另一个团队成员与他配对，这样也帮助了该同事学习更多有关知识。

随后，米拉和其他一些团队成员走访了客户支持和培训组，这两个小组与实际用户合作密切。团队的第一个条目已经完成了，他们希望能从接近客户的这些人中尽早得到反馈。其中一个培训人员正好有空，而且他在玩这个条目对应的新功能，在使用过程中他产生了几个新的想法，并反馈给了交易团队，留给他们对该功能做进一步的改进。

当天晚些时候，马克和其他团队成员开始开发第二个条目中的任务。马克刚刚完成10分钟的TDD，并且在做了微小的变更后得到了一段干净稳定的代码（参见13.1.4节）。他再次（大约每10分钟）将微小的变更推送到中央共享存储库（repository）中，以便与他的团队和所有其他人持续集成（参见13.1.5节）。他看了看墙上的红绿大屏幕，发现构建系统已通过了整个团队的所有测试。

总体产品待办事项列表（PBR）梳理

第五天，马克和米拉参加了一个全体PBR研讨会，与会者还有来自每个团队的代表，以及产品负责人保罗。保罗首先给大家分享了他目前对产品方向和下一步要做什么的想法，以及最重要的一点，即支持他这些想法的原因。为了帮助大家理解其推理内容，他与小组一起回顾了他的优先级模型，以及其中的利润影响、客户影响、业务风险、技术风险、延迟成本等因素（参见8.1.5节）。

为了指导小组下一步的工作，保罗向大家征求反馈意见和想法，接着，小组讨论了下一步需要梳理的条目。虽然保罗知道自己最后会给条目定出优先顺序，但他还是努力让团队先了解他的想法，同时他也可以学习团队成员的想法。他希望团队也能像自己一样拥有产品主人的感觉（参见8.1.8节）。

然后，小组拆分了几个新的大型条目，做了一些轻量级澄清讨论（更多澄清工作会在稍后进行），用计划扑克进行了评估，以此了解这些条目的更多信息，所以这不仅仅是为了评估（参见11.1.7节和11.1.8节）。

提示：产品负责人鼓励团队对产品负责。

来自三个团队（其中包括贸易团队和利润团队）的代表后来决定对一些条目一起进行一次多团队PBR，增加他们对这些条目的共同理解，因为这些条目具有很强的相关性。来自另外两个团队的代表在团队PBR会议中分别选择了各自要处理的条目。

多团队PBR与团队PBR

第六天，这三个团队的所有成员聚在一个大房间内开始做多团队PBR。

虽然他们的主要业务是创建和销售交易解决方案，但该公司拥有一小部分债券交易员在使用该解决方案，公司仅仅是为了保持他们自己有人参与，所以头寸相对较小，风险不高。通过这种方式，公司可以更好地了解市场趋势，同时可以保留一些专家用户以便随时且轻松地与开发团队交谈。

坦尼娅和泰德是参与交易的人员，他们告诉保罗其发现了一个趋势性变化，于是在多团队PBR会议上对与该趋势相关的条目进行了进一步的提炼，他们俩作为专家被邀请参加会议，以帮助团队学习和澄清新的条目。

另外两个团队与其他一些交易人员讨论后，举办了单独的PBR研讨会，以完成对一些已在梳理的条目的澄清工作，并开始处理一些新条目。此外，该公司三名专门从事金融监管和合规工作的律师之一加入了其中一个团队，帮助他们澄清相关的问题。

作为PBR会议的最后一步，人们对墙上和白板上的所有东西都进行了拍照。他们将照片添加到wiki页面中，用于记录与每个条目有关的所有内容。此外，他们还对讨论期间快速添加的wiki页面中的文本和表进行了更新和清理（参见9.1.6节）。

关于团队级待办事项列表和产品负责人职责的讨论

多团队PBR研讨会结束后，迈克（刚加入公司）看到山姆坐在咖啡机旁，走过去说道：“嘿，山姆。你对有些事情的意见我很感兴趣。在我们刚刚结束的梳理研讨会上，我注意到我们是直接与一些交易人员一起澄清问题。但这不是效率很低吗？我在上一家公司工作时，他们每个团队都有自己的产品负责人，产品负责人编写故事、画框架图，解释需求说明，然后交给我们实施。这样我们只需要专注在编程上。并且每个团队都有自己的产品待办事项列表，团队的产品负责人会优先考虑这些待办事项列表。但我在这里看到的不一样，为什么呢？”

山姆说：“这是个有趣的问题。介意我问你几个问题来探讨一下吗？”

“当然可以，说吧。”

“让我们首先考虑一个产品待办事项列表与多个团队级待办事项列表。假设每个团队都有自己的待办事项列表工作，一个真正的整体产品负责人如何能够简单而有效地看到全局情况？一个团队对其他不同团队的待办事项列表条目的需求和设计能了解多少？”

迈克回答说：“根据我上一个公司的经验，可以很清楚地给出答案：不多。”

山姆继续说：“现在假设有8个团队和8个团队待办事项列表。如果从公司高层或整体产品角度来看，由于某种原因，8个团队的2个待办事项列表中的条目变成了最重要或优先级最高的条目，这时该怎么办呢？出现这种情况也许是由于市场发生了变化。因此，你需要回答一些问题：在低优先级待办事项列表中工作的6个团队能否轻松地转移到其他两个待办事项列表中的高优先级条目上呢？而且，考虑到每个团队都有自己的待办事项列表工作和自己的优先级事项，小组能注意到这个问题吗？”

迈克回答说：“我以前公司的团队只处理他们自己的团队待办事项列表条目，不能转移给其他人。但是咱们团队为什么要这样做呢？这不是效率很低吗？”

山姆回答说：“从公司的角度来看，团队是一个只在低优先级事项上‘高效’工作的群体，这是因为他们各自专注于不同的团队待办事项列表工作，故而会产生知识上的狭隘性，也因为总体优先级和项目总体情况对他们不可见。让我来问你几个问题：这看起来不灵活还是像敏捷一样灵活？从公司的角度来看，这样做能否起到优化作用，让人们只处理影响最大的事情呢？”

迈克停顿了一下：“哦！我想我明白了。尽管我们的团队说自己在做敏捷，但这实际上不敏捷。总体而言，我们对最高价值的变化没有足够快的响应。我以前的团队产品负责人说，她总是优先考虑我们团队待办事项列表的最高价值事项。但现在发觉，当从更高的层次来看时，团队正在忙着高效处理的可能是低价值的东西。”

规则：一个完整的可交付产品只对应一个产品负责人和一个产品待办事项列表。

山姆说：“没错。这就是我们只有一个产品待办事项列表，而很多团队没有团队待办事项列表的原因之一。简而言之，产品待办事项列表支持整体产品聚焦、系统优化和敏捷性。当然，这样就能很简单，也很容易地看到整个团队的情况。”

“而且，”迈克评论道，“我注意到在我之前的公司里，所有的团队很难同时协作，因为在异步的Sprint中各自的工作目标非常不同。而在这里，可以感觉到所有团队在一次Sprint中有着更多的共同焦点和方向。”

“没错！”山姆回答，然后继续说道。

“还有另外一个问题：如果只有一个产品待办事项列表和一个产品负责人，但每个团队仍然有自己所谓的产品负责人，根据定义，他们不会对团队待办事项列表进行优先级排序，那么这些团队级产品负责人整天都在做什么呢？”

迈克回答说：“在我的上一家公司，团队级产品负责人的工作是与用户交谈并为团队编写故事，这样团队级产品负责人一边收集和编写需求，团队一边专注而高效地编程。”

规则：产品负责人不应独自处理产品待办事项列表梳理工作，而应鼓励多个团队与客户/用户及其他利益相关者直接合作，并从中获得支持。

山姆问：“迈克，在你了解Scrum术语（如‘产品负责人’）之前，你会把开发人员和真正的客户之间的中间人称作什么？他们收集需求，然后将其提供给开发人员？”

“我加入上一家公司时，公司还没有采用Scrum。”迈克回答道，“那时候，有一群业务分析师，由他们承担这样的角色。在采用Scrum之后，这些人成为产品负责人。”“在你们今天的PBR研讨会上”山姆问，“你和在场的交易员谈过吗？”

规则：所有优先级顺序都由产品负责人确定，但优先级的澄清工作应尽可能直接在团队、客户/用户和其他利益相关者之间进行。

“让我想想。”迈克回答：“是的，我和坦尼娅讨论过她分析俄罗斯公司债券交易的想法。这看起来有点混乱，所以我问她为什么，她解释说，这是因为对海外账户洗钱有所担忧。其实，她不知道我们组最近正在研究一些其他的功能，这些功能可以与欧盟和美国新的监管数据库相结合来评估上面所担忧的问题。因此，我向她建议了一种不同的方法，我认为——她也同意——这种方法能更好地解决这个问题。”

“现在我认为，”他深思着，接着说道，“在我的上一家公司可能不会发生这样的事情，因为我们很少直接与用户交谈。”

持续开发

一天接着一天，团队开发代码，并结合全面的测试自动化不断地持续集成。当构建中断时，停止并修复，他们正在努力实现团队的完美目标，即拥有一个可以持续交付给客户的产品。照此发展，当Sprint即将结束并且团队准备开始Sprint评审时，不会出现开发后期匆忙和疯狂地集成和测试大批代码的现象，因为代码一直都在集成和测试。

Sprint评审

终于来到了最后一天，也是最后一次全体人员参加Sprint评审的时间。都有谁参加这个会议呢？保罗（产品负责人、主要产品经理）、所有的国际债券交易员、几名培训员和客户服务代表、几名销售人员，以及客户方的4名用户。客户支付较低的年费率，以便为他们的用户换取定期参加这些评审的机会。除此之外，还有所有的团队成员。

规则：有一个产品级Sprint评审，是所有团队共同的。

因为有很多条目需要审查，所以团队先举行了一个一小时的评审活动，就像科学博览会一样，房间里摆有很多设备，每个设备都可帮助人们探索不同的条目（参见14.1.3节）。一些团队成员留在固定的区域收集反馈，而其他人员则在使用和讨论新功能。

提示：讨论下一步Sprint的方向。

一小时后，保罗召集大家在一起，共同讨论问题并提供反馈。之后，又讨论了未来的发展方向。保罗分享了市场和竞争对手的情况，以及他对下一步行动的想法，并征求大家的意见。

团队回顾会

休息了一会儿后，交易团队（和所有其他团队）进行了单独的团队级Sprint回顾。他们认为，这一次，把多团队设计研讨会放在Sprint计划之后（而不是更早）举办不太理想，因为一些重大问题直到最后一刻才被发现，而这些问题可能会严重阻碍开发或使开发变得复杂。因此，在下一个Sprint中，他们决定在PBR会议期间将尽最大努力识别出那些可能存在重大设计问题并需要与其他团队讨论的条目。并且如果是这样，就要尽快举办多团队设计研讨会。

规则：每个团队都有自己的Sprint回顾。

结束

Sprint完成！山姆邀请交易团队与米拉和他一起到街对面的比利时啤酒酒吧庆祝米拉的生日。

总结

故事中的一些要点如下：

❑它强调了LeSS中人员和团队在Sprint中的流动。

❑它将故事中的元素与特定的LeSS规则联系了起来。

❑对于已了解Scrum的读者来说，故事中发生的事件应该是很熟悉的。

❑这个故事展示了整体产品聚焦的思想，即使有很多团队参与开发也是如此。

❑多项活动强调了基于团队的学习和协调。

❑通过持续集成来开发项目，有了这一点，就可以通过代码交流来支持分散式协调和谈话式的交流，进而支持持续交付。

❑团队直接与用户和客户进行交互以澄清需求，从而减少切换开销，增进相互理解、同理心和所有权。

2.2.4 LeSS故事：功能条目的流动

这个故事更多地关注于在梳理和开发期间功能条目在Sprint局部的流动。

与政府监管机构人员的会面结束后，波西亚立即赶往机场，奔赴在回家的路上。她是另一个产品的产品经理；她帮助保罗专门研究监管和审计事宜。

办公室里，波西亚见到了保罗。她拿出五张卡片，卡片写的是她总结的一些将会对产品产生影响的新规则，以及她认为客户首先需要的一些功能。保罗指着卡片问道：“就你所知，这涵盖了所有的工作，对吗？”波西亚微笑着说：“这是监管内容。它从来没有结束的时候。”

保罗问：“你能不能把这些放在我的产品待办事项列表中，暂时放在最下面，先不排序？”（参见8.1.7节）

“没问题。”

一周后，保罗告诉波西亚：“我想尽快给大家介绍债券衍生品的一些重要监管要求。在下一个Sprint的产品待办事项列表梳理研讨会中，我会要求一些团队来关注一下这些监管事项（参见9.1.6节）。你最了解它，所以请你参加整体PBR。至于其他任何团队梳理研讨会，如果他们希望你参加的话，请你也参加。此外，你能否设置一个wiki页面，放置一些指向新监管文档的链接，共享给团队？”“已经做完了”，波西亚回答道。

提示：大量产品待办事项列表的电子表格和wiki。

总体PBR

保罗启动了一个简短的总体PBR研讨会：“关于新法规，我们有很多工作要做。我们很快就需要交付相关的条目，因为法定的最后期限是财政年度结束。经过初步的条目划分和评估，我们便会心中有数了，但如果最终需要三个或更多的团队来实施，而且要花较长的时间来完成，我也不会感到惊讶。”（参见11.1.2节）

小组把这个巨型新条目拆分成几大部分，开始学习其中的主要内容。更多拆分稍后会在单团队或多团队PBR会议中进行。波西亚走到白板前，在白板左边写道“债券衍生品的规定”。然后开始与小组交谈，他们一边交谈，一边绘制一个树形图，用四个树枝表示四个主要子条目。但是他们没有深入研究——避免过度分析（参见11.1.8节）。

接下来，小组为新条目创建了四张卡片，每个人都使用计划扑克（planning poker）和相对大小点数对其进行估算，并把产品待办事项列表中已有的知名条目的点数作为基准。这里主要目标不是要估出点数，而是要让问题浮出水面，以推动更多的讨论，这件事是由他们与波西亚一起来做的（参见8.1.7节）。

接下来，保罗问：“波西亚，这四个大条目中，哪个优先级最高？”

她指着第二张卡片，“场外交易的外来债券衍生品。”

保罗说：“有个功能我们需要尽快完成和交付。产品待办事项列表因为这个功能正在变长。所以我想让一个团队在下一个Sprint开始时开发这个功能。哪个团队有兴趣？”

交易团队自愿接受了这个任务。

最后，来自其他三个团队的成员决定为相关条目举办一次多团队PBR研讨会。

团队PBR：大型条目的切分

第二天交易团队与波西亚一起举办了团队PBR研讨会。四个巨大条目，他们承担了其中一个：场外交易（OTC）的外来债券衍生品的新规定。山姆（他们的Scrum Master）也在那里。波西亚说：“这是一个巨大且复杂的条目，坦率地说，没有人真正了解这个领域。我们需要花较长的时间才能把它分解开，真正理解它，并做出需求说明。”

山姆问：“我们真的需要了解所有的东西吗？分析能让我们多学些东西，还是会拖延我们的学习？”

山姆和大家一起回顾了“切分出小功能块”的想法：从一个条目中分割出一个小功能块，然后真正理解并快速实现它。山姆总结道：“大家知道，图表和文档不是代码，图表不会崩溃，文档也不会运行。”（参见9.1.3节）

在波西亚的帮助下，团队从一个以客户为中心的瘦“端到端”条目中分出了一个细小的功能块。

从现在起，他们开始把注意力集中在这一小功能块上，理清并实现它。只有在实现和得到反馈之后，他们才会在晚些时候回过头来更进一步地

分割和细化。通过实例化需求，波西亚和交易团队在当天余下的时间里一直都在处理自己的这一块功能。

提示：参考《实例化需求》。

多团队PBR：轮换梳理

整体PBR的一个结果是决定让交易团队实现切分出的小功能块。另一项决定是由三个团队为相关条目举办一次多团队PBR研讨会（如图2-1所示），以提高多个团队一起学习和思考相同条目的敏捷性（参见11.1.5节）。

除了来自这三个团队的所有成员，内部交易员坦尼娅、泰德和特拉维斯也加入进来，帮助团队澄清大约有一打的新条目。

首先，他们与每个团队的成员组成三个临时混合小组。接着，混合小组在房间的不同区域开始清理不同的条目，每个区域都配有白板、大墙空间、笔记本电脑和投影仪。坦尼娅、泰德和特拉维斯分别在第一组、第二组和第三组。

然后他们开始轮换梳理：30分钟后，计时器到点！一个小组走到另一个组所在的区域，反之亦然，但坦尼娅、泰德和特拉维斯保持不动。计时器重新启动，交易员们向轮换进来的团队解释最新的情况，接着大家继续清理。

在一整天的时间里，随着不同的条目变得越来越清晰——或者留下悬而未决、不得不在以后进行探讨的问题——新条目被不断地引入到工作区域中。一些较大的条目被分成了两个或三个新的较小的条目。

小组会在一天中停止几次澄清工作，而做一些估算，主要是为了学习和促进交流。他们使用相对（故事）点的方法来做估算；为了保持与公共基线的同步，他们根据产品待办事项列表中的一些已经完成并且众所周知的条目来对相对点进行校准（参见11.1.8节）。

更新产品待办事项列表，向产品负责人汇报最新进展

PBR研讨会后的第一天，波西亚和几个团队成员（参见8.1.7节和9.1.4节）：

❑使用从原始条目中新拆分出的条目来更新产品待办事项列表，并删除原始条目。

❑创建新的wiki页面，在其中添加链接，指向PBR研讨会中创建的条目的详细内容。

❑记录新的估算值，准备要实现的条目。

随后，波西亚和这些团队成员与保罗会面，审查产品待办事项列表的变化，并回答保罗提出的一些问题。

结束

故事中的一些要点：

❑从巨大条目上切分出小功能块，从交付小功能块中学习，避免过早和过度的分析。

❑为了条目，以及团队间的知识共享，执行多团队PBR，这可以提高组织的敏捷性，拓宽整个产品知识，并促进自组织协调。

❑即使与许多团队一起合作，也要努力践行整体产品聚焦的思想。

下一步——下一节将描述适用于由许多团队组成的大型团体的巨型LeSS框架。

2.3 巨型LeSS框架

2.3.1 需求领域

不论是有1000人的产品开发，还是只有100人的产品开发，由于大量需求的复杂性以及人员的复杂性，分而治之似乎是不可避免的。传统的大规模开发按如下方式划分：

❑单一职能组（分析组、测试组，……）

❑体系结构层面的组件组（UI层组、服务器端组、数据访问组件组，……）

这种组织设计使开发变得缓慢而不灵活，表现为高水平的浪费（库存、在制品、交接、信息传播，……），长延迟的ROI，复杂的规划和协调，更多的间接费用管理，以及弱反馈和弱学习。这种组织方式是向内围绕单一技能、体系结构和管理模式设计的，而不是向外围绕客户价值设计的。

但是，在巨型LeSS框架中，当超过大约8个团队时，组织划分需要围绕客户关注的主要领域（即需求领域）来进行。这反映了LeSS以客户为中心的原则。

规模——需求领域很大，参与的团队通常有4到8个，而不只是1个或2个。后面的2.3.3节将解释其原因。

动态性——需求领域是动态的。随着时间的推移，一个领域的重要性会发生变化，然后随着团队加入或离开一个领域（主要是现存领域），该领域会增长或缩小。

示例——例如，在证券产品（股票交易）中，以下可能是客户感兴趣的一些主要需求领域：

❑交易处理（从定价到捕捉，再到结算）

❑资产服务（例如处理股票分割、股息）

❑新市场启动（例如尼日利亚）

概念上是在一个产品待办事项列表中添加一个需求领域属性，然后把每个条目归类到一个且仅一个需求领域：

然后，人们可以关注一个领域产品待办事项列表（概念上是一个产品待办事项列表的视图），例如市场启动领域：

共同Sprint——是否每个需求领域都在各自的Sprint中单独工作，并且延迟到很晚的时候做集成？不是这样。

2.3.2 领域产品负责人

在巨型LeSS中引入了一个新角色。每个需求领域都有一个领域产品负责人，专门负责该领域的产品待办事项列表工作。

大型产品组通常有几个专门负责不同客户领域的产品支持经理，其中一些人可以担任领域产品负责人。有时，总体产品负责人还可以兼任某一个领域的领域产品负责人；这种情况更有可能发生在不太巨大的巨型LeSS组织中！

2.3.3 领域特性团队

领域特性团队在一个需求领域（例如资产服务）内工作，一个领域产品负责人专注于一个领域产品待办事项列表中的条目。从团队的角度来看，在一个领域中工作就像在一个小型LeSS框架中工作一样——他们与领域产品负责人积极互动，就像她是总体产品负责人一样，依此类推。

团队成员对该客户领域非常了解。并且幸运的是，一个需求领域的条目在整个代码库中对应的子集往往几乎可以推测到，这样就能缩小团队成员在庞大的产品中必须学习的范围。

关于规模大小有一个关键点：一个需求领域一定有许多特性团队在其上工作。

魔术数字4

首先，为什么一个需求领域建议的上限是8个团队呢？请参见“魔术数字8”这一小节。

建议下限为4个团队，而不是1个或2个团队，这又是为什么呢？当然，4不是一个神奇数，但它确实可以实现一个均衡，因此产品组不必包括许多个过于微小的需求领域。

那么，包括许多个过于微小的领域会有什么问题呢？它们会降低对总体产品级别优先级的可见性，增强局部优化，增加协调复杂性，需要更多的职位来填充，并且创建过于专门化的团队，该团队缺乏灵活性（敏捷性），无法从公司的角度处理新出现的最高价值条目。此外，当领域很小时，领域产品负责人在用户和一两个团队之间充当业务分析师角色的可能性就会增加。

下限4是否可以有合理的例外呢？是的：

❑在LeSS转型早期，团体正在逐步扩大一个新的领域，预计最终将需要4个或4个以上的团队。这时，可以从一个小而简单的团队开始。

❑当一个需求领域的需求不断减少，而另一个需求领域的需求不断增加时，为了重新平衡团队，一个领域会从4个团队变为3个团队。最终，将两个缩小的小领域合并为一个新的较大领域。

需求领域和团队示例

总结起来证券产品可以具有：

❑1个产品负责人和3个领域产品负责人，一起构成产品负责人团队

❑6个交易处理领域特性团队

❑4个市场启动领域特性团队

❑4个资产服务领域特性团队

2.3.4 巨型LeSS框架概要

每个需求领域就是一个（小型框架）LeSS实现，各个需求领域按照共同Sprint并行工作。我们有时将巨型Less中的Sprint总结为一堆Less。

与LeSS一样，巨型LeSS同样有规则和可选的指南；这些内容将在下面的故事中加以介绍，并在后面的章节中进行详述。

角色——与LeSS相同，再加上两个或多个领域产品负责人，以及每个需求领域中的4到8个团队。产品负责人（专注于整体产品优化）和多个领域产品负责人组成了产品负责人团队。

工件——与LeSS相同，再加上一个产品待办事项列表中的需求领域属性，因此每个领域都有一个领域产品待办事项列表视图。

事件——仍然只存在一个产品级共同的Sprint；它包括在共同Sprint上工作的所有团队，它结束于一个共同的潜在可交付产品增量。

2.3.5 巨型LeSS故事

学习巨型LeSS——喜欢正式讲解的读者可以绕过这些故事自由地跳到后面的章节。

简单的故事——这些都是有意简化的故事，目的只是为了介绍巨型LeSS的基础知识。

两个主题——以下是两个主题不同的故事：

1．全新且巨大的需求，创建和扩展新的需求领域。

2．与多地点团队合作。（这种情况也发生在小型LeSS框架中，但在巨型LeSS框架中尤其常见。）

2.3.6 巨型LeSS故事：新的需求领域

普丽蒂欢迎波西亚度过了她在新职位上的第一天。作为大型交易公司证券部的中层运营经理以及内部证券系统的产品负责人，普丽蒂同时还肩负着为其领域产品负责人所在的产品负责人团队寻找和留住人才的重任。她认为波西亚是一个极其出色的人才，因为她的专业知识正是处理新的巨型需求所需要的（参见8.2.2节）。

波西亚的上一家公司是债券交易系统开发公司，她当时担任产品经理的职务，专门处理公司的监管问题。在波西亚面试目前这家公司时，普丽蒂说明了公司现在的这一情况：“波西亚，在上一次金融危机之后，监管机构变得越来越严厉，他们要求我们遵守多德-弗兰克法案。现在，大家不知道这到底意味着什么，也不知道它对我们的系统会产生什么样的影响。你对这个领域的了解非常深入，而且还有一个很棒的监管人员专业网络。如果你能加入我们的团队，帮助我们解决这个问题，我一定会欣喜若狂的。”

突然袭击

几天后……波西亚、彼得和苏珊走进了普丽蒂的办公室。彼得是市场启动领域产品负责人，苏珊是交易处理领域的Scrum Master。

普丽蒂非常欢迎大家的到来，接着立即把话题转到正题，说道：“你们大家知道，多德-弗兰克法案真的要来了，而且来势凶猛。但你们还不知道，就在今天早上监管机构打来了电话，希望我们现在就开始行动。我一直以为我们可以明年才会开始，所以，我们现在就必须行动了，是关键时刻啊。”

“我认为没有人清楚这个要求的详细含义，甚至连监管者也不清楚。我们不知道它对我们的系统会产生怎样的影响，也不知道工作量有多大，当然一定会很大！不过现在波西亚加入了我们的团队，她比任何人都了解这一点，尽管她对我们的系统还是完全陌生的。那么，我们该如何帮助她开始处理这堆积如山的工作呢？”

苏珊问：“你们了解诵读困难症僵尸（Dyslexic Zombies）团队，对吧？”

彼得和普丽蒂点了点头。所有人都知道——不仅仅是他们的名字。诵读困难症僵尸团队可能是所有团队中拥有最广泛经验的团队。他们已经存在多年了，当他们采用LeSS时，他们真的是痛苦煎熬。该团队中的两个成员来自现在已被遗弃的架构小组，还有几个成员已经在那个系统工作超过15年了。这些人对采用LeSS非常抵制，因为他们担心会失去自己的“系统观点”。出乎他们意料的是，事情发生了反转！因为他们知识丰富，功力深厚，所以能够不断得到挑战性的开发任务。他们还经常作为专家讲师参加为新人举办的最新架构学习研讨会，而马里奥——前PowerPoint架构师之一——现在担任架构社区的协调员。这个人只有在啤酒喝到一定程度时，才会承认密切参与代码和测试工作增加了他对系统的真正理解。

苏珊继续说：“如果说有一个团队能快速帮助波西亚更好地了解多德-弗兰克法案的规模和影响，那就是僵尸团队。几年前他们领导了萨班斯-奥克斯利法案的研究。明天他们要举办PBR会议，为一个新功能收尾。我们为什么不在这个会议上，引导他们参加多德-弗兰克法案的讨论，并让他们在不久以后就集中精力把全部时间放在这件事情上呢？”

与僵尸团队一起梳理条目

第二天，在与僵尸团队一起参加的梳理会议上，波西亚解释了情况，“大家可能都听过多德-弗兰克法案。但很令人吃惊：监管机构刚刚通知我们，希望我们‘立即’采取行动，并在今年年底前明显达到合规要求。否则他们就有可能限制我们的交易。”

听到这个消息后，僵尸团队成员显然很惊讶。他们听到过一些传言，但没想到会这么匆忙！

马里奥说：“好吧，波西亚，给我们简短地总结一下，这意味着什么，多德-弗兰克法案和萨班斯-奥克斯利法案有什么不同？”

波西亚拿起笔，在白板上画了大约45分钟后，完成了一个概况图，僵尸团队成员看着，并有点目瞪口呆。

“他们说的是到年底？”马里奥说。“即使整个产品组从今天就开始，到时也无法完成。这事巨大无比！”

马里奥拿起一支笔，在白板上开始勾画他们的系统，与其他僵尸团队成员讨论系统可能受到的影响。

他说：“波西亚，让我们也利用这个机会帮你更好地理解一下这个系统。你随便问。”

波西亚说：“你能等一下吗？我来录个像，这样可以帮我记住。”

米歇尔是这个团队的一名资深成员，她说：“我们最好尽快开始一些真正的开发，并在前进中学习，否则我们到头来还是在分析。我以前见过这样的事情。”

Scrum Master苏珊说道：“我刚刚想到……Tom DeMarco曾说过，每一个失败的项目都是因为起步太晚。”大家都笑了。她继续说：“所以我的建议是：从切分出小功能块开始。”（参见9.1.3节）

创建新的需求领域

第二天，波西亚、普丽蒂和产品负责人团队的其他成员会面。波西亚概括性地分享了到目前为止她所理解的需求范围。

普丽蒂说：“这个范围比我预期的还要大，我们需要在几个月内向监管机构展示一些切实的进展，并在财政年度结束前——也就是说从现在起有7个月——展示一些重大的进展。他们现在被授权随时可以向我们提出更多的要求，并有权关闭我们的业务。正如大家所知道的，就在上个月，首席执行官曾明确表示过新的监管要求必需优先于任何其他事务。根据我的经验，如果我们能尽早给监管机构展示一些东西，并做到透明和反应灵敏，我们与监管机构打交道时的灵活性就会提高。这就是我们要做的事情。”

普丽蒂继续说：“依我看，我们需要建立一个新的需求领域来迎接这个突然袭击。当然，这可能会影响到我们现有的一些高优先级目标，因为我们必须转移一些团队。大家准备一下，一两天后我们举行一次会议，深入讨论一下该需求对整体优先级的影响。不过现在，我想先听听大家关于开辟新领域的意见。”（参见9.2.4节）

经过简短的讨论，每个人显然都认识到了创建新领域的重要性。

普丽蒂接着说：“波西亚，你是新来的，对于这件事，你认为自己能处理好领域产品负责人这个角色的责任吗？”

波西亚点了点头。

普丽蒂继续说：“彼得，你认为僵尸团队可以开始做这件事吗？他们需要学习多德-弗兰克法案知识，在更多的团队加入之前需要弄清楚该法案对我们系统的影响。”（参见13.1.15节）彼得说：“我想我们别无选择。”

普丽蒂说：“好吧，波西亚，现在我们已经从彼得的领域待办事项列表中拿到一些条目，还有那个巨型条目——你称之为“多德-弗兰克的其余部分”，以及僵尸团队和你从该巨型条目中切分出来的那个细小条目。让彼得向你演示一下如何在产品待办事项列表中设置新领域，以及如何将条目转移到该区域。”

普丽蒂继续向小组讲道：“下一个Sprint将在三天后开始。僵尸团队将会转移到你们领域，这样你们就可以开始启动这个怪兽了。也许在一两个Sprint阶段后，我们将会准备好——并且必须准备好——为你们领域增加一个团队，以加强你们的开发力量。各位，有两个主要问题，请大家考虑一下：第一，准备在几天后召开一次重要的会议，讨论优先级影响事宜。第二，还有其他哪些团队可以作为新领域优秀的候选团队。”

新需求领域的Sprint规划

每个需求领域都有自己的Sprint计划会议，而且这些会议几乎都是并行举行的。在波西亚的新领域，Sprint计划会议以她向僵尸团队成员介绍两张陌生面孔开始。

她说：“吉莉安和扎克与监管机构一直有定期的联系，他们将帮助我们把这件事具体化。他们已经同意在PBR会议期间帮助我们做计划，并且在后面的Sprint中每天都会尽可能多抽出些时间来帮助我们。”

她继续说：“下面是我对未来两个Sprint的初步突击计划。首先，我们需要一起了解多德-弗兰克法案的更多内容，并将其分解为几个主要的、容易管理的部分，这样我们才能消除迷雾，对优先事项有一个更好的认识。

“第二，从这个Sprint开始，我们要实现那个切分下来的小功能块。这将能帮助我们更好地了解有关法案的真正的工作以及对我们产品的影响。我们也会因此取得一些具体可见的进展。

“第三，我们需要做好准备，迎接更多的团队加入我们的领域。大家觉得这种方法怎么样？有没有其他建议？”

在简短的讨论过程中，马里奥对他的团队说：“最近我代表我们的团队参加了所有领域产品负责人和普丽蒂举行的产品负责人团队会议，我想就有关背景多讲一点。首先，项目开始阶段，只有我们一个团队。我们将在早期实现方面发挥主导作用，了解条目的总体情况，并理解对体系结构的总体影响。”（参见13.1.15节）

米歇尔打断道：“就像一个老虎团队开发新产品吗？”

“是的，就是这样，”马里奥说。“把我们的产品对多德-弗兰克法案的支持看作是一种新的产品，它需要不断地融合到我们产品的其余部分中去。但是由于时间匆忙，工作量大，几个Sprint过后，需要有一支团队加入我们，不久之后，可能还有另外两支团队再加入。届时，我们的开发不会中断，但我们会变成一支领头羊团队，这意味着我们需要带领其他团队跟上速度，并确保我们在引导整体产品的推进。”

米歇尔说：“听起来这就像我们将要成为一个架构和项目管理团队一样！”

马里奥笑了，“不，受够你了。我们仍然是一个常规的特性团队，但除了开发之外，我们确实需要关注和指导新团队，让他们尽快赶上。但我们要清楚：团队协调和管理仍然是每个团队的责任。”

新需求领域的第一个Sprint

第一个Sprint是一个不同寻常的过程，是在需求澄清和开发之间不断寻求平衡的过程，但这对目前这种极端情况来说相当有用。团队花了将近一半的Sprint时间与波西亚、吉莉安以及扎克交流。这是因为，即使是为了这一小块需求，试图理解政府新法规这一晦涩领域——无法直接接触政客和政策制定者——也需要大量的调查、阅读、讨论以及对外沟通（参见9.1.3节和9.2.5节）。他们预计，在未来的Sprint中，澄清所需的时间将很快减少到通常的水平，即一个Sprint时间的10%或15%。

也就是说在这个Sprint中他们只花了一半的Sprint时间来开发一个小条目。但是讨论和从编码中学习是有回报的。尽管慢了但值得肯定的是，他们能够开始分解多德-弗兰克法案了——至少分解成他们中的任何人都能理解的部分。

在实现这个首先切分下来的小条目时，他们花了很多时间讨论系统的总体设计，频繁地在代码和设计之间来回切换，理清思路。

新需求领域的Sprint评审

整个证券产品组在一个Sprint中协同工作，最终实现了一个可交付产品增量。但是每个需求领域都有自己的Sprint评审，所有评审几乎都是并行进行的。

在评审期间，波西亚、吉莉安和扎克仔细察看了僵尸团队成员实现并集成到整体产品中的一个“完成”条目。他们最初预测要完成两个条目，最终完成了一个，但波西亚对他们的成果仍印象深刻，想想看，这项新工作当时那么快就分给了他们。

第二个Sprint

在第二个Sprint中，他们再次花了很多时间与波西亚、吉莉安以及扎克一起澄清需求，条目有一定的进展，但却不尽如人意。

在Sprint进行到一半的时候，他们与即将加入该领域的第二个团队举行了一次多团队PBR会议，向他们讲授了多德-弗兰克的相关知识。然后又举办了一个现行体系结构的学习研讨会，向团队介绍已有的主要设计元素（参见13.1.9节）。

僵尸团队明白这项工作非常大，并期待得到更多的帮助。

产品负责人团队会议

每个Sprint都会举办一次产品负责人团队会议，该会议用于调整和协调不同领域产品负责人之间的关系，并为大家提供一些指导（参见12.2节）。

在几个Sprint之后的一次产品负责人团队会议上，领域产品负责人轮流分享他们的情况和接下来的目标。当轮到波西亚时，她说道：“不出意料，进展较小，挑战很大。但是浓雾正在散去，我和队员们正在全力以赴地工作。吉莉安和扎克帮了很大的忙。”

巴勃罗是资产服务的领域产品负责人，他对他们领域间关系紧密的条目做了一些评论。波西亚同意稍后会见巴勃罗和几位团队代表。

普丽蒂问：“波西亚，你认为我们下一个Sprint的目标是什么？”

增加第三个团队

两个Sprint过后……在产品负责人团队协调会议上，普丽蒂讲话：“正如大家所知，波西亚所在的领域目前仍然只有两个团队。我知道巴勃罗希望他的六个团队保持在资产服务领域，但多德-弗兰克法案今年对我来说太重要了，所以我们不得不把巴勃罗领域中的一个团队移到波西亚的领域。巴勃罗，请从你们组里找一个志愿团队，然后告诉我和波西亚。”

结束

巨型LeSS故事中的一些关键点：

❑总体产品负责人负责寻找领域产品负责人，并负责发展他们的能力。

❑总体产品负责人负责决定启动、增长或压缩需求领域。

❑需求领域很大，通常需要4到8个团队，但在初始启动期间，尤其是在只有一个团队且使用“切分出小功能块”方法启动时，需求领域可以小一些。

❑领头羊团队首先独自处理一个大型条目，直到他们了解该领域以及开发方式，然后指导更多的新团队来帮助完成巨量工作。

2.3.7 多地点团队：术语与提示

接下来是一个涉及多地点团队的巨型LeSS故事。但首先还要明确一些定义，因为通用术语分布式团队（distributed team）所表示的含义经常被混淆，这里对这些术语加以澄清：

❑分散团队——人员（例如7人）分布在不同地理位置的团队；不同的房间、不同的建筑物，甚至不同的城市。

❑同地点团队——几乎是围坐在同一张办公桌旁工作的团队。

❑多地点团队——在一个地点工作的同地点团队，和在另一地点工作的同地点团队。

其次，这里再给出一些提示：产品组拥有的是多地点团队。分散团队通常是不良组织决策的产物，也可能是没考虑到不采用同地点团队所需成本。

❑分散团队很少是真正的团队；它更可能是松散联系的个人群体。沟通协调摩擦较大，很少能结成团队。

❑当产品组有50人或500人时，没有必要采用分散团队。7人一个小组很容易共处一地。但是，这样的团队有些可能位于不同的地点，因此

规则：每个团队都是自管理的、跨职能的、同地点的、长期的。

2.3.8 巨型LeSS故事：多地点团队

波西亚是证券交易系统中新需求领域的领域产品负责人。新的领域开始时只有一个团队，专注而简单。几个Sprint之后，波西亚的领域增加到了三个团队。她和前两个团队一起驻扎在伦敦。但是第三个新团队，名叫德拉库勒斯第家族（HouseDraculesti），位于公司的一个主要开发基地，在罗马尼亚的克鲁日。

为什么不在伦敦开发基地添加第三个团队呢？这样做不是可以避免在一个需求领域内进行多地点开发可能带来的许多麻烦和效率损失吗？其中的成本提高会使得其添加了一个团队而不得不去掉另一个团队。

但这个案例有其积极的一面，因为克鲁日距离伦敦只有两个时区，那里的人都说英语，而且在这个重视长期实践工程的城市里，很多开发人员拥有计算机科学学位，具有超强能力。此外，这是公司一个专门的内部开发地点，这些内部团队都有丰富的开发经验，对产品和领域有着深刻的理解。

说到底，普丽蒂（产品负责人）不希望任何伦敦团队离开他们目前所在的需求领域。

普丽蒂知道多地点团队是波西亚要面临的一种全新情况，所以在接下来的一次会议上，她这样说道：“请你的Scrum Master和西塔谈谈，也请西塔对你在做的一些事情提供一些指导。她是资产服务领域的Scrum Master，几年来她一直关注着他们的多地点开发。她知道各个Scrum Master与他们的团队同地办公的重要性，并且帮助主持了许多次多地点会议。”

普丽蒂继续说：“而且，我们今年的利润非常可观，所以我将给你和僵尸团队提供资金，尽快旅行到克鲁日去，和那里的团队同坐在一个房间内一起做迭代，紧密合作。克鲁日团队也可以来伦敦，但你需要在他们的工作地点发出一个强烈信号，表明他们很重要。当然要尽量避免让他们觉得伦敦比克鲁日更重要。哦，你还可以邀请他们每隔几个月定期走访一次。”

多地点Sprint计划第一部分

几个Sprint之后，有一次波西亚走进了一个房间，她看到房间里的计算机显示器投影仪连接着笔记本电脑，视频里正在显示的是克鲁日的一个房间，克鲁日的整个团队都坐在那里。西塔建议整个克鲁日团队在加入该需求领域的前几个月里能够参加多地点会议，这将能有效提高大家的学习效率和参与度（参见12.1.2节）。

所有团队代表都带着平板电脑或笔记本电脑。

波西亚开始讲话：“欢迎大家。屏幕上的共享电子表格中突出显示的部分是我对这个Sprint条目的提议。我想大家都明白为什么这些主题和优先事项都很重要，因为我们已经在PBR中讨论过这个问题，它反映了我们大家的意见。不过，现在再问大家一次，你是否需要对它们做再次的澄清。除此之外，我还会邀请大家在自己希望开发的条目旁输入团队名称。”完成之后，小组进入问答阶段，并总结了条目一直存在的一些问题。伦敦的代表们在墙面贴纸上写问题，克鲁日的团队成员在共享电子表格中键入问题。波西亚花时间看了一些贴纸上的图，并与大家边讨论答案边在纸上画草图。她还花了一些时间在电子表格上为克鲁日团队作答，同时通过视频会议与他们进行面对面的交谈。

大约30分钟后，各种不同的问题都得到了解决，波西亚请大家一起回来。她说：“在我们结束之前，大家还有什么问题想一起讨论吗？”

多地点总体PBR

伦敦地点的人们进入研讨会会议室。那里设置有两台投影仪。一台显示的是克鲁日工作室视频，另一台显示的是波西亚计算机上的浏览器（参见11.1.2节和11.1.5节）。

波西亚说道：“我们开始吧。我想集中拆分一些条目。我邀请了扎克加入进来，他对此非常了解。”

扎克使用了一个基于浏览器的思维导图工具，一边与小组讨论一边创建思维导图分支。

然后，他们使用共享电子表格为每个新拆分的条目编写实例，以便两个地点的人员都能对细节有一个轻量级但很具体的了解。之后，小组使用特别大的规划扑克来对新条目做估算，大的规划扑克有助于大家举牌时在计算机和视频上看得清楚。

结束

巨型LeSS多地点故事中的一些关键点：

❑多地点团队经常会产生明显且微妙的摩擦并增加成本，其负面影响之大往往令人吃惊。

❑减少地点摩擦的有效方法包括：团队时区相近，工作地点为内部且专用（非外包），开发人员流利使用相同语言，地理位置和文化方面高度重视开发人员的长期实践和卓越能力。

❑Scrum Master必须与他们的团队共处一地。

❑各地点人员相互之间感觉像同伴，而不是二等公民。

❑定期走访不同地点，增加相互交流。

❑会议中争取使用视频工具进行虚拟面对面交流。

❑使用共享文档工具，同步轻松地修改工件。

2.4 继续前进

不要问：“我们如何在复杂而笨拙的组织中实现大规模敏捷？”而要问一个特别且有深度的问题：“我们如何简化组织使其变得敏捷而不是去做敏捷？”真正扩展Scrum起始于变革组织，而不是改变Scrum。在下一个部分中，我们将利用4章的篇幅集中讨论如何理解和实现简单的以客户为中心的LeSS组织。

再接下来有部分LeSS产品和LeSS Sprint，我们将在其中介绍简单LeSS组织中以客户为中心的产品和迭代。