Scrum 能夠幫助一個5-9人的小團隊以迭代增量的方式開發產品，在每一迭代結束時，交付潛在的可交付的產品增量。正是由於其靈活性，Scrum 方法現已成為團隊軟體交付方法的首選，近期釋出的15屆敏捷狀態報告也顯示，66%的受訪者及其所在的敏捷團隊最常用 Scrum 方法。

但隨著敏捷在團隊中得到越發廣泛的實踐，越來越多的人意識到全組織規模化敏捷實踐在當下帶來的機遇。但當人們簡單地將 Scrum 套用到多團隊實踐中的時候，又出現了各種各樣的問題。為了解決大規模開發團隊的敏捷應用問題，一款多團隊的規模化敏捷框架 Large Scale Scrum（LeSS）應運而生。

在之前的文章中，介紹過 LeSS 的“誕生”，在此就不再贅述。在這篇文章中，我們會詳細聊一下 LeSS 的具體實踐：

一、框架

為了讓框架更好地應用到多團隊中去，Bia 和 Craig 兩人決定要儘量避免向框架內新增角色、工件、流程等情況，防止因過多的定義而限制團隊的經驗實踐。其中，他們還提出了“守、破、離”三個階段：

守：在守的階段，要先打基礎，這時候團隊的行動是循規蹈矩的；
破：在破的階段，要善於打破規則，發現適合自己的情境；
離：在離的階段，要學會逐漸找到適合自己團隊的方式。

基於此，LeSS框架保留了Scrum的許多實踐與想法，如產品負責人、開發團隊、Scrum Master三角色，以及Sprint計劃會議、每日站會、回顧會議等。儘管這些概念與Scrum中的實踐相同，但側重點會有所不同。

1.產品負責人

產品負責人有兩個關鍵的職責：一個是對產品待辦列表中的事項進行優先順序排序，另一個是與團隊合作澄清產品待辦列表中的事項。

澄清產品待辦列表中事項需要產品負責人在團隊與使用者/客戶之間擔任橋樑的作用，幫助團隊與使用者/客戶直接對話，避免產生產品的需求理解分歧。

2.團隊

團隊的要求在前一篇文章有也有提到過，主要是自管理的、跨職能的、專注的、長期存在的，以及共處一地的。這將會讓團隊中的每位成員為實現團隊的共同目標，決定自己如何去做。

3.Scrum Master

在LeSS框架中，Scrum Master需要作為一個全職角色來幫助團隊解決過程中遇到的困難。一名Scrum Master最多可管理3個團隊。

二、Sprint

LeSS中的Sprint是產品級的Sprint，這意味著，各個團隊處在同一Sprint中，而在這一Sprint結束後，多個團隊將交出一個整合的潛在可交付產品增量。這意味著，所有團隊的Sprint計劃會議、Sprint評審與回顧會議都是同時進行的。在具體的實施層面，LeSS又給出了一套應用流程：

1.產品待辦列表細化會議

產品待辦列表細化會議（PBR）分為三層：

1）整體PBR

整體PBR是一個簡短的整體產品待辦列表細化會議，主要包括產品負責人以及所有團隊成員。這一會議主要為團隊分配要實施的事項。

2）多團隊PBR

在LeSS中，多團隊PBR透過專家、使用者/客戶、產品負責人、團隊成員的共同參與，來推進Sprint，提高跨團隊的適應性。多團隊PBR一般只有兩個團隊。

3）單團隊PBR

但團隊PBR在LeSS中比較少見，一般會應用在巨大且模糊不清的專案背景下，需要先讓一個團隊清除迷霧，後續逐步加入其他團隊的情況中。

2.Sprint計劃會議

Sprint計劃會議分為兩部分：

1）Sprint 計劃會議1

這一會議是所有團隊的會議，會議將劃分各個團隊的具體工作事項。如果團隊的數量較少，可以全體團隊成員參與這一會議。如果有兩個以上的團隊，則需要每個團隊派出一個團隊代表（除Scrum Master外）參與會議。

2）Sprint計劃會議2

這一會議是各團隊內部的會議，團隊在此會議上制定自己團隊的Sprint計劃。有時為了團隊之間的分享與學習，兩個或多個團隊可能會在同一房間的不同區域舉行自己團隊的計劃會議。

3.每日站會

與Scrum中的每日站會不同的是，其他團隊的成員可以加入該團隊的每日站會，進行資訊共享，更好地協調團隊之間的合作。

4.Sprint評審會議

Sprint評審會議需要所有團隊一起評審該Sprint交付的潛在可交付產品增量，應實現所有人就產品進行協作的機會。這裡的所有人指的是除產品負責人之外，還包括團隊成員、利益相關者等。

5.Sprint回顧會議

回顧會議最長持續45分鐘，分為兩種情況：其一是團隊內部展開回顧會議，其二是產品負責人、Scrum Master、團隊代表進行整體回顧，主要討論跨團隊的協作、系統問題。

與Scrum一樣，在一整套帶有流程的框架下，LeSS提供了足夠的具體實踐，以及足夠的靈活性以及擴充套件性，幫助大規模團隊探索自己的敏捷之路。在此基礎上，大規模團隊可以調整團隊實踐，最終打造出真正適合自己的規模化敏捷實踐。

此外，還要注意的一點是，LeSS框架更適合於8個以下的團隊數量，如果團隊數量超過8個，就需要應用LeSS Huge框架。具體LeSS Huge框架是如何應用的呢？詳見下一期。

規模化敏捷LeSS（二）：LeSS團隊實踐指南