來(lái)源：晨小菜
作者：陳曉鵬
LeSS的第一次學(xué)習(xí)是在2019年1月份，當(dāng)時(shí)的感覺(jué)挺燒腦，對(duì)SystemThinking第一次接觸，很多東西似懂非懂，學(xué)得并不是很扎實(shí)。幸運(yùn)的是，兩年后終于有機(jī)會(huì)跟著呂毅老師重修LeSS，也算是對(duì)知識(shí)的重新回爐了。
第二次參加培訓(xùn)，對(duì)于LeSS的更細(xì)致內(nèi)容以及運(yùn)用System Thinking來(lái)思考LeSS背后的深層機(jī)理有了更深的認(rèn)識(shí)。按照個(gè)人學(xué)習(xí)習(xí)慣，照例還是會(huì)在培訓(xùn)后寫一篇文章作為學(xué)習(xí)的總結(jié)。特別強(qiáng)調(diào)一點(diǎn)，不是說(shuō)自己有多勤奮，而是想通過(guò)輸出倒逼輸入。大家知道，很多培訓(xùn)因?yàn)樵诙虝r(shí)間內(nèi)灌輸了大量知識(shí)，所以當(dāng)時(shí)大部分的內(nèi)容只是淺層記憶，雖然覺(jué)得有收獲，但是過(guò)幾天就忘得一干二凈了。而如果培訓(xùn)后沒(méi)有做進(jìn)一步的整理，知識(shí)沒(méi)有形成體系化變成自己腦袋里的東西，最終只是竹籃打水一場(chǎng)空。所以我也只是強(qiáng)迫自己做一些整理工作，不然就沒(méi)有動(dòng)力再進(jìn)行復(fù)習(xí)了。LeSS的全稱是Large-Scale Scrum的縮寫，是由Craig Larman和Bas Vodde提出的。在2005年左右，Bas還是諾基亞西門子通信公司（簡(jiǎn)稱諾西）的雇員，當(dāng)時(shí)的諾西正在經(jīng)歷從傳統(tǒng)開(kāi)發(fā)向敏捷開(kāi)發(fā)轉(zhuǎn)型的時(shí)期，而Craig作為其中一名外部敏捷教練被應(yīng)聘到諾西幫助進(jìn)行敏捷轉(zhuǎn)型。
Craig一開(kāi)始準(zhǔn)備了當(dāng)時(shí)流行的各種輕量級(jí)開(kāi)發(fā)框架介紹對(duì)諾西的各個(gè)團(tuán)隊(duì)進(jìn)行簡(jiǎn)單的培訓(xùn)，這些輕量級(jí)開(kāi)發(fā)框架包括DSDM、XP和Scrum等。然后Craig讓團(tuán)隊(duì)自己選擇需要采用哪種框架。最后，有80%以上的團(tuán)隊(duì)選了Scrum，原因很簡(jiǎn)單，Scrum是相對(duì)比較簡(jiǎn)單的框架，而大家都想挑簡(jiǎn)單的做。確定好Scrum后，Craig和Bas又面臨一個(gè)新的問(wèn)題。因?yàn)镾crum推薦的團(tuán)隊(duì)人數(shù)是5-9人，而諾西當(dāng)時(shí)的產(chǎn)品團(tuán)隊(duì)少則幾十人，多則幾百人，這種情況該如何更好的采用Scrum使得既能支持?jǐn)?shù)百人的團(tuán)隊(duì)規(guī)模，又能保持Scrum的輕便性呢?于是Craig和Bas在敏捷轉(zhuǎn)型期間做了大量的實(shí)驗(yàn)（600多個(gè)實(shí)驗(yàn)），有些實(shí)驗(yàn)有效，有些實(shí)驗(yàn)無(wú)效。他們倆根據(jù)這些實(shí)驗(yàn)總結(jié)提煉出了一套適應(yīng)于大規(guī)模敏捷被稱之為L(zhǎng)eSS的方法，并寫成了兩本書(shū)，一本叫《精益和敏捷開(kāi)發(fā)大型應(yīng)用指南》，一本叫《精益和敏捷開(kāi)發(fā)大型應(yīng)用實(shí)戰(zhàn)》。然而之前的著作主要是分享LeSS具體的試驗(yàn)成果，比如哪些試驗(yàn)可以采納，哪些試驗(yàn)需要避免，這對(duì)于習(xí)慣于先了解總體后了解細(xì)節(jié)的人們來(lái)說(shuō)有點(diǎn)難入門。因此兩位創(chuàng)始人進(jìn)行了反思，并且認(rèn)可了“守破離”的方式，于是他們?cè)O(shè)計(jì)出了今天我們所看到的LeSS框架。我們只有了解完LeSS的歷史后，才能對(duì)LeSS全圖有更深刻的理解。
- 最外層是試驗(yàn)，也就是上面提到的Craig和Bas在LeSS實(shí)施期間做了600多個(gè)試驗(yàn)來(lái)驗(yàn)證；
- 往里面一層是指南，兩位創(chuàng)始人總結(jié)了大概50多個(gè)指南，并在他們的第三本LeSS著作《大規(guī)模Scrum：大規(guī)模敏捷組織的設(shè)計(jì)》中進(jìn)行詳細(xì)介紹；
- 再往里一層是框架，接下來(lái)我們會(huì)對(duì)LeSS框架進(jìn)行詳細(xì)的討論；
- 最里面一層是原則，Craig和Bas把LeSS設(shè)計(jì)的核心思想提煉了10條原則，我們將在下個(gè)小節(jié)介紹。
LeSS的原則一共有10條，我們可以把它們分成三類：
- 大規(guī)模Scrum也是Scrum——它不是新的被改進(jìn)的Scrum；
- 經(jīng)驗(yàn)性過(guò)程控制——Scrum本身就是基于經(jīng)驗(yàn)性過(guò)程控制。
- 以少為多——不想要增加更多的角色，因?yàn)闀?huì)導(dǎo)致團(tuán)隊(duì)的責(zé)任感變?nèi)酰徊幌胍嗟墓ぜ?，因?yàn)闀?huì)導(dǎo)致團(tuán)隊(duì)與客戶的距離更遠(yuǎn)；不想要更多的流程，因?yàn)閳F(tuán)隊(duì)對(duì)流程的所有權(quán)更弱。
- 整體產(chǎn)品聚焦——一個(gè)Product Backlog，一個(gè)Product Owner，一個(gè)PSPI，一個(gè)Sprint。
- 以客戶為中心——專注于了解客戶真正的問(wèn)題并解決這些問(wèn)題。
- 系統(tǒng)思維——觀察、理解和優(yōu)化整個(gè)系統(tǒng)而不是局部；
- 持續(xù)改進(jìn)以求完美——團(tuán)隊(duì)需要不斷地進(jìn)行改進(jìn)試驗(yàn)。
LeSS根據(jù)團(tuán)隊(duì)規(guī)模不同有兩個(gè)框架，一個(gè)是LeSS框架，適合2-8個(gè)Scrum團(tuán)隊(duì)；一個(gè)是LeSS Huge框架，適合8個(gè)以上團(tuán)隊(duì)。雖然兩個(gè)框架有所不同，但是它們還是有一些共同要點(diǎn)：
- 一個(gè)產(chǎn)品負(fù)責(zé)人和一個(gè)產(chǎn)品代辦事項(xiàng)列表；
- 一個(gè)跨所有團(tuán)隊(duì)的共同Sprint；
讓我們先來(lái)思考，當(dāng)一個(gè)項(xiàng)目只有一個(gè)Scrum團(tuán)隊(duì)的時(shí)候，毫無(wú)疑問(wèn)大家都比較熟悉了，在這里不再贅述。但是如果一個(gè)項(xiàng)目超過(guò)一個(gè)Scrum團(tuán)隊(duì)的范圍該怎么辦？很多人馬上會(huì)想到，那就組織多個(gè)Scrum團(tuán)隊(duì)一起工作唄。（比如3個(gè)Scrum團(tuán)隊(duì)）我們?cè)賮?lái)看Scrum中有個(gè)著名的“3355”的說(shuō)法，也就是Scrum里面包含3個(gè)工件、3個(gè)角色、5個(gè)活動(dòng)和5個(gè)價(jià)值觀。那么這時(shí)問(wèn)題就來(lái)了，對(duì)于多個(gè)Scrum團(tuán)隊(duì)一起工作，我們是需要1份總的Product Backlog還是保留3份各自Scrum Team的Product Backlog？抑或是1（總的Product Backlog）+3（每個(gè)Scrum team各自的Product Backlog）份？到底是1還是3還是1+3？不知道大家有沒(méi)有進(jìn)行深層次的思考？LeSS中的答案是只有1份Product Backlog。具體原因在呂毅老師的LeSS培訓(xùn)中花了大量的精力從系統(tǒng)思維的角度分析過(guò)。第二個(gè)問(wèn)題是PO需要多少個(gè)？只有1個(gè)PO還是每個(gè)Scrum Team有各自的PO？還是說(shuō)有一個(gè)總的大PO+3個(gè)Scrum Team的PO？當(dāng)然，LeSS中強(qiáng)調(diào)即使有多個(gè)團(tuán)隊(duì)，但是只能有一個(gè)PO，一個(gè)PO對(duì)應(yīng)一份Product Backlog才能保證整體產(chǎn)品聚焦，同時(shí)可以避免多PO職責(zé)不清的情況。同理可知，一份Product Backlog只對(duì)應(yīng)一個(gè)PSPI的輸出。而為了實(shí)現(xiàn)在每個(gè)Sprint結(jié)束后只有一個(gè)PSPI的輸出，所以3個(gè)Scrum團(tuán)隊(duì)需要有統(tǒng)一的開(kāi)發(fā)節(jié)奏，也就是說(shuō)Sprint的開(kāi)始結(jié)束時(shí)間必須拉齊，所以LeSS只能有一個(gè)Sprint；最后，如果輸出只有一份交付件的話，那Sprint Review Meeting也只需一次就行了。因此我們可以從客戶和產(chǎn)品為中心的維度拉出這樣的功能條目工作流：（1個(gè)）PO ->（1份）Product Backlog ->（1個(gè)）Sprint->（1份）PSPI ->（1個(gè)）Sprint Review Meeting接下來(lái)我們?cè)?/span>從團(tuán)隊(duì)的工作流角度來(lái)分析:我們知道現(xiàn)在有3個(gè)Scrum團(tuán)隊(duì)，每個(gè)團(tuán)隊(duì)各自做自己負(fù)責(zé)的工作。我們?cè)谧鯯print Planning的時(shí)候該怎么做？我們需要有一個(gè)所有人或者至少所有Scrum團(tuán)隊(duì)的代表能參加的計(jì)劃會(huì)，從而使得每個(gè)團(tuán)隊(duì)都能了解本次Sprint的目標(biāo)以及各團(tuán)隊(duì)知道該做什么條目，這也被稱為Sprint計(jì)劃一。當(dāng)然各團(tuán)隊(duì)領(lǐng)了具體工作條目后，具體的任務(wù)還需要每個(gè)團(tuán)隊(duì)自己回去商量，所以每個(gè)團(tuán)隊(duì)還會(huì)進(jìn)行Sprint計(jì)劃二；因此Sprint Planning變成了1+3。（如果有些需求在兩個(gè)團(tuán)隊(duì)之間關(guān)聯(lián)比較緊密的話，也可以兩個(gè)團(tuán)隊(duì)合在一起做多團(tuán)隊(duì)Sprint計(jì)劃二。）接下來(lái)我們看Sprint Backlog的份數(shù)，由于我們每個(gè)團(tuán)隊(duì)各自都會(huì)做Sprint Planning，毫無(wú)疑問(wèn)應(yīng)該每個(gè)團(tuán)隊(duì)各自有各自的Sprint Backlog，也就是說(shuō)Sprint Backlog應(yīng)該是3份。我們?cè)倏疵咳照緯?huì)，顯然各自團(tuán)隊(duì)可以自己開(kāi)每日站會(huì)，我們沒(méi)必要舉辦全體的站會(huì)，這會(huì)非常耗時(shí)。可能很多人會(huì)問(wèn)，對(duì)于有些任務(wù)會(huì)涉及到一些跨團(tuán)隊(duì)協(xié)作，該怎么辦？一但碰到需要跨團(tuán)隊(duì)協(xié)作的事情需要實(shí)時(shí)的進(jìn)行團(tuán)隊(duì)間溝通和協(xié)調(diào)，而不需要依賴某個(gè)固定的時(shí)間和會(huì)議再來(lái)討論。最后我們?cè)倏椿仡檿?huì)議。LeSS建議每個(gè)團(tuán)隊(duì)自己先開(kāi)團(tuán)隊(duì)的回顧會(huì)議，當(dāng)然有些措施可能涉及到跨團(tuán)隊(duì)，所以還會(huì)有一個(gè)全體的回顧會(huì)議，大家一起討論和改進(jìn)。所以我們根據(jù)團(tuán)隊(duì)數(shù)量的維度來(lái)分析得到以下的團(tuán)隊(duì)工作流：（多個(gè)）Scrum團(tuán)隊(duì)->（多份）Sprint Backlog->（1+多個(gè)）Sprint Planning->（多個(gè)）每日站會(huì)->（多個(gè)+1）Sprint回顧會(huì)。剛才我們?cè)谏厦娣治龅絃eSS只有一個(gè)PO，這對(duì)于在團(tuán)隊(duì)規(guī)模不大（小于8個(gè)團(tuán)隊(duì)，50人以內(nèi)）的情況下，PO還是勉強(qiáng)可以應(yīng)付的。但是如果團(tuán)隊(duì)規(guī)模變大，比如20個(gè)團(tuán)隊(duì)，那對(duì)于PO一個(gè)人來(lái)說(shuō)根本不可能協(xié)調(diào)得過(guò)來(lái)。雖然LeSS不提倡隨便增加角色，但是在目前這種情況下，確實(shí)只能妥協(xié)增加新的角色了。因此在LeSS Huge框架你可以看到，LeSS中唯一比Scrum多的一個(gè)角色就是Area PO（APO，領(lǐng)域產(chǎn)品負(fù)責(zé)人）。每個(gè)APO負(fù)責(zé)某個(gè)需求領(lǐng)域（Requirement Area），一般一個(gè)需求領(lǐng)域包括4-8個(gè)Scrum團(tuán)隊(duì)，這樣20個(gè)團(tuán)隊(duì)可能對(duì)應(yīng)了4個(gè)需求領(lǐng)域，有4個(gè)APO，還有一個(gè)PO，他們一起構(gòu)成了PO團(tuán)隊(duì)。在產(chǎn)品中需求領(lǐng)域范圍比較大且相對(duì)比較獨(dú)立。關(guān)于需求領(lǐng)域的顆粒度大小，我們可以拿滴滴打車軟件作為例子，在滴滴產(chǎn)品中，出租車是一個(gè)需求領(lǐng)域，順風(fēng)車可能是另一個(gè)需求領(lǐng)域。所以對(duì)于無(wú)論是Sprint計(jì)劃一還是Sprint Review會(huì)議，抑或是全體回顧會(huì)，這些我們都以需求領(lǐng)域作為范圍來(lái)組織即可。但是從整個(gè)產(chǎn)品層面來(lái)說(shuō)，我們只有一個(gè)PO，一份Product Backlog，一個(gè)PSPI。這里需要補(bǔ)充說(shuō)明的是盡管只有一份Product Backlog，但是每個(gè)需求領(lǐng)域可以有各自的領(lǐng)域產(chǎn)品代辦事項(xiàng)列表“視圖”，這個(gè)視圖和數(shù)據(jù)庫(kù)表的“視圖”是挺類似的含義，也就是本質(zhì)上這些視圖還是屬于Product Backlog，只是每個(gè)需求領(lǐng)域過(guò)濾掉和它無(wú)關(guān)的條目而已。關(guān)于LeSS如果開(kāi)展，官方教材給了指導(dǎo)方法，步驟如下：
- 組建結(jié)構(gòu)合理的團(tuán)隊(duì)；
- 只有產(chǎn)品負(fù)責(zé)人為團(tuán)隊(duì)提供工作；
- 讓項(xiàng)目經(jīng)理遠(yuǎn)離團(tuán)隊(duì)。
其中第5和第6個(gè)步驟更像是rule，第5個(gè)主要是確保PO作為唯一人員為團(tuán)隊(duì)提供工作，使得團(tuán)隊(duì)能集中注意力，而且?guī)椭鷪F(tuán)隊(duì)減輕來(lái)自外部的壓力；第6個(gè)主要是項(xiàng)目經(jīng)理的責(zé)任已經(jīng)由PO和團(tuán)隊(duì)來(lái)共同分擔(dān)掉了，也就不需要項(xiàng)目經(jīng)理了。上面是“官方”的教程，但是個(gè)人覺(jué)得呂毅老師分享的在某個(gè)客戶做LeSS實(shí)踐的啟動(dòng)策略更加的接地氣，如下圖：- 首先，對(duì)所有團(tuán)隊(duì)進(jìn)行1天的培訓(xùn)，培訓(xùn)完后根據(jù)經(jīng)驗(yàn)，一般80%的團(tuán)隊(duì)沒(méi)有反饋，20%的團(tuán)隊(duì)會(huì)考慮下一步；
- 其次，會(huì)有一段時(shí)間的等待，需要客戶內(nèi)部進(jìn)行討論和準(zhǔn)備，確定哪些項(xiàng)目來(lái)試行LeSS。這段時(shí)間可長(zhǎng)可短，一般需要1-3個(gè)月；
- 再次，確定好試點(diǎn)項(xiàng)目后，需要進(jìn)行一系列準(zhǔn)備過(guò)程，包括：1）針對(duì)試點(diǎn)項(xiàng)目進(jìn)行培訓(xùn)；2）定義產(chǎn)品列表，這個(gè)可能是initial的產(chǎn)品列表；3）做好技術(shù)相關(guān)準(zhǔn)備，比如單元測(cè)試框架，自動(dòng)化框架，CI/CD等。這個(gè)時(shí)間大概會(huì)有幾個(gè)星期。
- 最后，是flip階段，大概是2天時(shí)間?？赡芾冒胩鞎r(shí)間進(jìn)行LeSS團(tuán)隊(duì)的組建，然后做LeSS Sprint前的準(zhǔn)備。兩天后就正式進(jìn)入LeSS的Sprint節(jié)奏中了。
我們知道規(guī)?；艚萦胁煌目蚣埽薒eSS之外，也有SAFe、Scrum@Scale等。我在一年前寫過(guò)一篇文章《規(guī)?；艚軸AFe和LeSS的同與不同》，闡述了SAFe和LeSS在設(shè)計(jì)思維層面的相同之處以及不同的地方，這次培訓(xùn)讓我又有了新的體會(huì)。
結(jié)合之前與不同企業(yè)交流以及咨詢的經(jīng)驗(yàn)，個(gè)人覺(jué)得LeSS適合于組織結(jié)構(gòu)比較扁平或者包袱不重的企業(yè)，比如原來(lái)規(guī)模不大但現(xiàn)在正在擴(kuò)張的企業(yè)，特別是互聯(lián)網(wǎng)企業(yè)會(huì)更加適合。LeSS的核心理念是盡量不增加角色，這使得原來(lái)沒(méi)有那么多包袱沒(méi)那么多角色的組織實(shí)施起來(lái)阻力較少。而SAFe是通過(guò)增加層級(jí)來(lái)解決規(guī)模化問(wèn)題，增加層級(jí)也意味著增加角色，所以對(duì)于原本包袱比較重，組織層級(jí)比較多的企業(yè)（比如大型國(guó)企）來(lái)說(shuō)，能夠使得不同的人在SAFe框架中找到自己的位置，從而不會(huì)產(chǎn)生危機(jī)感而阻止敏捷的變革。當(dāng)然這只是一家之談，作為一個(gè)參考信息給到大家，具體判斷和決定留給各位親愛(ài)的讀者。3月每周四晚8點(diǎn)，IDCF【冬哥有話說(shuō)】將解讀四位國(guó)際大咖的經(jīng)典演講，一起精進(jìn)#敏捷#DevOps。
第4期，今晚8點(diǎn)，王立杰老師解讀規(guī)?；艚軸AFe聯(lián)合創(chuàng)始人Dean Leffingwell《業(yè)務(wù)敏捷，贏得數(shù)字化時(shí)代》。關(guān)注公眾號(hào)回復(fù)“牛上加牛”獲取直播地址哦~
