如果你知道敏捷開發(fā)，Scrum你一定不會陌生。

如果你知道敏捷開發(fā)，Scrum你一定不會陌生。從上世紀 90 年代初開始，Scrum 框架在全球范圍內已得到了廣泛應用，有報告顯示全世界范圍內采用敏捷開發(fā)模式的公司里有68%以上使用Scrum框架。Scrum團隊中包括：

1. 產品負責人
2. 開發(fā)團隊
3. Scrum Master

1. 待辦列表
2. Sprint待辦列表
3. 潛在可發(fā)布產品增量

Sprint是Scrum 的核心，其長度為1～4周的一個固定長度時間盒，這段時間內構建 一個“完成”、可用的和潛在可發(fā)布的產品增量。在Scrum指南中定義了：

1. Sprint計劃會議
2. 每日站會
3. Sprint評審會議
4. Sprint回顧會議

在常見的實踐中通常會在Sprint周期中間增加一個產品待辦列表Refinement會議，用以初步討論澄清下一個Sprint潛在要做的用戶故事?？雌饋硎遣皇呛芎唵?？Scrum是一個輕量的，易于理解但難以掌握的敏捷框架。

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

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

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

行業(yè)里目前有一些大規(guī)模敏捷的解決方案，如 Large Scale Scrum（LeSS）， Scrum of Scrums， Scaled Agile Framework（SAFe）， Disciplined Agile Delivery（DAD），NEXUS等等。這里簡單介紹一下LeSS這個框架，當年在NOKIA的時候用的就是這套框架。

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

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

筆者去年的時候接手了一個研發(fā)團隊，準備開發(fā)一個公司內部DevOps研發(fā)平臺產品。團隊成員包括3個前端JS開發(fā)，9個后端JAVA開發(fā)，1個測試，1個交互；前后端分離設計，前端基于React，后端基于SpringBoot；團隊成員幾乎不懂敏捷開發(fā)，Scrum以及LeSS等。如果是你，你會如何開始？

沒有合理的團隊設計讓產品研發(fā)事倍功半，而有了合理的團隊設計讓團隊事半功倍。團隊設計是影響團隊績效的一階因素。團隊設計簡單說包含兩方面考慮，一個是團隊自身結構的設計，一個是團隊間溝通協(xié)調方式設計；團隊自身結構設計上通常有兩種選擇：組件團隊或特性團隊。

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

組件團隊缺少產品整體視角，關注組件交付而非客戶價值交付；常見的句式是：“我的做完了”。

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

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

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

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

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

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

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

當需求被拆分到各個組件團隊后，帶來的另外一個后果是后期集中集成，集中測試，反饋周期往往拉長，并且將風險留在最后，往往導致項目延期，交付周期變長。

相對于組件團隊，特性團隊：

• 長期穩(wěn)定存在，長期的合作利于打磨高效團隊，質量和效率穩(wěn)定可預見。
• 跨技能，團隊成員技能中包含前端，開發(fā)，測試等多種技能。
• 跨組件，團隊覆蓋的范圍同時橫跨多個組件。
• 團隊能獨立完成客戶價值交付。
• 團隊間協(xié)調合作從項目管理域轉移到代碼技術域。

當然特性團隊也帶來了一些挑戰(zhàn)：

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

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

整體上特性團隊對外更加關注客戶價值價值，促進創(chuàng)新；對內打破團隊邊界，促進組織轉型升級；對個人促進個人學習，提升個人技能。

敏捷原則之一“我們最重要的目標，是通過持續(xù)不斷地及早交付有價值的軟件使客戶滿意?！睂τ谝粋€從0到1的產品，持續(xù)不斷的滿足客戶需求，持續(xù)不斷的從客戶收集反饋對于產品來說非常重要，特性團隊更適合當前的產品研發(fā)場景。筆者選擇組建了三個特性團隊，每個團隊4人，其中包含前端開發(fā)，后端開發(fā)，可以獨立完成產品需求交付。

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

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

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

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

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

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

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

完成了團隊自身結構設計以及產品需求組織結構設計之后，那么團隊之間如何在LeSS框架下協(xié)助完成一個產品從0到1的開發(fā)呢？敬請期待大規(guī)模敏捷開發(fā)框架LeSS實踐（二）。

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

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