随着敏捷的发展，越来越多项目和公司开展采用大规模敏捷的方式进行敏捷开发。
1. SAFe
Dean Leffingwell（SAFe创始人）于2011年上线了SAFe1.0，随后根据业务实践以及市场变化，SAFe不断改进和提供软件和系统开发方法，及时上线新版本。敏捷项目管理已经深入人心，很多公司都使用Scrum，XP，TDD等敏捷框架来管理软件开发，显著提高了开发质量和速度，应对不断变化的业务需求和市场。当涉及大规模软件开发，这些框架显得力不从心。以目前市场占有率80%以上的Scrum为例，众所周知，Scrum开发团队以3-9人为佳，然而，如果一个大型软件需要10个Scrum团队合作开发，如何协调这10个团队，就变成一个问题。
要解决这个问题，就需要引入规模化敏捷实践。其中SAFe是使用最广泛的规模化敏捷框架（见下图），主要分为企业级解决方案和政府精益敏捷解决方案。企业方案中，迭代团队使用Scrum和Kanban实现敏捷。每个Agile Release Train可以包括5-10个迭代团队，大约50-125人。一个ART（Agile Release Team）无法满足需求时，可引入Solution management和Portfolio management。
举一个例子，我经历过的车企_SAFe 项目（不代表全部情况）。
- 组织结构复杂： 人数比较多产品经理就有3.4个，开发团队加起来将近50个人。
- 沟通繁琐：这么多人的项目，开起会来时间很长，相当痛苦。每一次各个业务对齐，都让所有人参加，能装满所有人的会议室就是很大的问题。即使，会议室足够大，大家都进来了，开大会的时候因为很多地方和自己手上工作无关，大部分时间也经常是不知所云。-
- 相对能够对变化进行相应：从敏捷角度，在组织内部沟通灵活地条件下，可以应对变化，这一点相比较瀑布有一定优势。
2. LeSS
LeSS是一个轻量级的敏捷框架，用于将Scrum扩展到多个团队。从2005年开始，Bas Vodde和Craig Larman在大型项目中使用Scrum原则和规则后开发了LeSS框架。他们的目标是在不受Scrum约束的情况下成功开发大型项目。
LeSS建立在经验组织，跨部门自组织团队等Scrum原则之上，并提供了一个大规模应用该框架的框架。它提供了有关如何在大规模产品开发环境中采用Scrum的简单结构规则，指南和实验。LeSS只有几个规则和两个框架：LeSS和LeSS Huge。
LeSS基础：2–8个团队
最庞大的团队：8个以上的团队
不同之处在于所涉及的团队总数。基本的LeSS是由2到8个团队组成，每个团队八个，从事相同的产品开发。LeSS Huge拥有多达2,000多名从事相同产品开发工作的人员。换句话说，您想要多大？LeSS可以向上或向下扩展Scrum，以在许多环境中工作。
下图说明了LeSS基本框架。开发团队的数量从两个到八个不等。一个产品负责人最多负责八个团队，每个Scrum管理员最多可以服务三个团队。
在LeSS框架中，完整的可交付产品有一个产品所有者和一个产品积压。产品负责人不应独自从事产品积压工作的改进。她得到了直接与客户/用户和其他利益相关者合作的多个开发团队的支持。所有优先级都通过产品所有者进行，但澄清可以直接在团队与客户/用户和其他利益相关者之间进行。尽管LeSS大部分内容仍然适用于一站式Scrum框架，但差异非常重要：
-Sprint计划分为两个部分：第1部分是所有团队通用的，第2部分是每个团队通用的。
- 冲刺计划（第1部分）每周冲刺时间限制为一小时。尽管并非所有开发人员都必须参加，但他们并不灰心，每个冲刺团队至少有两名成员与产品所有者一起参加。然后，代表团队成员回去并与各自的团队共享他们的信息。
- 独立的sprint计划（第2部分）和每日讨论会进行，并且来自不同团队的成员可以参加彼此的会议，以促进信息共享。
- 跨团队协调由团队决定，与集中式协调相比，分散式和非正式协调更为可取。重点是非正式的网络，其中涉及跨团队交谈，组成指导者，旅行者，侦察员和开放空间。
- 每个开发团队和产品所有者的代表都对整个产品积压工作进行了积压细化。单个团队的待办事项清单细化也在单个团队级别进行，但是多团队的待办事项清单细化在每个冲刺中都会发生，并且是LeSS中的关键实践。每个团队和产品负责人的代表都要进行审查。
从运行方式上看，LeSS看起来比SAFe更加简单易用并且沟通成本低，我个人比较喜欢这种方式（可能是因为经历的SAFe项目有些痛苦的原因。）
