規模化敏捷 LeSS（三）：LeSS Huge 是怎樣煉成的？

上篇文章《 》中講到 LeSS 框架中的團隊數量不要超過8個，但8個以上的團隊要如何實踐敏捷呢？

為了應對8個以上團隊實踐敏捷的情況，Bas 以及 Carig 還提出了 LeSS Huge：一個透過在多個小型 LeSS 框架堆疊的基礎上擴充套件的規模化敏捷框架。

一、需求領域

LeSS Huge 按照產品中的客戶需求，劃分出不同的需求領域，每一需求領域由幾個相應的功能團隊組成。也就是說，需求領域是按比例放大的功能團隊。

舉一個例子來進一步說明需求領域：在一個小型的保險團隊中，會有合同承保、合同修改以及索賠三個功能角色，LeSS Huge 中可以將一個大型保險團隊分為合同承保、合同修改以及索賠三個需求領域，每一領域有幾個相對應的功能團隊。這裡要注意的是，需求領域具有臨時性，會根據產品的需求在整個生命週期內進行調整（不會在每一迭代中改變）。

二、產品負責人團隊

首先需要解決一個產品負責人無法協調眾多團隊的問題。LeSS Huge 增加了產品負責人團隊的概念：劃分不同的需求領域，每一需求領域增加一名區域產品負責人，該區域產品負責人會對該需求區域的產品需求做出優先順序決定。

由於需求區域大小不同，每個區域會包含不同數量的團隊，團隊太小會導致積壓事項，團隊太大則會導致區域產品負責人無法協調，因此一個合理的需求區域所包含的團隊數量在4-10之間。

產品負責人團隊由產品負責人主導，即產品負責人始終擁有最終決定權，且產品範圍及產品釋出時間仍由產品負責人決定。

三、區域產品待辦列表

針對某一需求領域歸納整理出該領域的產品待辦列表，這一事項由該區域產品負責人負責。相比產品待辦列表而言，區域產品待辦列表內包含的是更易於管理、顆粒度更細的專案。但如果區域產品待辦列表與產品待辦列表出現很大的差異的時候，就需要考慮重新整理產品待辦列表了。

四、一個產品級 Sprint

同 LeSS 框架一樣，LeSS Huge 框架中所有團隊都處於一個 Sprint 之下，又以交付一個整合的整體產品增量結束。

其次，無論是 Sprint 計劃會議2、Sprint 評審會議還是 Sprint 回顧會議，都可以以一個需求領域為單位來組織會議活動。為了對齊計劃與進度，區域產品負責人要經常與產品負責人同步，從而及時發現團隊方向是否出現了偏差，團隊是否處理的是最有價值的專案等。

五、由點到面的 LeSS Huge 實踐

由於團隊規模龐大，實現一次性採用 LeSS Huge 框架會有很大的風險，因此，LeSS Huge 的實踐應循序漸進地進行。

首先，應先完善一個需求領域，其次逐步擴大團隊的工作範圍以及完成的定義，與此同時，讓其他團隊做好轉型的準備，逐步適應 LeSS Huge 框架，實現由點到面的規模化敏捷轉型。規模化敏捷實踐的轉型往往需要很長時間，急功近利並不可取。

LeSS Huge 在 Scrum 以及 LeSS 的基礎上，重新擴充套件了敏捷框架，降低了大型團隊管理的複雜。其中，最重要的還是團隊之間的協作性與互通性，而 LeSS 強調的更加靈活的團隊便是要著重實現這一點。