本文摘於《軟件研發效能權威指南》——第 9 章
核心觀點
- 開發人員在多個“單點式”工具平臺之間的來回切換是很耗費時間和精力的。
- “一站式”是指把研發各個環節的軟件工程能力集成在一個統一的平臺上，對新人友好，對老人提效。
- “一鍵式”是指讓研發工程師只關心具有創造性價值的工作，而不需要處理能夠由研效平臺自動完成的事情。
- “雙流”模型可以實現需求價值流和研發工程流雙向自動聯動。
傳統單點研發效能工具平臺面臨的挑戰
一個完整的研發效能工具平臺，需要包括需求協作、代碼管理、構建能力、測試能力、環境部署能力、製品管理、配置管理、監控告警、高效運維等功能。可以說，效能工具平臺是研發工作開展的載體，涵蓋了軟件研發全生命週期的各個環節，其設計與使用體驗做得好，整體研發過程的流暢度就高，工程師的有效價值就能更好地被髮揮。
軟件研發全生命週期中的各個環節都有各自領域的單點工具，比如需求管理工具常用的是 Jira、代碼管理工具常用的是 GitHub 和 GitLab 等，這些垂直領域的單點工具平臺不論是商業化產品，還是企業自研，基本都是以 SaaS 的形式在企業內爲廣大工程師提供服務。
開發工程師要完成一個需求開發任務，往往需要在多個單點垂直工具間來回反覆切換。當我們的軟件工程紀律和流程管控越嚴格時，工具來回切換的次數就會越多，而且每次切換都可能需要以人工的方式在各個工具平臺間傳遞信息，甚至是“翻譯”信息。
比如，在一個典型的開發任務場景中，開發工程師首先要訪問需求管理工具，從中找到對應的任務項，然後將其狀態從“待開發”轉變爲“開發中”，接着到代碼管理工具中找到對應的代碼倉庫並下載代碼。同時，先使用需求管理工具中的開發任務 ID 作爲分支名字來創建功能分支，然後在該功能分支上完成本地的開發與測試工作。在此期間，爲了做到質量左移，往往會在開發過程中使用遠程靜態代碼掃描工具中的代碼規則，在本地執行靜態代碼檢查，同時也會使用 Mock 能力來完成本地的單元測試。當本地開發和測試達到質量要求時，就會先通過代碼工具提交代碼評審，然後在工具平臺的支持下完成代碼評審的交互，之後代碼合流過程中會使用 CI 平臺來執行流水線，流水線完成一系列的步驟（如單元測試、靜態代碼掃描、安全掃描和編譯等），並且達到質量門禁的要求後，會將產生的製品存入製品庫。最後，開發工程師還需要再次訪問需求管理平臺，找到之前的任務，並將任務的狀態從“開發中”設置爲“待測試”。
我相信，很多開發人員對以上過程已經很熟悉了。在這個過程中，除了業務代碼開發和測試，你需要和各種工具平臺頻繁打交道，需要訪問需求管理平臺領取任務，需要訪問代碼管理工具拉取代碼並創建分支，需要調用靜態代碼掃描平臺的能力，還需要使用 CI 平臺和製品庫的能力，最後還要再次訪問需求管理平臺更新任務狀態。
在這個過程中，有多次工具切換，要花費大量時間在流程性的事務上，造成時間和精力的浪費，還需要你對各個工具平臺的使用方法和流程都很清楚。
更糟糕的是，各個工具平臺的概念模型可能還不完全一致。比如代碼管理平臺上的“項目”概念和測試平臺上的“項目”可能就不是相同邏輯下的概念；再比如“應用”的概念在不同的工具平臺上可能不是一個意思，這就使研發過程的流暢性大打折扣，工程師的理解和學習成本很高。同時，各個工具平臺之間還會形成研發數據孤島，很難進行統一的研發過程數據收集和度量。因此，我們迫切需要“一站式”和“一鍵式”的統一研發效能平臺對各個工具平臺進行橫向整合和拉通，以此來提升研發過程的整體效能。
“一站式”和“一鍵式”
“一站式”的概念
“一站式”是指把研發各個環節的軟件工程能力集成在一個統一的平臺上，研發工程師在研發過程中不再需要來回訪問多個工具平臺，也不需要人工記住並遵守研發流程，更不需要記住多個工具平臺的訪問入口，這樣的設計對新人友好，對老人提效。
具體來講，就是研發工程師不需要記住每個單點工具平臺（比如，需求管理系統、CI 系統、自動化測試系統等）的域名，在一個統一的研效平臺上完成所有的研發任務，而且各個階段的產出物也能更加順暢地在各個工具平臺間流動。這樣，不僅能統一各個工具的權限管理體系，還能讓研發過程的度量數據收集實現自動化，不需要任何人爲干預，而且各個工具中的概念名詞也能在一站式的理念下得到統一，研發的各個階段能夠實現無縫鏈接與協作，實現真正意義上的研發全流程流水線。
“一鍵式”的概念
有“一站式”作爲基礎，就能在此基礎上進一步實現“一鍵式”。“一鍵式”是真正提升研發效率的利器。
“一鍵式”是指讓研發工程師只關心創造價值的工作內容，比如聚焦於架構設計、編寫代碼、編寫單元測試用例、開展代碼評審等活動；而不需要處理能夠由工具平臺自動完成的事務性工作，比如需求狀態流轉、代碼分支創建、靜態代碼檢查、測試環境搭建、應用部署、測試用例執行等。
“一鍵式”最理想的效果是用戶在提交代碼後，可以不需要人工來完成後續的事務性工作，也不需要再盯着整個流程等待下一步，而是可以轉向處理其他事情，研效平臺會自動執行靜態代碼掃描和單元測試、判斷質量門禁、構建制品、將製品部署到測試環境且執行接口測試，接着將製品部署到預發佈環境，經過自動化的系統測試後，最終實現生產環境的正式發佈，在此過程中會運用灰度發佈等機制來降低風險。在整個過程中，只有出現錯誤時才需要研發工程師介入處理，真正意義上實現了“一把梭”。
研發效能平臺的“雙流”模型
本書提出的研發效能“雙流”模型是“一站式”和“一鍵式”概念的最好詮釋。“雙流”模型包含需求價值流和研發工程流，其中需求價值流是產品經理和項目經理關注的視角，反映了各個需求的完成狀態和項目整體的完成情況；研發工程流是研發工程師關注的視角，反映了開發任務在工程維度上的完成狀態，更多是從代碼、測試和 CI/CD 等工程視角來看任務的進展。
研發效能“雙流”模型實現需求價值流和研發工程流雙向自動聯動
需求價值流和研發工程流雙向自動聯動
在“雙流”模型中，可以實現需求價值流和研發工程流雙向自動聯動，不需要研發工程師在完成開發和測試任務後單獨到需求管理系統中去更新任務狀態，需求的狀態更新（比如，需求狀態從“開發中”轉到“待測試”）由代碼分支合併進主幹後自動流轉，不需要人工參與，這樣就能讓研發工程師更好地聚焦在創造價值的工作上。
“雙流”模型是實現研發效能平臺的一個參考依據，值得借鑑。以下就通過具體例子介紹“雙流”模型的工作原理和實現方式。
首先，在一個研發迭代週期開始之前，我們會從 Backlog 中選擇迭代需要完成的需求任務列表，並將每個需求分解成開發任務。在理想的情況下，我們儘可能把每個開發任務的顆粒度都控制在一個代碼倉庫的範圍內，如果某個業務需求的實現需要涉及多個服務模塊（如多個微服務模塊）的改動，則建議爲每個模塊創建一個開發任務。也就是說，建議創建多個獨立的開發任務，以開發任務爲單位進行迭代計劃的安排，並且每個開發任務都會事先確定好開發工程師的人選。
在傳統模式下，在一個迭代開始後，被分配任務的開發工程師就會收到系統郵件通知，再根據郵件中的鏈接到需求管理工具中閱讀並理解該需求，並且手動設置任務的狀態爲“開發中”，然後去代碼平臺拉取相應的代碼，創建開發分支，之後在 IDE 中開始開發和測試工作。但是以“雙流”模型實現的效能工具平臺就會簡單很多，完全不需要在需求管理工具、代碼平臺工具和 IDE 之間切換，只需要在 IDE 中即可完成全部工作。具體的過程如下：
在一個開發任務被分配給某個開發工程師後，該工程師所使用的 IDE 中就會通過研效平臺的 IDE 插件收到任務分配通知，工程師可以直接在 IDE 中閱讀需求詳情並一鍵領取任務，這一領取行爲首先會自動把對應代碼倉庫的代碼拉取到 IDE 工作區，然後會自動以需求任務 ID 爲名字創建代碼的功能分支，並確保 IDE 已經切換到該分支。同時，會自動調用需求管理平臺的 API 接口，將該需求任務的狀態從“待開發”轉爲“開發中”。這一系列的行爲都直接由研效平臺 IDE 插件自動發起，對開發人員來說做到了完全透明，其要做的只是簡單地在 IDE 中一鍵領取任務，就可以聚精會神地在本地進行開發和測試工作了。
在本地開發和測試任務完成後，當前的功能分支達到可交付狀態時，由開發工程師在 IDE 中直接發起代碼合流請求，該代碼合流請求會先被研效平臺中的 CI 子系統接管，然後 CI 子系統自動發起代碼評審流程，代碼評審的交互過程可以直接集成在 IDE 中完成。同時，研效平臺工具能自動根據代碼變更的 Code Diff 自動推薦最佳的評審人。比如，將最近這段時間改過相同邏輯的工程師作爲評審人是一個很經濟的選擇，因爲其認知成本是最低的。更進一步，研效平臺工具還會對此次代碼評審變更的大小進行標識，以便評審人可以根據其空閒時間片段的大小來選擇合適的評審內容。代碼評審完成後，CI 子系統會自動觸發 CI 流水線完成常規的單元測試、靜態代碼掃描，並且判斷質量門禁的達成情況，最後生成製品並上傳至製品庫。接下來，研效平臺工具會再次自動調用需求管理平臺的 API 接口，將該需求任務的狀態從“開發中”轉爲“待測試”。
研發流程的後續環節也會採用類似的聯動設計，用系統化的工具能力來保證需求狀態和代碼實際狀態的聯動。
由此可見，以“雙流”模型理念打造的研發效能平臺可以讓工程師聚焦在最關鍵的核心任務上，而不需要人工去做事務性的工作，讓整個研發過程的價值流動更順暢，進而提升團隊的研發效能，再次驗證了“工欲善其事，必先利其器”。
軟件研發各個階段的高效實踐
除此以外，“雙流”模型還明確定義了軟件研發各個階段的高效實踐。比如，在需求階段有哪些最佳實踐可以從源頭上保證效能，在本地開發和測試階段有哪些實踐可以保證質效提升，在代碼合流階段有哪些高效實踐等，本書第 2 篇介紹的研發效能實踐其實就是“雙流”模型各個階段的具體實踐與落地，這裏不再詳細介紹。
研發效能“雙流”模型明確定義了軟件研發各個階段的高效實踐
總結
這部分介紹了傳統單點研發工具平臺在橫向拉通維度上的痛點，並在此基礎上提出了研發效能平臺“一站式”和“一鍵式”的概念。同時，介紹了這一概念的落地案例：研發效能“雙流”模型，並且對“雙流”模型中的需求價值流和研發工程流雙向聯動能力進行了介紹。
