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