LeSS Huge 框架是 LeSS 中第二個框架, 它是針對有 8 個以上 (不含 8 個) Scrum 團隊來使用的. 所以 LeSS 框架是針對大約 10 – 50 的團體, 而 LeSS Huge 框架是針對大約 50 – 6000+ 的團體.

Source: https://less.works/less/less-huge

基本上, LeSS Huge 框架是由多個 LeSS 所組成, 有時候我們會稱 LeSS Huge 框架是一疊 LeSS 框架. 所以大部分的地方, LeSS Huge 框架和 LeSS 框架差不多, 類似的角色, 產出物, 和活動.

(1) 角色

除了 LeSS 的角色外, 還多了 Area Product Owner, 以及每個需求領域會有 4 到 8 個 Scrum 團隊.

(2) 產出物

和 LeSS 差不多, 但是在 Product Backlog 中的 Product Backlog Item 會多了需求領域的屬性. 用來區分這個 Product Backlog Item 是屬於哪個需求領域.

(3) 活動

這邊就和 LeSS 真的一樣. 大家有共同的 sprint, 最後還是要交付一份產品增量.

接下來我們將針對不一樣的地方加以說明. 以下三個主要不一樣的部分：

圖片來源: https://less.works/less/less-huge/requirement-areas

(1) 需求領域 (Requirement Area)

對於大型複雜的東西, 我們的處理方式就是 divide and conquer, 也就是各個擊破. 常見以前的作法有以下兩種:

a. 角色分組: 依照分析, 開發, 測試等角色來切割
b. 架構分組: 依照要開發的系統架構來切個, 可能每個元件有一組人馬負責. 或者是一組人馬負責多個元件

但是不管怎麼分, 這些都不是以用戶的角度來分. 從用戶的角度來看, 他不知道你有什麼角色, 以及你系統切成哪些元件. 他只知道你的產品功能有什麼. 因此, 應該是以產品的功能需求來分類. LeSS 中把需求邏輯接近的分成一群, 稱之為需求領域 (Requirement Area, 又稱之為 RA). Requirement Area 有著以下特性

a. 規模夠大: 大約大到需要 4 到 8 個 Scrum 團隊來處理. 而非只是 1 到 2 個 Scrum 團隊就可以處理
b. 範圍動態: 需求領域隨著時間的演進, 範圍和重要性會改變, 尤其當有 Scrum 團隊加入或減少時, 範圍可能就會改變.

基本上, 不該有需求領域是 1 到2 個 Scrum 團隊負責, 因為這樣很容易造成有很多小的需求領域產生, 這樣很容易局部優化, 協調上也變得複雜.

一個領域可以有多個 Scrum 團隊共同處理, 每個 Scrum 團隊只會負責一個領域.

(2) Area Backlog

在 LeSS 中我們還是只有一份 Product Backlog, 但是在每個 Product Backlog Item (PBI), 我們可以加入需求領域的屬性. 下面是一個 product backlog 範例

如果我們只專注在某一個領域, 我們把這個稱為 Area Backlog

(3) Area Product Owner

每一個領域會有一位 Product Owner, 負責將這個領域的需求, 填到 Area Backlog 中. 他也需要和其他領域的 Product Owner 合作, 保持產品的聚焦, 並且某個領域過度優化. Area Product Owner 們 和 Product Owner 會共同組成一個團隊：產品負責人團隊. 這個團隊會討論出事情的優先順序, 但是 Product Owner 是擁有最後的決定權. 他決定何時要發佈, 發佈的範圍是哪些.