上两篇文章我们分别介绍了LeSS的原则和小型 LeSS框架，本文介绍巨型LeSS框架，重点介绍巨型LeSS与小型LeSS不通的点。
图片来源：《大规模Scrum：大规模敏捷组织的设计》
当规模扩展到巨型LeSS时，似乎不可避免地需要“一些”额外的组织结构。需求领域和领域产品负责人角色正好满足了这一点，同时又能保持框架小巧。
从客户角度看，强相关的客户需求按需求领域分组。
图片来源：《大规模Scrum：大规模敏捷组织的设计》
巨型LeSS包含的角色：
产品负责人——巨型LeSS框架中有一个总产品负责人，每个需求领域有一个领域产品负责人；一个（总体）产品负责人负责产品级的优先级划分，并决定哪些团队在哪个领域工作。他应与各领域产品负责人密切合作。
领域产品负责人——专门负责客户需求逻辑领域的独立“产品负责人”。领域产品负责人承担团队产品负责人的责任。他还作为产品负责人团队的成员与总体产品负责人及其他领域产品负责人合作，以保持整体产品聚焦。
特性团队：巨型LeSS框架中分多个需求领域，每个需求领域有4到8个特性团队。特性团队专门负责产品的一部分，每个团队只属于一个需求领域。团队应长时间固定于一个领域。当其他领域价值更高时，团队可能会因此而改变其需求领域。每个需求领域有一个领域产品负责人。
产品负责人团队：总体产品负责人和领域产品负责人组成产品负责人团队。产品负责人团队中没有分析师、需求说明编写人员、UI/UX设计人员或架构师。这些角色会导致现状问题和新标签旧结构问题。专家们应该加入常规特性团队。
工件：每个需求领域所有的团队共用一个产品待办事项列表
领域产品待办事项列表——产品待办事项列表在一个需求领域的子集。它不是独立的待办事项列表，而是产品待办事项列表的逻辑视图，但可以作为独立的待办事项列表进行管理。
巨型LeSS包含多个事件：
1）Sprint计划按需求领域进行。没有特殊的规则。有一个产品负责人团队会议。
每个领域的产品负责人在决策上相对自主，因此在主题和条目的选择上存在缺失整体产品聚焦或需求领域之间的一致性的风险。对策是在下一次Sprint之前召开产品负责人团队会议。领域产品负责人分享一些特定情况和接下来的目标，并讨论是否有调整的需要。此外，一个产品负责人可以在会上提供高级别的指导。
2）产品待办列表梳理会议
在巨型LeSS中，产品待办事项列表梳理是在每个需求领域上进行的，如同在小型LeSS框架中一样。例如，“总体”PBR会议针对的是一个需求领域，而不是整个产品。对于巨型LeSS没有特别的PBR规则。
其余与小型LeSS相同。
巨型LeSS组织结构
图片来源：《大规模Scrum：大规模敏捷组织的设计》
研发地点团队——巨型LeSS采用几乎总是多地点的，组织通常倾向于将直线组织设置在本地，以使经理们能够轻松地进行“现场观察”，并真正帮助团队改进。应避免将需求领域与组织结构等同起来，因为这会导致组织结构在需要时难以改变。
产品负责人团队——与LeSS结构中的概念相同。但该类团队的规模更大，因为它包括所有的领域产品负责人。在采用巨型LeSS的大型产品组织中，产品负责人团队可以根据需求领域设立多个产品负责人团队子团队。
未完成部门——与LeSS结构的概念相同。在巨型LeSS产品组中，往往会有多个较大的未完成部门，并且需要较长的时间才能摆脱它们。在采用巨型LeSS的大型产品组中，未完成部门往往还有额外的组织结构，并且可能继续使用其过时的项目管理实践。
支持部门——该部门为团队提供开发环境支持。在LeSS中，团队之间相互支持，而不需要独立的团体提供专门支持。但巨型LeSS组织通常确实会把有些支持部门集中起来，因为他们需要应对的工作量非常大。同样，这个部门应该足够小，并且处理问题的态度可以是“我们能帮什么忙？”而不是“就这样吧！”
例如：配置管理支持是支持小组变成“控制”小组的常见例子。配置管理支持小组应该是帮助团队改进构建的专家，他们应该向团队解释构建知识并教团队做更好的构建设计，而不必成为构建的所有者。他们可以与团队成员结对，观察团队成员的工作方式，以便共同设计和改进方法。其他常见的支持小组包括试验室支持、持续集成系统支持或运营支持。
能力和指导——巨型LeSS组织设有专门的培训和辅导部门，以提高人员的能力，这对持续改进至关重要。
其余内容与小型LeSS相同。
