程式設計師的績效到底是應該衡量專案，還是改 Bug 量？
你聽說過有的團隊使用各種衡量方法嗎？比如 Bug 修正率，或者每週產生的程式碼行數？根據這種度量算出的業績最差者就可以辭退了。接下來會怎樣？團隊就會只關注那些容易改的 Bug，以便做出漂亮的資料。最終，產品的質量只能越來越差，而不會變好，而且也會導致具有價值的開發者離職。難怪開發者們不信任生產力度量了。“我從來沒有見過任何度量能真正起到作用的。”
這篇文章裡我想剖析一下生產力度量的奧祕。我們會逐一討論：
哪些度量必須小心使用——意味著它們可能涉及一些特殊的條件，以及特殊的使用方式；
哪些度量是真正有用的，不論你是團隊貢獻者、領導還是經理，都應該把這種度量引入團隊。
讓我們開始吧！
應當非常小心使用的度量
1) ticket 關閉率——用於衡量個人業績
如果不使用故事點或類似的東西，那麼這個度量可能是最具誤導性的了。使用這個度量實際上等於假設所有 ticket 的工作量都是相同的，而這絕對是錯誤的。絕對不應該用這個度量來衡量個人開發者的業績。一名開發者可以改正任何人都改不了的問題，改正一個從多個方面影響產品效能的問題，而這可能耗費他整個星期。而另一個開發者可能用同樣的時間修改 20 個細節問題。哪個對團隊和公司的影響更大？
即使你採用了故事點，那麼上面的場景中，即使是最好的情況，那一個 Bug 可能有 5 個故事點，而另外 20 個 Bug 每個有 1 故事點。這還沒有考慮到絕大多數團隊都不會使用故事點來衡量 Bug，一般故事點只用來衡量功能。
但是，你可以使用這個度量來發現類似於開發者被某個任務纏住之類的問題。關鍵是，不要使用這個度量去衡量開發者的業績，否則你的團隊就會追求度量本身，而不會產生任何有意義的工作成果。這個度量僅能用來幫你理解，作為管理者的你怎樣才能幫助團隊前進。
2) 產生的程式碼行數(Lines of code，LoC)——用於衡量個人業績
還是上面的例子，大型的 Bug 修改可能只需要改一行程式碼，另一個開發者可能匯入了一個函式庫，或者改動了每個檔案中的每個標頭檔案。這兩個人怎麼比較？顯然沒法比較。類似地，這個度量也絕不能用來衡量個人業績。LoC 可以用同樣的方式使用——用來理解你的團隊是否遇到麻煩，或者是否為了專案的質量而引入了太多的函式庫！
一些人會根據被修改的程式碼行數計算“影響度”度量，即這些改動的嚴重程度，以及影響到的檔案數量。總的來說，這樣做的目的是找出比 LoC 更好的度量標準。這個標準看上去不錯，但我還是強烈建議，不要用它來衡量個人業績。實際上，這個度量對於上面說到的只修改一行的 Bug 依然束手無策，許多實際工作中的例子也證明了這一點。
3) 程式碼擾動量(Code churn) vs. 程式碼吞吐量
程式碼擾動量有很多不同的定義。常見的度量方式是，對開發者近期工作的程式碼編輯量，佔開發者自己的程式碼量的百分比。擾動率的突然增加可能意味著開發者在解決特定問題時遇到了困難。
一些人認為程式碼擾動量的生產效率不高，因此不如“程式碼吞吐量”，這是非常危險的看法。實際上，程式碼擾動量可能意味著開發者在優化某部分程式碼以獲得更好的效能。也有可能產品團隊無法做出決策，使得開發者只能原地踏步。因此規則是，要關注擾動量的任何巨大變化，以找出開發者可能遇到的潛在問題，從而幫助團隊更快地前進。
有什麼度量可以衡量個人業績？
你肯定會問這個問題。答案是：沒有！沒錯，你可以看看我說的這句話：
度量是主觀的，能提供資訊的。但不能根據度量評判任何個人的業績。度量只能讓你更好地理解專案的複雜性。
實際情況是，管理很困難，而且永遠需要根據情況而定。你需要挖掘很多資訊來理解問題的根源。有時候你會發現某個開發者的確業績很差，但這個發現是因為你做出了努力來理解團隊及團隊的合作情況，才能發現是否有某個成員拖了大家的後腿。這是成為好的經理、促進團隊提高生產力並維持團隊的必經之路。
而且，如果你首先考慮了這一點，你就能正確地使用上面提到的三種度量。你還能使用更多的度量來幫你更好地理解團隊的工作速度和質量。
應當使用的度量
我將這些度量分為兩類：速度和質量。如果覺得我漏掉了什麼，請告訴我，我很願意加到這篇文章裡。
速度相關的度量
這些度量是最具爭議性的，因為許多人（包括我）都很討厭敏捷開發的故事點。但還有一些其他度量，我希望你在試圖用它們衡量“速度”時能三思而後行。
4) 提交頻率
這個度量可以促使大家每天提交程式碼，這是個好的實踐。還可以用來測量打斷的代價。計劃和會議等非編碼的任務都會不可避免地拉低提交頻率。通常，團隊每週都至少要浪費一天時間來從事這些活動。監視提交頻率能讓你看到哪些會議會影響團隊提交程式碼的能力。
經理應當儘可能保護團隊的專注力，確保流程相關的活動不會造成負擔。
5) 服務水平協議(SLA)
每個團隊都有自己定義的SLA。但下面Airbnb使用的這個 SLA 我覺得很有意思。這個 SLA 定義為：在一定時間內團隊修正並部署的 blocker bug 佔的百分比（例如，blocker 的時間為 24 小時，critical bug 的修改時間為 5 天）。我喜歡這個度量的真正原因是，它能讓你從使用者的角度理解產品質量。
注意，我認為這個度量是速度類別的，因為它顯示了團隊的速度，而不是生產軟體的質量。
6) 與拉取請求有關的速度
每週開啟的拉取請求數量
每週合併的拉取請求數量
每週產品部署次數
合併所需平均時間（或在特定閾值下合併拉取請求的百分比）。這個度量有時等價於“提交到部署所需時間”（一段程式碼從提交到部署所需時間，期間這段程式碼可能要經歷測試、QA、staging 等，取決於你的組織流程）。這個度量能顯示出工作流中遇到的障礙。
這些度量能讓你理解工程團隊的持續輸出。例如，如果向團隊新增更多的人也無法讓這些數字增加，那麼可能因為流程本身有問題，或者需要先解決一些技術債務。但是，如果它增長得快，說明可能出現了質量問題。
不要忘記，只衡量團隊速度而忽略工作成果的質量是非常具有誤導性，而且是極其危險的。
與質量有關的度量
質量本身並不是目標。真正起作用的是能夠安全地增加並修改功能時的信心。
7) 測試覆蓋率
當然，不需要 100% 的覆蓋率。但是，知道自己的位置並跟蹤，可以看到是否在為了質量而犧牲了速度。
(8) 拉取請求質量
拉取請求能讓你清晰地看到程式碼的整體複雜度。程式碼越複雜，下面這些度量增大的可能性就越高：
拉取請求導致構建失敗或測試失敗的次數百分比
拉取請求被合併和被拒絕的比例
每個拉取請求的評論數——這個度量不應該太低，但也不應該太高。
9) 專案中的 Bug 數
一般來說，在專案生命週期的中期，Bug 數量會上升。在最後期限之前幾天或幾周（不同大小的專案不一樣），團隊會專心減少 Bug 數量，直到 Bug 接近某個程度。這個接近程度最終能代表專案的產品的整體質量。所以，整體的 Bug 數量（要注意區分優先順序）是個很好的專案指示器。
另一個度量是發現的 Bug 數量，或者使用 Bug 修正數量與釋出的功能數量的比例。這兩個度量通常按照每週或每月的頻率統計。它們能夠指示實現的質量水平。
10) 依賴的時期
另一個有關技術債務的指示器就是程式碼庫中存在多少過時的依賴。這個度量可能很有意思。
技術債務很正常，每個專案都會出現，而質量的標誌很主觀。類似於這一條的度量能幫你跟團隊一起定義一系列的規則，以瞭解團隊工作的質量。
本文的主要觀點是，如果你衡量專案或衡量整個團隊，你的開發者就不會在度量上弄虛作假。正如@raffi所說（https://twitter.com/raffi/status/725044879097782274），“不衡量的東西是沒法作假的。”而度量作假是最容易的。
如果你有不同意見，請告訴我。希望這篇文章能起到拋磚引玉的作用。
原文：https://anaxi.com/blog/2018/11/25/do-not-measure-developers-measure-projects/
作者：John Lafleur
譯者：彎月，責編：屠敏
推薦閱讀：
點選“閱讀原文”，開啟 APP 閱讀更順暢