這是鼎叔的第一百一十八篇原創文章。行業大牛和剛畢業的小白，都可以進來聊聊。
歡迎關注本專欄和微信公眾號《敏捷測試轉型》，星標收藏，大量原創思考文章陸續推出。本人新書《無測試組織 - 測試團隊的敏捷轉型》已出版（機械工業出版社），文末有連結。
前文 聊聊軟體生命週期中的度量指標 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484754&idx=1&sn=6fe0d88765436de0f4e431211fa5a3f9&chksm=c24fb030f538392679597e9a3d16529821b5d35eed155dc52abdc560ce6407642cb44dbf1670&scene=21#wechat_redirect， 介紹了軟體生命週期各個階段的核心指標，非常詳細了，但這系列指標是從需求研發（事）的角度來開展度量改進活動，還不能滿足管理層的所有需求，我們還可以從管理者角度來度量團隊（人）的健康度。我們這篇具體聊聊研發工程成熟度，參考阿里巴巴的卓越工程度量經驗，每個公司可以裁剪適合自己的度量公式。
阿里巴巴集團的卓越工程度量
阿里巴巴和螞蟻集團在全集團所有事業部（BU，約 30 多個）推行了三年的卓越工程建設，整體而言沒有收到負面看法，收穫成果還是不錯的。
作為強業務導向的研發團隊，業務交付永遠是最重要的，而對卓越工程的重視程度一般。當業務壓力大時，能夠用於自身工程能力建設的精力也很有限，還技術債的投入比重不高。
但是，只要有清晰的成熟度度量方法，可以用低成本引導技術團隊自行改進薄弱地方，加強內功。
整體度量框架說明如下：
一： 以團隊為單位進行研發指標度量，最終給團隊一個工程成熟度（卓越工程）評分和評級。
評分是 100 分滿分制，例如，95 分以上是 “大師” 等級，85-95 分是 “精英” 等級，60-85 分是 “良好” 等級，40-60 分是 “普通” 等級，40 分以下是 “初始” 等級。
二：卓越工程分數在內部官網上實時呈現，網頁會展示這個總分是怎麼計算出來的，它由一系列關鍵指標加權計算而來。
關鍵指標也會定期增加，相應的權重會發生調整，以滿足總分 100。
所有指標由研發管理平臺自動化採集提供。
針對每一個關鍵指標的分數，網頁都會給出指標的計算公式，以及如何提升的 “官方推薦”。點選問號會跳轉到相應的方法介紹頁面，傳播優秀的實踐經驗。
三： 良好及以下等級根據分數自動確認。
精英及大師級別，除了分數要在幾個月內保持達標，還需要向技術委員會申報，由專家確認，才能正式授予高等級的認證證書。
四：各個事業部技術介面人，會定期開會交流本事業部技術團隊在卓越工程行動中取得的進展，分享治理心得和優秀案例。
卓越工程專家團隊也會定期組織工程文化活動，比如單元測試沙龍，編碼比賽，工程專家課程等等。
卓越工程專家團隊還會為每個 BU 輸出技術工程成熟度報告和工程滿意度報告。（後者也很有意思，以後再聊）
五：各個事業部的技術一把手，會把卓越工程治理目標，納入技術 OKR 的考慮中。
由此，形成從度量到改進的閉環。
卓越工程的度量框架
基於軟體研發生命週期的度量框架，都是大同小異的，不同公司完全可以有自己的指標裁剪和偏好，不需要完全對標一個大公司來制定。
能否執行出好的效果，還是看執行力和基礎設施。
因為不同公司的研發基礎平臺水平是不同的，工程度量指標又希望是全自動化採集，如果基礎設施的資料採集能力弱，那麼有些指標只能被替換，或者退而求其次，給出精度較低的指標。
簡單講解下構成工程成熟度各個權重的推薦指標，以及如何採集的說明，不涉及具體公司的工具或技術。
大權重的指標可以包括這七個部分：程式碼規範，程式碼評審，單元測試，驗收測試（單測以外的各種自動化測試），測試環境健康度，構建效率，部署效率。
每個部分都可以單獨治理。從質量左移出發，程式碼規範 + 程式碼評審 + 單元測試是核心開發活動，工程成熟度的權重佔比 40-50%。其他主要模組每個權重 10% 左右。
程式碼規範
程式碼是軟體開發的源頭。從自動化原則出發，主要透過各種程式碼掃描工具進行評分。
主要權重指標：
千行程式碼阻塞問題數量
千行程式碼嚴重問題數量
程式碼評審
程式碼評審的目的是找出並修正在軟體開發初期的錯誤，從質量左移的法則上來看，大部分的缺陷都應該在編譯之前發現，程式碼評審就是最重要的手段。
從程式設計者的視角，程式碼評審可以形成良性的社交壓力，推動程式碼可讀性得到保證，並在組織內傳播有價值的知識。
為了讓程式碼評審更加規範，可以參考谷歌等公司制定程式碼審查標準，包括評審需要附帶的關鍵資訊，評審透過的門檻是什麼，評論是否都要解決等。
建議對相關團隊進行評審結果的通知，讓干係人都瞭解誰在提交評審，誰在輸出有價值的評審意見，這往往是很好的正向激勵。
主要權重指標：
發起 CR 次數：團隊內員工發起 CR 的總次數
發起 CR 平均程式碼行數
參與 CR 次數：看團隊內員工參與 CR 的總數。
參與 CR 平均程式碼行數
評審者評論數：參與評審者的發表評論總數，還可以按照千行程式碼看評論密度。
單元測試
單元測試首要的價值是降低開發同學修改程式碼時的心理負擔，提高重構效率，有利於測試驅動開發的落地。一旦單測水平進入成熟期，單測活動能夠降低需求的整體交付時長。
卓越工程強調單元測試應該：快速，獨立，可重複，自檢查（無需人工互動）。單測不關心功能測試環境。一個完整的功能交付，單測程式碼也是重要的交付產物。
幾個核心權重指標：
單元測試接入率：有單測結果任務的程式碼庫，佔團隊總程式碼庫的比例。
全量行覆蓋率： 在成功執行的單元測試任務中，全量程式碼行覆蓋的佔比。
全量分支覆蓋率
增量行覆蓋率
單測實踐也是有優先順序的，如果一個系統已經很穩定，不會頻繁的修改和釋出，可以降低單測的優先順序，把人力投入到釋出頻率更高，風險更大的業務。
驗收測試
相關權重指標可以參考以前的文章。聊聊持續測試 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484564&idx=1&sn=9d0267d51f5075bcd39f1fb7d0e58f3b&chksm=c24fb1f6f53838e0b2c91e9c8588edd04140a8109719761be75c05fe9dbceb3b096475a176a7&scene=21#wechat_redirect
測試環境健康度
對於大多數公司，測試環境是阻礙效能提升的最大障礙之一。這塊的健康度當然體現了工程成熟水平，如果能提供一個高效穩定的線下環境供工程師自測和聯調，提效就非常顯著。尤其主幹環境的穩定性是重中之重。
預發環境也會因為資源有限發生爭搶，還容易汙染到生產資料引發故障。我們應該儘可能左移到線下的專案環境進行測試，保障多套測試環境能並行使用。
線上下完成所有的開發自測，整合測試，聯調測試，最後部署到預發環境做正式釋出前的驗證。
主要權重指標：
主幹環境的接入率: 團隊線上的總應用中，多少比例的應用接入了主幹環境。
主幹環境的 SLA（服務水平）：當月團隊應用在主幹環境的平均穩定性，可以每 10 分鐘做一次可用性取樣。
預發環境的 SLA
構建效率
隨著業務變得越來越複雜，如果不刻意治理，程式碼構建的效率不可避免地會被降低。我們度量構建效率，主要看構建時長和構建失敗率的改善，儘可能縮短 “從程式碼提交到可測” 這個過程的耗時。
常見的構建提效方法有：正確配置目錄，正確使用增量構建，謹慎使用 Snapshot，依賴瘦身和減少依賴深度，Docker 構建的規範化，基礎軟體的版本升級，程式碼衝突預先檢查等。
主要權重指標：
構建平均時長：成功構建例項的構建編譯打包時長。
使用者原因構建失敗率：非專案環境原因，而是使用者原因導致的失敗。
部署效率
應用的部署一直是非常耗時的事，它導致測試環境驗證過程很漫長，還會帶來線上風險。改善部署耗時的關鍵影響因素可以有效提升釋出效率。
具體治理手段有加速應用啟動的非同步初始化方法，中介軟體的啟動配置最佳化等。權重指標有：
生產應用啟動時長：在生產環境成功部署例項的應用平均啟動時長
預發應用啟動時長
釋出整體：返工和折返
這塊效率指標作為面向釋出過程的通用評分事件，觀測研發團隊的效能表現。
效能表現是受到多個維度影響的複雜評估物件，比如業務節奏，需求質量，需求大小，系統複雜度，互動複雜度，人員技能，技術基建等等。
只要能看到問題就有找到具體改進方法的機會。改進方法和前面多個模組的改進方法都可能有關，和 DevOps 建設的水平也強相關。
主要權重指標：
變更前置時長：從首次提交變更程式碼，到變更成功釋出之間的時間
程式碼修改預發折返率。也可以統計折返次數和平均折返時長。
釋出失敗率
平均釋出頻次。
其他權重模組（可選）
對於大型公司，不同技術部門在業務上獨立，但是基礎技術元件上又有很多合作和複用，可以把二方包的治理水平作為可選的權重評分。二方包就是集團內部共享但非開源的基礎軟體包，它在跨事業部的業務中起到重要的紐帶作用，也會影響整合方的體驗。
在集團內部提高二方包的規範性和易用度，可以提高研發質量和效率，促進了跨部門的學習氛圍，凸顯了開放協作組織的價值。
主要指標：
團隊程式碼開放率：活躍程式碼的已開放比例。活躍程式碼指近期有程式碼提交的程式碼庫。
二方包合規率
對於強調線上治理水平的公司，可以選擇把釋出後的治理能力也做為工程成熟度的一部分，具體指標可以包括：
線上監控覆蓋率（看應用基礎的覆蓋情況）
人均監控處理量
監控平均處理時長
對工程成熟度的總結
有些業界的成熟度模型很容易被濫用，組織容易在成熟度模型的牽引下形成慣性，不自覺地開始低階的 “內卷”，從而忘記了提升研發體驗和業務滿意度才是根本目標。
如果沒有人認真思考高階能力該如何構建，那眼前的眾多改進措施不可能持續落地，或者付出的成本高於收益。
我們希望透過工程成熟度模型來產生有效的工程文化，讓研發團隊看清楚改進清單，積累優秀的成功實踐案例和慘痛的反模式，從而建立共識。
這個過程不可能透過行政命令達成，而是需要人和人的切磋交流，也需要卓越工程師的深度參與。