精益敏捷轉型聽起來很容易，但做起來很難，很多組織在數字化轉型的過程的早期，一到兩個團隊作爲試點團隊進行敏捷轉型，都能獲得不錯的轉型效果。隨着轉型的持續推進，涉及到越來越多的團隊轉型，這時就會暴露出早期沒有發現的一些問題。我們經常說量變引起質變，如何保證組織轉型過程中，大團隊從傳統的瀑布式開發轉變到精益敏捷模式的開發呢？今天我們不談理論，不談框架（SAFe，LeSS），我想從一個實操的方面來剖析一些我們實際遇到的困難和一些應對策略。
我們從以下4個方面來分析：
- 產品規劃
- 多開發團隊的協同
- 集成與測試
- 上線交付
我們知道在傳統瀑布模式下會產生如下的一些問題
- 產品規劃：規劃流程長耗時，反饋慢，交接成本高，用戶價值被工作交付物替代， 戰略目標和價值息被衰減。
- 多開發團隊的協同：研發流程長，問題到測試纔會被發現，相互依賴嚴重，聯調成本高，項目管理成本高。
- 集成與測試：集成耗時長，集成質量不好，修復問題繁瑣，全流程測試缺失
- 上線交付：上線時間長， 上線後不穩定，上線失敗。
造成這些問題的主要原因：
- 角色劃分工作範圍（內心：我只做這個）
- 部門牆重（內心：不是我的目標）
- KPI導向（內心：我只考慮完成我的指標）
- 角色技能單一（內心：我只會做這個）
- 任務依據技術分類拆分（UI，後臺服務…)
- 節奏對不齊（我沒時間聯調）
- 系統關聯依賴多（你先上API，我在上UI）
- 溝通不暢（內心：不要說出全部事實）
這些方面只是軟件開發中很多問題的一個縮影，現在來讓我們看看精益敏捷如何在這些方面幫助團隊更好的完成工作。
首先我們一起看一下，一個敏捷團隊如何在上面的幾個方面提供更好的工作模式？
讓我們來看看大致的過程：
- 產品規劃有PO(產品擁有者）來負責規劃，PO會在需求澄清會議上給團隊（開發，測試，UX）講解要實現的功能，
- 團隊負責需求的開發，測試，交付。開發每日多次提交代碼構建軟件產品，進行持續集成和部署
- 測試同學前移到需求分析過程，參與需求討論並輸出測試用例，每天一旦發現缺陷，立刻快速修復，重新測試驗收
- 在迭代最後，由團隊給PO進行迭代演示，PO驗收用戶故事同時給出反饋結果。
- 團隊一起對開發流程，協作回顧，找出浪費的地方，進行改進
這看起來還不錯，團隊解決了上面說的的那幾個問題，
- 提高了交付價值的能力，由PO全生命週期負責產品。
- 減少了協同管理成本，團隊具有獨立交付能力
- 縮短了交付週期，減少了各種浪費（精益-7個原則：消除浪費).
- 提高了質量，頻繁進行構建和自動化測試，更早發現Issue.
這樣的團隊符合精益敏捷的小團隊運作，是比較理想的一種狀態。但真實情況比這複雜很多，一個產品可能有很多這樣獨立自主的跨職能團隊組成。這麼多獨立的跨職能的小團隊，他們按上述過程完成自己的工作，是否就能實現產品的整體目標？答案是否定的，
首先我們建議在多團隊下，請按照下圖的架構來組建團隊和團隊與團隊之間的關係。
優勢在於：
- 跨職能獨立的團隊，減少團隊之間依賴等待的浪費
- 產品領域按業務垂直拆分，可以交付完成的客戶價值
- 由領域PO，領域DM負責整體業務和整體開發計劃，各團隊目標對齊，減少摩擦
- 領域內角色橫向的虛擬組，建立起了連接，增強了整體協同能力
- 對於更大規模的業務，橫跨多個業務領域，可以快速橫向擴展
各個團隊交付用戶價值和產品整體戰略規劃對齊
當多個團隊負責一個產品的時候，這個功能有那個團隊負責，誰考慮整體產品價值等，都需要面對解決。首先從組織戰略規劃層面上明確商業願景，通常我們使用EDGE中的精益價值樹（LVT）來梳理願景， LVT始於組織的最高層，一層一層傳遞，再反向傳遞成果。
其次當產品戰略和目標清晰後，承接舉措的就是一到多個跨職能團隊。這些跨職能的團隊根據自身的能力來和這些獨立的小塊工作對齊。 每一份工作都代表了相對對立的用戶價值。 這些用戶價值組合在一起整體實現了產品價值。
多團隊的開發協同
- 多個團隊服務一個產品時，迭代的節奏要對齊，同時啓動迭代，同時結束迭代，好處在於多團隊是按照同樣的時間週期開發，容易對齊各個團隊規劃。在交流溝通時，大家是基於一個時間週期概念在討論。
- 多個團隊服務於多個產品時，這種情況就比較複雜。建議梳理團隊工作，儘量支持一個產品領域，這時需要重新考慮各個團隊承接的產品。
- 一個團隊對應多個產品線，例如：基礎架構團隊，他們提供基礎架構支持多個產品。這種情況下，有兩種建議，
第一種拆分團隊，把基礎架構工作分散在各個團隊中，這時團隊依賴基礎架構團隊的情況就減少了。但同時也帶來了另一個問題，就是基礎架構沒有統一規劃標準，解決這個問題可以在各個對立團隊中，建立橫向的虛擬的架構守護組。
第二種建議，如果組織無法拆分基礎架構團隊，那基礎架構團隊就要把自己的工作當成產品來管理，就是說這個團隊有着自己的架構規劃和研發節奏。團隊需要有相關產品PO，根據組織戰略和各個產品特點來規劃基礎架構或基礎服務。定期發佈最新的服務能力。這類似微服務團隊或現在比較熱的中臺研發團隊。
在開發階段，團隊裏的各個角色都可以組建成橫向的虛擬小組。這和Scrum of Scrum有着異曲同工的左右。 爲什麼要組建這些橫向的虛擬小組呢？ 因爲單個獨立的團隊好比羣山中的一角，團隊只能看到自己，對於整體無法知道，現在在團隊層面上，各個團隊的角色橫向建立小組，就是讓每個團隊信息共享給其他團隊，使單個團隊具備了上帝視角。可以看到一個產品的全貌，從而更好的完成自己的部分。
集成與測試
在多團隊下，持續集成的技術就顯得更爲重要了。 團隊對自動化建設需要持續投入，包括（代碼倉庫，自動化編譯和構建，自動化測試，自動化部署等）關於持續集成技術有很多書和資料，這裏就不在詳細介紹。 但我們想表達的，團隊需要投入一定資源在自動化程度的提高上面。一開始投入大於收益，但隨着持續的建設，慢慢收益會大於投入。這裏就需要一些策略，每一個迭代新增的故事都要有自動化測試跟上，對於已有的功能，構建主線流程測試，同時還構建了基本的冒煙測試。同時還需要培訓測試人員如何寫自動化代碼。這些都需要領導的支持和組織的遠見。
上線交付
多團隊下的上線一直就是一個挑戰。主要是每個團隊只完美的完成自己的部分，對於依賴的部分由於信息溝通問題導致接口無法對齊或接口缺失，或全流程功能無法打通。
這裏的建議就是：
- 在測試層面，各個團隊的測試組成的橫向虛擬小組來解決全流程測試案例的設計和執行。
- 在需求分析設計層面，由PO組成的團隊負責整體功能的規劃和拆分。
- 開發層面利用持續集成的技術，每天進行產品構建部署。縮短集成周期，減少代碼衝突，提前自動發現程序接口問題。
當我們建立了持續集成流水線以後，我們要求每天數次的代碼提交到主幹版本，通過所有測試後自動部署到測試環境。 這樣大大加快了功能集成。當我們要進行發佈時，我們只需要在某個時間節點進行代碼凍結，然後立刻生產新的發佈分支，進行編譯構建發佈版本。這一過程在數小時之內就可以完成。
總結
以上是我們在大團隊轉型時遇到的實際問題，給出的建議大家可以參考，但切記不要複製，你可以從這些經驗上找到自己組織的轉型之路，因爲轉型需要文化、認知的轉變，這些是無法複製的。你需要像煲一鍋靚湯一樣，高級食材已準備好，需要耐心，小火慢燉，讓這些食材的精華逐漸融入進你的組織。
文/ThoughtWorks曹志強
更多精彩洞見，請關注微信公衆號：ThoughtWorks洞見