LeSS 的誕生（一）：大規模團隊該何去何從

《敏捷宣言》釋出後，“敏捷”被越來越多的小型開發團隊認可。與此同時，另一個問題也逐漸暴露了出來： 以 Scrum 為首的敏捷方法論對那些大規模的開發團隊並不友好。

基於此，業界開始探尋能夠達到多個團隊協作開發最佳效率的辦法。直至2005年，當時在諾基亞公司工作的 Bas Vodde（一位精益敏捷教練）和 Craig Larman（一名組織設計顧問）對此產生了莫大的興趣，兩人一拍即合。憑藉 Bas 對 Scrum 等敏捷方法的應用，以及 Craig 對產品開發流程的熟悉程度，他們打造了一款適合於多團隊的規模化敏捷框架—— Large Scale Scrum（ LeSS）。

對於 如何大規模實踐 Scrum 這一問題，Bas 和 Craig 找到了完美的答案。

實際上，LeSS 框架就是將 Scrum 框架放大，並應用於多團隊管理層級中，因此，LeSS 保留了很多 Scrum 中的基本要素，例如： 每日站會、 產品待辦列表、 Sprint 計劃會議、 Sprint 評審會議、 回顧會議等。但在 Scrum 框架的基礎上，LeSS 框架又延伸出比之更大的範圍。

對於多團隊來說，規則越少，實踐的門檻就會越低。 因此，LeSS 框架是一個極簡框架，以真正的團隊作為基本構建塊來進行整個組織的架構。另外，在建立 LeSS 的過程中，Bas Vodde 和 Craig Larman 儘可能地減少定義的輸入，更多的是推動團隊憑自身經驗建立適合自己的流程。

LeSS 具體細化為兩種框架： 一種是適用於8個小團隊進行開發，每組最多8人的“LeSS”； 另一種是協調、管理多達上千人的團隊的“LeSS Huge”。不論是哪一種具體的框架，對團隊自身的要求都不會改變。

1.  LeSS 團隊要求是自管理的

一個自管理的團隊，能夠幫助各團隊成員之間增強協同能力，提高團隊工作效率。這裡的一個大前提就是，各團隊有一個共同的願景和為之奮鬥的目標，讓每一位成員都有“主人翁”意識。

2.  LeSS 團隊要求是跨職能的

Craig Larman 解釋，“與其引入一種方法，在這基礎上打各種補丁的話，倒不如嘗試改變組織架構，建立一個跨職能的團隊。”跨職能的團隊具有很大的靈活性，能夠更快地響應不斷變化的需求，並能更好地處理團隊之間的協作問題。

3.  LeSS 團隊要求是協同辦公的

多個團隊協作辦公，以更快地為客戶交付新的產品。無論如何，需要打破部門和團隊間的壁壘，透過不斷地學習、試錯來幫助各團隊、各成員之間快速適應。與此同時，與其他流程部門之間的溝通、交流也能夠為團隊增加新的可能。

4.  LeSS 團隊要求是長期存在的

由於 LeSS 面向的是多個團隊，這就要求各團隊的組合不能隨意變動。因為團隊的目標是長期的，所以透過將大目標分解為小目標，協調各個團隊步調一致，才能實現專案的成功。如若各個團隊隨意組合，那麼最初擬定的計劃則會被全盤打散。

總的來說， LeSS 團隊與小型敏捷團隊的要求沒有太大的差別。但 LeSS 框架是如何做到， 既能在團隊間保留足夠的靈活能力和擴充套件能力，又能有充足的時間來啟動整個流程的呢？LeSS 框架具體又應如何實踐呢？且聽下回分解。