作者 | 阿里文娛技術專家 成文
研發效能期望
隨著敏捷、DevOps 等概念的興起，研發效能成為企業關注的重點，但是研發效能面臨的問題和挑戰也與日俱增。尤其在互聯網行業，版本需要快速迭代，業務與系統越來越複雜，質量和效率經常被放到對立面，隨著團隊規模越來越大，成百上千人的高效協同面臨巨大挑戰，研發效能導致的問題形成惡性循環。
本文將結合優酷近兩年遇到的研發效能問題分享一下優酷在研發效能領域的實戰經驗。
問題與挑戰
隨著移動時代的到來，優酷的主戰場也聚焦到以手機、Pad 為主的小屏客戶端，以及家庭 電視的大屏客戶端。在移動端領域，因為 UI 交互變化快，自動化維護成本高，行業普遍還是以手工測試為主，大部分團隊的開發質量意識薄弱，甚至不自測也不提測，研發流程混亂，溝通 成本高。在整個研發過程中每個團隊都覺得自己繁忙且“高效”，然而站在全局視角團隊整體的研發效能卻顯得非常遲緩。針對這些問題，大家通常會想到以下三個方案：
1）規範流程，與開發達成一致，形成文檔，大家按照約定執行；
2）數據驅動，通過收集各種數據反映研發效能問題，改進不足；
3）自動化，把日常部分重複工作轉化成自動化腳本，降低迴歸成本。這三個方案在初期比較容易取得一些效果，但是到了中後期各自的新的問題和挑戰就會逐
漸凸顯出來：
1）流程規範靠約定，執行效果很難量化；執行完全依賴個人，約束力不強；
2）數據顆粒度比較粗，反應的問題比較片面；數據與研發流程脫節，很難形成驅動力；另 外，數據的收集成本也在持續增加；
3）自動化一直在投入，但是取到的效果很難衡量；與研發流程脫節，關鍵節點依靠人來銜 接，自動化的價值難以發揮。
優酷最佳實踐
為研發效能提效，優酷也是圍繞上面三個方案展開，只不過我們巧妙的把三個方案融合成 一個方案，並融入到不同的研發流程當中。
1. 提測流程
我們首先做的就是把提測流程平臺化，把線下的文檔形式的規範搬到線上。不走線上提測 拒絕測試，把必須提供的信息設置成必填項，不滿足提測要求的提測單打回，在很短時間就統 一了所有業務線的提測標準。
我們打通了打包平臺和需求管理平臺，對於開發來說只要選包選需求提測即可，大部分提 測單中的信息可根據包信息和代碼變更信息自動彙總，反而給開發減少了很多額外的工作。測試收到提測單掃碼安裝下載後測試，再給測試結論即可。
其次，還有提測卡口功能。測試可以提供手工自測用例給開發，開發在提測時必須先完成 手工用例並通過所有測試才能提測。因為直接融入在提測流程中，所以約束力非常強，讓開發 被動提高質量意識。
再次，更酷的是提測流程與自動化融合。與自動化平臺打通後，自動化不僅作為測試的一 種減輕迴歸成本的工具，更作為一種服務化的能力融入到流程中。比較常見的套路是：提測後 自動觸發冒煙自動化，通過後才發送提測通知，再自動觸發已配置的其他類型的自動化任務， 如穩定性測試、功能迴歸、性能迴歸等。當然開發也可以在提測前選一個包就直接使用這些測 試服務，自動化的價值被充分挖掘出來。提測流程，如下圖所示：
最後，在平臺的使用過程中自動沉澱了非常多的數據，提測次數、提測通過率等對測試形 成比較好的保護，開發的質量意識增強。
2. 移動端研發 Pipeline
隨著業務複雜度增高，團隊規模擴大，每個版本參與集成的模塊可能多達上百個，研發過 程各環節都可能成為瓶頸，高效協同僅靠提測流程很難保證。我們依舊採用三合一的策略，只 不過把整個研發流程，從需求確認到提測到集成到發佈全部搬到線上，串聯打通各個平臺，實 現研發流程的全面數字化。如下圖所示：
首先，建立好產品、業務、版本、提測區的基礎關係。PMO 在產品中新建版本，各業務接 口人在業務中新建提測區並關聯所屬產品的版本，產品在提測區關聯的需求項目裡確認需求， 開發在提測區提測，測試在提測區關聯的缺陷項目中管理缺陷。不同角色依舊在各平臺按照自 己的方式工作，只不過因為我們維護了研發流程中數據的關係，數據的意義變得大不一樣：
1）數據不需要刻意去手工收集，在日常工作中自動沉澱，在版本視角自動彙總各業務情況；
2）數據不是孤立的點，可以傳遞給上下游。比如產品在需求管理確認需求，開發在提測環 節直接選需求提測，提測以後狀態可再同步至需求管理平臺；
3）數據融入在流程裡，作為關鍵環節的卡口，驅動力強，不需要等到版本覆盤的時候才看。
其次，建立 Pipeline 的過程其實就是在建立各階段標準的過程，結果不好往往是過程做的不到位。就好比“束水攻沙”，定好標準收緊河道，讓水流動更快，把問題和風險儘早暴露出來。以缺陷關閉率為例，如果業務在缺陷關閉率不達標的情況下參與集成，集成效率一定很低，但 實際上這個問題應該在開發測試階段就解決好。通過設置缺陷關閉率的集成卡口，在集成階段 到來就前提前預警，讓開發和測試人員儘早解決缺陷關閉率不達標的問題。經過一段時間的實 踐，我們各業務在集成階段的缺陷關閉率達標情況得到明顯改善，集成效率也得到顯著提升。
最後，研發流程各個環節都可以與自動化有機結合，有更靈活的觸發規則：集成自動觸發、 迴歸通知自動觸發、灰度發佈自動觸發等。對於性能自動化的結果可以基於版本設立基線，與 自己與行業對比，自動生成版本性能報告。
研發流程規範、數據驅動、自動化三者關係密切，相輔相成，研發效能改進需要有全局視 野，需要結合研發流程讓規範落地，需要結合數據驅動變得更智能，需要結合自動化進一步釋 放人力，三者融為一體才能更好形成研發效能持續改進的動力。
研發效能展望
研發效能改進和看病救人有很多相似之處，講究望聞問切，對症下藥。兩千多年前，《黃帝 內經》就提出“上醫治未病，中醫治欲病，下醫治已病”的理論。目前我們才剛剛摸到“中醫治欲病”的門檻，但是要達到“上醫治未病”，研發過程還需要不斷往前，從編碼設計、從系統 架構、從需求上入手，做到防患未然。
閱讀更多 CSDN 的文章
