如何度量前端項目研發效率與質量（上篇）

時間 2020-06-08

標籤如何度量前端項目研發效率質量上篇简体版

原文原文鏈接

DevUI是一支兼具設計視角和工程視角的團隊，服務於華爲雲 DevCloud平臺和華爲內部數箇中後臺系統，服務於設計師和前端工程師。
官方網站： devui.design
Ng組件庫： ng-devui（歡迎Star）

引言

在DevOps，有個很流行的說法是XX項衡量DevOps是否成功的指標。經過對研發流程各個階段的關鍵數據進行度量，來判斷一個項目是否完成DevOps轉型。前端

這個思路很是正確，由於要想改進它，就要度量它。git

而對於前端項目大部分也能夠套用DevOps的部分衡量指標，我基於自己的項目實踐，結合前端項目研發流程的特殊性和差別點，梳理出更適合判斷前端項目是否高效高質的衡量指標。而衡量指標大部分都是能夠經過工具實現自動化採集，從而能夠很容易創建出適合團隊自己的交付看板，用於平常項目管理改進。github

本文適合前端項目leader，和嘗試前端工程實踐的工程師們。安全

前端研發流程

我將前端研發流程分爲：設計、開發、我的驗證、版本驗證、線上驗證5個階段。下面我分別解釋下這幾個階段的含義與區別。前端工程師

設計：前端研發流程最特別的階段，因爲前端業務特色，前端工程師不可避免的將會與設計師和產品盡力進行協同。不管是產品設計的技術可行性評估仍是產品體驗的討論，產品設計的階段將決定業務的實現方式，這是全部需求的源頭。與設計師和產品經理的協同效率越高，前端團隊的交付效率也會越高。編輯器

開發：前端工程師的核心編碼輸出階段，這個階段的代碼質量、開發效率、協同聯調效率都將決定後續版本的質量和返工成本。在這個階段有很是多的自動化工具或cli，來協助開發者提高效率和編碼質量。但這也是最很差控制得階段，由於他與我的開發環境和我的技術水平與習慣息息相關。模塊化

我的驗證：前端工程師開發完成後，在正式提交前，都會有我的驗證的階段。也就是自我驗證確保無問題後，再提交入庫，啓動版本驗證階段。雖然每一個開發工程師都會自我驗證，但由於開發者思惟的存在，這每每是最容易忽視的一個環節。咱們須要在這個環節加入不少的自動化驗證能力，來幫助開發者在我的開發階段完成質量的提高。由於，在整個研發流程中，越在前面環節發現問題，其修復成本越低。工具

版本驗證：在前端團隊中，各個開發人員完成自我驗證後，提交至版本分支後，將啓動版本驗證階段。在這個階段，優秀的前端團隊會經過自動化的流水線完成編譯打包、靜態檢查、質量門禁、用例測試等一系列自動化的版本驗證動做，完成版本的質量與安全的保障。這個階段應該是整個研發流程中自動化率最高的環節。效率高、自動化程度高、執行速度快的流水線，將極大提高前端項目的質量和效率。post

線上驗證：前面四個階段都是站在開發團隊的視角，最後一個階段是站在用戶的視角。也就是說，當你完成了版本發佈後，你的產品真實表現如何，用戶是否按照指望的方式在使用，有無漏測，有無在開發階段忽略的質量漏洞，可否先於用戶發現問題，可否快速定位到問題。這些都須要在線上驗證階段進行監控與攔截，在該階段，前端監控，還有各類告警、撥測等工具的應用，都是比較好的優秀實踐。單元測試

那麼到此，整個前端研發流程也就完整閉環。

衡量指標

說完了前端研發流程。那麼，在這個流程的各個階段，咱們用哪些可度量的指標來判斷每一個階段是否作到了最好，是否還有改進空間？度量指標體系的創建，不只幫助你瞭解目前項目的基線狀況，更大的價值是可以根據客觀的度量數據，牽引團隊往達標的方向改進，方向清晰，效果明顯。

設計

在設計階段，咱們須要考慮的是如何提高前端人員的效率。這個階段在不少團隊若是設計師與產品經理比較專業，經過設計平臺的協同，都能達到很高的效率。可是若是設計師與產品在設計階段的混亂，可能會致使需求不清晰、設計反覆、一句話需求，因此在這個階段，更多的是衡量產品經理與設計師，經過指標反向約束，避免設計成本轉移給前端開發人員。經過項目管理的工具，前端開發者很容易給對應需求打上標籤和填寫對應信息，從而度量相應指標。

前置時間（Lead time）

前置時間是供應鏈管理中的一個術語，也被應用於敏捷與devops中，在供應鏈管理中，是指從採購方開始下單到供應商交貨所間隔的時間。而對應到敏捷和devops中，每每指用戶提出需求到發佈上線的時間。通常狀況下，在交付人力穩定的狀況下，交付效率都是恆定的，因此前置時間的縮短還要着重審視設計階段的效率。也就是說，從用戶提出需求，到最終設計稿定稿的時間是否存在優化空間。

需求修改頻次

因爲前端交付產品與交互體驗息息相關，存在設計稿和原型頻繁改變的狀況。需求修改頻次，能夠記錄前端產品需求被修改的次數，從而反應產品經理與設計師在產品設計的規範程度與協做效率。

需求規範度

提交的需求是否知足約定的規範。好比，複雜特性須要有詳細的高保真標註圖、杜絕一句話需求、杜絕描述不清楚的需求。在收到不知足規範要求的需求，開發人員有權打回需求，以免後續的開發成本浪費。而規範度遵循度差的團隊，應該審視相應角色的協做是否存在優化點。

開發

開發階段是工程師核心編碼輸出階段，在這個階段，咱們關注的主要是交付效率與質量。

迭代人均交付需求數

在單位迭代內，每一個開發人員能完成的人均需求數。因爲團隊劃分需求顆粒度習慣是延續的，可能存在個別迭代不一樣開發人員需求顆粒度不一致的狀況，但放在一個較長的時間段內相關偏差基本可控。因此平均迭代交付需求數越高，且呈上升趨勢的團隊，能夠理解爲團隊交付效率高。

迭代人均問題數

而對應的，單位迭代內產生的現網問題數越多，也表明其交付版本質量較差。而若是該指標長期未成收斂趨勢，那麼也須要同步審視相應的質量保障體系是否存在優化空間。

我的驗證

在我的驗證階段，主要是開發人員對本身編寫的代碼進行合入版本前的自我驗證。主要包含功能測試與代碼檢視等一系列質量活動。固然，在一些優秀實踐裏，也會引入大量自動化工具和插件，輔助開發人員提早發現質量問題。

代碼檢查聽從度

良好的代碼規範和基礎的靜態檢查可以避免不少低級問題，在這方面基於eslint等一系列工具，能夠很容易創建起代碼檢查的要求。而聽從度的指標，要求開發人員必須知足咱們的代碼檢查要求，好比，嚴重問題清零，或者問題100%清零等指標。

自動化用例覆蓋率

不管是單元測試用例仍是E2E的測試用例，在我的驗證階段，開發人員應該編寫對應的測試用例，並基於本次代碼提交的影響範圍，運行相關自動化用例，以確保新功能和歷史功能的質量。尤爲對於大型的前端業務系統，必須創建自動化用例體系保障長時間積累的大量特性獲得質量保障。在此階段，自動化用例覆蓋率越高，越能保障版本的質量。

自動化用例成功率

而用例覆蓋率對應的是，自行的成功率。頻繁失敗的測試用例，要麼反應業務功能的不完善，要麼反應測試用例的不嚴謹，從而影響版本質量的驗收，應盡力避免。