自2005年以来，Craig Larman和Bas Vodde一直与许多组织合作，将Scrum，精益和敏捷开发扩展到大型产品组。他们将从这项研究中获得的经验和知识转化为一个名为“大规模Scrum（LeSS）”的敏捷框架草案。
虽然许多思想领袖已经提出了这样的指导，但Craig和Bas认为“Scrum”作为一个框架具有有效采用敏捷所需的所有要素，而不管规模如何。可用的角色，流程和工件集足以成功实施Agile。因此，他们制定了LeSS，没有额外的术语或复杂的文物。
- 是适用于多个团队 是跨职能，跨组件，为3〜9自我激励的全堆栈功能团队，学习的重点成员
- 一起工作涉及协同努力与一个共同的目标，在共同冲刺年底交付一个共同的可交付的产品
- 专注于**“一个产品”**，这是一个广泛的完整的端到端以客户为中心的解决方案，真正的客户可以使用。它不仅限于组件，平台，层或库
LeSS有两个框架：
- 涉及2-8支队伍的LeSS
- LeSS Huge超过8支团队
让我们深入研究LeSS框架，并研究采用该框架要遵循的流程。
第1步：定义您的产品
LeSS的核心原则之一是保持**“整体产品聚焦”**。有了这个原则，压力在于所有团队都需要将产品作为“整体”而不是单独的部件，任务或专业化来关注。提供个人或半工作部件没有任何价值。
“产品”是客户整体利用，看到和重视的东西。
让我们进一步理解这一点。据您所知，以下哪项可视为“产品”？
- 自动导航系统的硬件电路板
- 自动导航系统作为一个整体，包括硬件和软件
- 一辆汽车，包括所有部件
显然，客户对整个产品的看法是“汽车”本身，它形成了广泛的定义。从以客户为中心的角度定义广泛的产品，可带来以下好处：
- 帮助以客户为中心的优先级
- 围绕产品创建更简单的组织
- 吸引人们关注真正的问题和影响，而不是要求“要求”
在最广泛的层面管理“产品”可能并不总是切合实际。通过广泛的定义，通过考虑现有结构，计划的组织发展和结构变化的可行性等，将定义限制在尽可能实际的范围内。
LeSS通过提供更广泛的产品定义，消除不必要的复杂组织解决方案以及寻找更简单的解决方案来降低组织复杂性。
在规划LeSS采用时，请从有效的产品定义开始。产品定义确定：
- 产品积压范围
- 产品负责人，以及
- 团队力量基于产品规模
第2步：定义您的产品团队
在LeSS中，组织结构为“产品团队”，更加关注“整体产品”。产品团队是由2-8个特色团队组成的团队。“功能团队”是一个长期的，跨职能的团队，由一般的专家组成，可以逐个完成许多端到端的客户功能。
LeSS需要团队拥有必要的知识和技能来完成端到端的以客户为中心的功能。如果没有，团队应该在学习或获得所需的知识和技能时继续学习。
上图描绘了LeSS中的“产品团队”结构。该团队以“整体产品”为重点，因此，他们在单个“产品Backlog”上工作。由于他们是“功能团队”，他们能够处理产品Backlog中的任何项目。
如果任何功能团队成员没有必要的技能来处理特定需求，那么学习是“强制”的，从而打破了过度专业化约束。
第3步：管理产品积压和持续改进
产品团队致力于构建单个产品，并通过单个产品Backlog工作，该产品Backlog定义了产品的所有工作。
LeSS为此产品Backlog维护一名产品负责人，该产品负责人支持“整个产品”。产品负责人与团队一起创建和管理产品Backlog，并关注两个关键信息流：
- 优先处理产品Backlog中的项目
- 将产品Backlog中的项目清理为团队
产品负责人还不断参与“产品Backlog改进”。通常，不迟于冲刺中间，团队和产品负责人会对项目进行优化，以便为下一个冲刺做好准备。产品Backlog改进的主要活动是：
- 拆分大件物品
- 细节项目直到准备好
- 估计
这个改进在三个层面完成：
整体产品积压改进 -
来自所有团队的代表以及产品负责人决定下一个sprint的项目。这有助于团队之间达成共识，也有助于每个人获得整体情况。
团队级产品Backlog改进 -
在获得对冲刺要求的全面了解后，团队会仔细考虑他们的特定积压项目，并更清楚地了解为下一个冲刺选择的项目。产品负责人会被告知积压的任何变更，例如分项或新估算
多团队产品积压改进 -
在团队与其他项目具有相互依赖性的场景中，LeSS建议使用多团队产品Backlog优化会话。
第4步：执行Sprint计划（一和二）
一旦产品Backlog得到改进并且大量商品处于**“就绪”状态，则按照产品级“Sprint”计划和交付商品，从而实现集成的“潜在可交付产品增量”**。
Sprint以“Sprint Planning”开始，包括两个部分：第一部分侧重于“什么”，第二部分侧重于将要交付的项目的“方式”。
Sprint Planning Part I（所有团队通用） -
在Sprint开始时，所有团队的所有成员都参加了Sprint Planning One。然而，随着冲刺的成熟以及对团队的理解的提高，每个团队的代表只参加Sprint Planning One活动。产品负责人和每个团队的团队或代表参加此会议，并从产品Backlog中选择他们将在下一个sprint中工作的项目。
Sprint Planning Part II（每个团队单独完成） -
在团队（Sprint Planning One）选择项目后，团队将举行自己的Sprint Planning Two会议。当团队之间存在强烈的相互依赖关系时，这些团队将组合Sprint Planning Two来识别相互依赖关系，并找出如何有效地处理它们。在本次会议结束时，团队可以更清楚地了解他们每个人在该sprint中要完成的工作，并且每个团队都会着手进行各自的冲刺。
LeSS有意识地避免了“发布计划”活动的概念，因为这往往会产生产品组：
- 在即将到来的发布周期之前不久，想一想主要的发布计划活动
- 然后开始针对该版本的开发活动
这种心态只是“订餐，然后等待送餐”的变体，这与传统的“合约博弈”相关，与敏捷规划中的发明和沟通的“合作博弈”不一致。
因此，Sprint Planning part I 和 Part II 本质上是一个滚动波发布计划活动，每次冲刺都会持续发生，产生“潜在可交付增量”，产品负责人可以决定在任何冲刺中“发货”
步骤5：执行具有协调和集成的Sprint
在Sprint计划之后，每个团队都开始处理Sprint积压中的项目。每个团队都会练习“每日Scrum”，以确保他们拥有共同承担责任并实现“Sprint目标”所需的所有信息。此外，在LeSS中，“每日Scrum”用于跨团队的“协调”，让其他团队的成员加入这些会议。
在Sprint期间，所有团队都可以采用分散协调和集成，以确保顺利执行，从而实现“潜在可交付增量”。一些协调技术是：
只是说说而已 -
任何团队成员都应该能够走近并轻松地与其他团队的任何成员交谈，以讨论任何问题或处理任何依赖。当出现协调需求时，人们应该能够通过电话，聊天或电子邮件等方式与“Just Talk”进行联系。
在代码中沟通 -
采用“持续集成”，以便所有团队成员将代码检入主线。发布提交后，团队成员应该与其他人讨论更改，以便与其他人同步。
发送观察员到每日Scrums -
另一种技术是让团队派代表到其他团队作为“沉默的观察者”来报告更新和关键信息。
组件社区和导师 -
必须了解围绕组件，技术和所需技能获得的知识和经验，并且可以为组件创建“实践社区[CoP]”并与所有团队进行沟通。这些社区通常由“组件或社区”导师组织，他们是“功能团队”的一员，并承担以下额外职责：
- 作为组件或技术领域的指导或指导
- 监控组件的长期健康状况
- 组织组件社区
- 组织设计研讨会
- 检查代码除了协调，这些社区还有助于提高代码质量和设计。
Scrum的Scrum -
这是一个“每日Scrum”，就像团队之间的会议，同步相关工作，消除障碍，以及处理依赖关系。
旅行者技术专家 -
许多产品团队依赖于几位经验丰富的技术专家。“旅行者”加入不同的团队，解决瓶颈，并带来一致性。
当所有团队协调并持续集成时，冲刺的执行会导致“潜在可交付增量”。
第6步：审核和回顾
冲刺后执行，审查和回顾恰好进行检查和调整。
冲刺回顾：
Sprint Review是所有团队审查一个潜在可交付产品增量的地方，重点始终是“整个产品”。
Sprint Review是一个盛大的活动，如’Bazar’或’Fair’，采用分歧 - 融合模式。在“Diverge”期间，每个团队都会分配一个站点来展示他们在该冲刺中所取得的成就。参加活动的利益相关者可以访问他们感兴趣的电台。发布此信息后，会有多个融合周期，利益相关者总结他们对展会的看法。发布评论，团队，产品负责人和用户，
Sprint回顾：
与计划类似，回顾会发生在两个层面。
- 团队回顾： 各个团队反思过去的sprint中的学习内容，并检查需要采取哪些不同的做法，以便更快更好地完成任务。
- 整体回顾： 发布此消息后，将进行“整体回顾”，让所有团队回顾上一个冲刺阶段，深入了解团队如何合作，彼此分享以及之前可能以不同方式处理的方案更好，更完美的和谐。
使用规模化 Visual Paradigm LeSS Scrum Cancas管理工具
通过专为大型项目设计的流程画布，最大限度地提高 Scrum 项目效率。
将项目工件保存在画布
规模化 Scrum 画布是一个 Scrum 工具，专为每个 Scrum 团队而设。通过直观的画布来规划、跟踪和管理 Scrum 项目。无论您的软件项目只涉及单个团队还是世界各地的多个团队，规模化 Scrum 画布都让您们连系在一起。
您不需要跳到不同的页面来浏览各种项目数据，因为所有内容都已放在同一页面。您只需单击工作项即可编辑/浏览您感兴趣的内容。
计划和追踪 Scrum 活动进程、角色和工件
规模化 Scrum 画布专为每个 Scrum 团队而设，用于管理项目工件（例如待办事项、利益相关者列表和障碍），记录事件（例如 Sprint 规划 1 和 2、Sprint 审查和回顾）以及跟踪进度。
适合各种规模的敏捷项目
具有兩個級別的大型Scrum畫布 - Sprint和Team。您可以輕鬆地在衝刺之間切換以查看當前和歷史衝刺數據（例如衝刺積壓的內容），或者在團隊之間切換以查看分配給他們的PBI並了解有關其進展的更多信息。
用户故事地图
在用户故事地图中添加和管理用户故事。通过拖放轻松地重新排列故事。开启用户故事以检视其详细信息，包括验收标准、确认项目和线框等。
丰富的用户故事，助您更好地规划
验收
制作用户故事的验收标准清单。在 Sprint 审核中逐一确认。
便利的产品待办事项列表
它为您提供项目中所有待办事项的完整列表。无论您的待办事项有多大，您都可以通过搜索和排序找到所需的项目。
Scrum 报告生成
随着项目的进展，将自动生成各种敏捷 Scrum 报告。这些报告为您的团队提供了与 Scrum 流程相关的重要资讯，使沟通更加有效。您也可以通过文件设计大师，以拖放形式编辑报告。
内置任务管理平台
一站式敏捷解决方案提供了积压和任务管理之间的无缝集成。您可以在一个地方创建任务，报告和监控进度。
一个软件，多种用途
使用 UML、BPMN、ERD、DFD、UX（线框，原型设计）、代码工程、ORM、思维导图等为您的 Scrum 项目注入动力。
结论
Scrum作为一种方法，对于团队来说非常有益，可以通过反馈循环实现增量交付并更快地适应变化。它是最常采用的敏捷方法之一的主要原因之一是因为Scrum在抽象原则和具体实践之间达到了理想的平衡。
进一步采用相同的理念，Craig Larman和Bas Vodde提出了大规模Scrum [LeSS]，可以为更大的产品组实现相同的平衡。LeSS不是新的Scrum或改进的Scrum。也不是每个团队的底层Scrum，以及不同层次的东西。LeSS是关于如何在尽可能简单的大规模环境中确定如何应用Scrum的原理，目的和元素。
正是由于这个原因，框架不会引入任何新的角色或工件，并使大型团队很容易理解和采用。
