LeSS框架想要解決的問題是如何將Scrum的原則、元素盡可能簡單夠用的使用到多個團(tuán)隊，合作開發(fā)一個產(chǎn)品的場景里去。

Less簡介

Scrum開發(fā)團(tuán)隊最佳規(guī)模是足夠小以保持敏捷性，同時足夠大可以在 Sprint 內(nèi)完成重要的工作，一個建議的數(shù)值通常是7加減2人，這樣既可以保持敏捷性又可以在Sprint內(nèi)交付潛在可發(fā)布的產(chǎn)品增量。

對于小規(guī)模產(chǎn)品，1個Scrum團(tuán)隊也許可以很好的應(yīng)付，然而現(xiàn)實中大規(guī)模產(chǎn)品開發(fā)時常常會涉及到多個團(tuán)隊協(xié)同開發(fā)一個產(chǎn)品。

如果我們繼續(xù)采用Scrum的方式進(jìn)行產(chǎn)品研發(fā)，我們就不得不需要思考一個問題：不同團(tuán)隊如何一起有效的合作完成一個產(chǎn)品的開發(fā)？

行業(yè)里目前有一些大規(guī)模敏捷的解決方案，如 Large Scale Scrum（LeSS）， Scrum of Scrums， Scaled Agile Framework（SAFe）， Disciplined Agile Delivery（DAD），NEXUS等等。

“LeSS is Scrum applied to many teams working together on one product.”簡單說LeSS依然是Scrum，依然是那三個角色，三個工件，五個會議。LeSS框架想要解決的問題是如何將Scrum的原則，元素盡可能簡單夠用的使用到多個團(tuán)隊，合作開發(fā)一個產(chǎn)品的場景里去。

LeSS框架分為兩類：LeSS以及LeSS Huge，超過8個Scrum團(tuán)隊的時候使用LeSS Huge框架。不要問我8是怎么來的，就這么定的，當(dāng)然在實踐的過程中需要考慮產(chǎn)品負(fù)責(zé)人以及Scrum團(tuán)隊成熟度適當(dāng)調(diào)整，理論總是要聯(lián)系實際。

LeSS實踐

沒有合理的團(tuán)隊設(shè)計讓產(chǎn)品研發(fā)事倍功半，而有了合理的團(tuán)隊設(shè)計讓團(tuán)隊事半功倍，團(tuán)隊設(shè)計是影響團(tuán)隊績效的一階因素。

團(tuán)隊設(shè)計簡單說包含兩方面考慮，一個是團(tuán)隊自身結(jié)構(gòu)的設(shè)計，一個是團(tuán)隊間溝通協(xié)調(diào)方式設(shè)計。團(tuán)隊自身結(jié)構(gòu)設(shè)計上通常有兩種選擇：組件團(tuán)隊或特性團(tuán)隊。

1、組件團(tuán)隊

在組件團(tuán)隊模式下需求拆分為組件子需求，往往一個需求會涉及到多個組件團(tuán)隊，通常會產(chǎn)生以下一些影響：

1）組件團(tuán)隊缺少產(chǎn)品整體視角，關(guān)注組件交付而非客戶價值交付，常見的句式是：“我的做完了”。

2）組件團(tuán)隊通常資源共享，關(guān)注資源效率，而非價值交付效率。當(dāng)一個組件團(tuán)隊服務(wù)多個業(yè)務(wù)方的時候，往往容易導(dǎo)致組件團(tuán)隊陷入公共綠地的困境，不用白不用，白用誰不用，各個業(yè)務(wù)方拼命爭奪組件團(tuán)隊資源，在整體溝通信息不順暢的時候，一個潛在的結(jié)果是最會哭最會喊的那個業(yè)務(wù)方需求獲得了資源，而不是對于公司或客戶最有價值的業(yè)務(wù)方需求獲得。

3）組件團(tuán)隊組織產(chǎn)品研發(fā)時通常也會采用項目制開發(fā)模式，從各個組件團(tuán)隊抽調(diào)資源，組建短期項目團(tuán)隊。不同的PM、不同的團(tuán)隊成員、不同的做事風(fēng)格、不同的項目復(fù)雜度、不同的完成標(biāo)準(zhǔn)，不否認(rèn)有非常牛X的項目經(jīng)理帶領(lǐng)非常牛X的團(tuán)隊完成非常牛X的項目，但整體上看，往往整個項目進(jìn)度、質(zhì)量、效率不穩(wěn)定可控。同時在短期的項目團(tuán)隊里，人往往被視作實現(xiàn)項目目標(biāo)的一個資源，成員工作動力不足，高效的團(tuán)隊是需要長時間磨合的。

4）項目制方式加上關(guān)注資源效率，通常產(chǎn)生的一個現(xiàn)象是團(tuán)隊/個人多任務(wù)并行。適當(dāng)?shù)牟⑿锌梢蕴岣邎F(tuán)隊的吞吐量，但同時會延長客戶價值交付周期。當(dāng)并行超出某一個限度的時候往往會導(dǎo)致整體質(zhì)量效率下降。在一定程度上這是一個投入產(chǎn)出比平衡的結(jié)果。

5）跨組件團(tuán)隊溝通時需要非常清晰明確的公司策略，產(chǎn)品優(yōu)先級等信息支持，才能更好的協(xié)調(diào)多個團(tuán)隊協(xié)作開發(fā)。但現(xiàn)實的情況往往是整個信息不夠透明。另一方面團(tuán)隊都會有自己的屁股，有做大做強(qiáng)自己組件的沖動，往往導(dǎo)致跨團(tuán)隊溝通協(xié)調(diào)成本高。

在溝通協(xié)調(diào)不順暢的情況下，往往會產(chǎn)生強(qiáng)烈的項目管理需求。比較極端的case，一個人半天代碼量的需求，前前后后花費了不同團(tuán)隊10個人討論了3天，最后在外力的介入下才拍板。

6）客戶價值匹配組件團(tuán)隊技能，而非團(tuán)隊技能匹配客戶價值；當(dāng)某一組件需求集中涌現(xiàn)的時候，容易產(chǎn)生擴(kuò)大團(tuán)隊的沖動；當(dāng)某一組件團(tuán)隊高優(yōu)先級需求不足的時候，并不會縮小團(tuán)隊規(guī)模，反而會找活做，容易導(dǎo)致低價值交付，后果是不斷擴(kuò)大的組件團(tuán)隊；

7）在某些組織里經(jīng)常會看到組織調(diào)整，一個原因就是不斷擴(kuò)大的組件團(tuán)隊，導(dǎo)致研發(fā)成本不斷攀升，但研發(fā)成本攀升的同時并沒有實現(xiàn)同等客戶價值價值交付，投入產(chǎn)出比降低，所以需要動一動，也算是一種應(yīng)對的方式，只是這種變化通常更劇烈一些。

8）當(dāng)需求被拆分到各個組件團(tuán)隊后，帶來的另外一個后果是后期集中集成，集中測試，反饋周期往往拉長，并且將風(fēng)險留在最后，往往導(dǎo)致項目延期，交付周期變長。

2、特性團(tuán)隊

1）長期穩(wěn)定存在，長期的合作利于打磨高效團(tuán)隊，質(zhì)量和效率穩(wěn)定可預(yù)見；

2）跨技能，團(tuán)隊成員技能中包含前端，開發(fā)，測試等多種技能；

3）跨組件，團(tuán)隊覆蓋的范圍同時橫跨多個組件；

4）團(tuán)隊能獨立完成客戶價值交付；

5）團(tuán)隊間協(xié)調(diào)合作從項目管理域轉(zhuǎn)移到代碼技術(shù)域；

特性團(tuán)隊要面臨的挑戰(zhàn)

1）每個人都需要掌握所有東西？整個團(tuán)隊需要擁有產(chǎn)品交付的所有技能，并在客戶需求開發(fā)過程中不斷學(xué)習(xí)擴(kuò)大個人技能領(lǐng)域，這是一個長期的過程，取決于團(tuán)隊學(xué)習(xí)的能力。BTW：在現(xiàn)在以及未來的千變?nèi)f化的社會中，無論是個人還是團(tuán)隊，學(xué)習(xí)能力將是一個非常重要的能力。

2）如何保證組件代碼質(zhì)量？需要工程實踐上的配合，例如主干開發(fā)，持續(xù)集成，保證產(chǎn)品不被破壞；組件守護(hù)者，review組件相關(guān)修改，技能指導(dǎo)；不同人從產(chǎn)品交付的角度修改組件促進(jìn)代碼學(xué)習(xí)以及程序員社交。

3）整體上特性團(tuán)隊對外更加關(guān)注客戶價值價值，促進(jìn)創(chuàng)新；對內(nèi)打破團(tuán)隊邊界，促進(jìn)組織轉(zhuǎn)型升級；對個人促進(jìn)個人學(xué)習(xí)，提升個人技能。

一個LeSS實踐樣例

0、背景

組建一個研發(fā)團(tuán)隊，準(zhǔn)備開發(fā)一個公司內(nèi)部DevOps研發(fā)平臺產(chǎn)品。團(tuán)隊成員包括3個前端JS開發(fā)，9個后端JAVA開發(fā)，1個測試，1個交互；前后端分離設(shè)計，前端基于React，后端基于SpringBoot；團(tuán)隊成員幾乎不懂敏捷開發(fā)，Scrum以及LeSS等。

1、組建特性團(tuán)隊

敏捷原則之一“我們最重要的目標(biāo)，是通過持續(xù)不斷地及早交付有價值的軟件使客戶滿意?！睂τ谝粋€從0到1的產(chǎn)品，持續(xù)不斷的滿足客戶需求，持續(xù)不斷的從客戶收集反饋對于產(chǎn)品來說非常重要，特性團(tuán)隊更適合當(dāng)前的產(chǎn)品研發(fā)場景。

根據(jù)項目背景，組建3個特性團(tuán)隊，每個團(tuán)隊4人，其中包含前端開發(fā)，后端開發(fā)，可以獨立完成產(chǎn)品需求交付。

2、明確特性團(tuán)隊之間的溝通協(xié)調(diào)方式

團(tuán)隊間溝通協(xié)調(diào)方式會受到產(chǎn)品需求組織方式的影響。團(tuán)隊將要開發(fā)的DevOps平臺是一個非常復(fù)雜的產(chǎn)品，涉及的需求領(lǐng)域很多，比如環(huán)境管理、應(yīng)用管理、版本管理、持續(xù)集成等，同時這是一個從0到1的過程，每個需求領(lǐng)域都有著充足而穩(wěn)定的產(chǎn)品需求，并且每一個領(lǐng)域都需要一定的領(lǐng)域背景知識才能更好的設(shè)計實現(xiàn)產(chǎn)品，所以筆者決定劃分為4個產(chǎn)品需求領(lǐng)域：環(huán)境，應(yīng)用，版本，持續(xù)集成。

3、需求領(lǐng)域

在LeSS里是沒有需求領(lǐng)域的，需求領(lǐng)域是LeSS Huge里的概念，當(dāng)團(tuán)隊個數(shù)大于8個的時候建議使用LeSS Huge，并且區(qū)分需求領(lǐng)域，每一個需求領(lǐng)域里依然是LeSS工作方式，同時增加APO角色負(fù)責(zé)一個需求領(lǐng)域。

雖然只有3個特性團(tuán)隊，但依然選擇劃分了需求領(lǐng)域，這點和LeSS有所不同。這里考慮的是團(tuán)隊個數(shù)是一個劃分需求領(lǐng)域的參考，同時產(chǎn)品復(fù)雜度和產(chǎn)品所處的階段可能也是需要考慮的一個維度。

在LeSS里不區(qū)分需求領(lǐng)域的情況下，每一個特性團(tuán)隊在一定程度上是等同的，提供最大的靈活性。需求領(lǐng)域的劃分在一定程度上降低了團(tuán)隊跨需求領(lǐng)域的靈活性，但是在當(dāng)前產(chǎn)品初期從0到1的情況下，每個領(lǐng)域高優(yōu)先級需求充足而穩(wěn)定，足以保證每一個特性團(tuán)隊持續(xù)的高價值交付，團(tuán)隊的跨領(lǐng)域靈活性暫時不是考慮的最主要的問題。

最終團(tuán)隊整體設(shè)計如下圖所示，一份產(chǎn)品待辦列表，劃分四個需求領(lǐng)域，每一個需求領(lǐng)域由一個特性團(tuán)隊負(fù)責(zé)需求，特性團(tuán)隊中包括前端開發(fā)和后端開發(fā)，其中特性團(tuán)隊C負(fù)責(zé)兩個需求領(lǐng)域。

這在一定程度上即保持了產(chǎn)品特性團(tuán)隊的特征，又減緩了特性團(tuán)隊在工程實踐上帶來的挑戰(zhàn)，當(dāng)然也犧牲了一定的團(tuán)隊敏捷性，這是當(dāng)下的選擇。

需要指出的是，團(tuán)隊的結(jié)構(gòu)設(shè)計不是一成不變的，隨著產(chǎn)品的演進(jìn)，需求領(lǐng)域不斷的涌現(xiàn)和消亡，團(tuán)隊的結(jié)構(gòu)設(shè)計也是隨著時間調(diào)整的，未必一個團(tuán)隊就只能工作在一個需求領(lǐng)域，或者一個需求領(lǐng)域只能一個團(tuán)隊工作，甚至是否還需要需求領(lǐng)域劃分，這是需要根據(jù)現(xiàn)實的情況來調(diào)整的。

總結(jié)

簡單總結(jié)一下，Scrum是敏捷世界里廣泛使用的一個框架，簡單，易懂但難于掌握。LeSS是大規(guī)模敏捷開發(fā)世界里一個常用的框架，它的本質(zhì)上依然是Scrum，它想要解決的問題是如何將Scrum的原則，元素盡可能簡單夠用的使用到多個團(tuán)隊，合作開發(fā)一個產(chǎn)品的場景里去。

在LeSS框架里，很重要的一點在于團(tuán)隊設(shè)計。記得以前去拜訪一個公司，公司領(lǐng)導(dǎo)介紹了公司的組織結(jié)構(gòu)，交流中我會問他一些潛在的問題點，他會很驚訝于你怎么知道？組織的很多問題根源在于組織結(jié)構(gòu)設(shè)計，相同的結(jié)構(gòu)設(shè)計上往往存在相同的問題。沒有合理的團(tuán)隊設(shè)計讓產(chǎn)品研發(fā)事倍功半，而有了合理的團(tuán)隊設(shè)計讓團(tuán)隊事半功倍。團(tuán)隊設(shè)計是影響團(tuán)隊績效的一階因素。BTW：世界上沒有所謂的最佳實踐，沒有所謂的銀彈，有的僅僅是在特定的上下文里合適的實踐和方法。

轉(zhuǎn)載自：http://www.woshipm.com/pmd/969435.html