Categories
程式開發

這些年,我們發展出了多少種愚蠢的“程序員工作成績”衡量指標?


本文最初發佈於GitClear博客,經原作者授權由InfoQ中文站翻譯並分享。

只要有計算機程序員,就會有愚蠢的指標來衡量他們。這篇文章的目的是讓2020年少一點愚蠢。今年,我們希望讓經理們對技術有足夠的理解,使他們能夠看到“提交計數”之類的度量指標的不足之處。在編制下面的列表時,我們將重點放在了“2019年在現實世界中經常使用”且“會對開發人員績效評估帶來誤導”的指標。

公平地說,在我們將討論的這些糟糕的指標中,有許多都含有豐富的信號。如果不是因為噪音過多,那麼這些指標可能會告訴你一些有趣的事情。對於“代碼攪動”這個指標,一個最相近的類比可能是:如果你走進一個房間,裡面有25個無線電台在通過一牆的音箱播放節目,那麼就有大量的信號!但你能指望從中得到什麼呢?大概什麼都沒有。用於證明決策合理性的數據源越嘈雜,決策的結果就越武斷,對公司長期福祉的損害就越大。

第一個指標最簡單,也最可悲。

代碼行(LoC)

原始代碼度量™️……這讓我們倒退了幾十年。這個指標將一個信號放入了大量的噪音中。更具體地說,根據GitClear對大約100萬個開源提交的分析,以下是LoC中一些最嚴重的污染:

這些年,我們發展出了多少種愚蠢的“程序員工作成績”衡量指標? 1

餅圖中用到的術語和方法的說明

如上所示,本質上,代碼行大約有70%是噪音。更糟糕的是,在開源代碼庫中,大約30%的提交最終會被丟棄,而不會被合併到主幹中,因此,從這些提交得到的任何LoC都會增加噪音。如果LoC本身有30%的信號,考慮到一般的商業庫中清洗掉的提交,要將其減少一半,這就意味著這個指標有80%多是噪音。

根據一個80%是噪音的度量指標來做決策聽起來很糟糕。但是,LoC還可以更糟糕,因為我們還沒有考慮到在實現新特性時LoC會出現尖峰。鼓勵快速添加代碼會滑向被技術債務搞得一團糟的代碼庫。更不用提在CSS文件中編寫的一行代碼與在Java文件中編寫的一行代碼的工作量有很大的不同。考慮到CSS傾向於產生簡短、重複的代碼行,一般的開發人員可能在編寫一行Java、Python或Ruby代碼的時間內可以編寫10行CSS。因此,根據LoC指標,“最有價值的開發人員”往往是添加最多CSS、空白和第三方庫的人。

由於所有這些原因,在這一大堆最糟糕的開發人員指標中,代碼行最突出。雖然深入挖掘,它確實隱藏著一絲信號,但你很難再找到一個被外來噪音污染得更嚴重的度量指標。

提交計數

與代碼行一樣,人們在GitHub及其他地方長期將“提交計數”作為一個度量指標來使用很大程度上歸功於它相對容易提取。但是,它確實比LoC有優勢。首先,它不容易受到噪音的影響,因為這些噪音都是一些瑣碎的行更改。它可以解決LoC一半的問題。其次,如果開發人員在2-3天內沒有提交,這通常是一個信號,說明他們可能被卡住了。目前為止,一切都還好。

不幸的是,作為軟件度量的“提交計數”的實際效用僅此而已。雖然LoC是一個被噪音破壞的信號承載指標,但實際上,提交計數從一開始就沒有信號。為什麼?因為,從概念上講,提交只不過是開發人員工作過程中的一個“保存點”。開發人員多久會保存他們的工作?這要看個人喜好。如果你使用“提交計數”作為指標來比較開發人員(正如GitPrime的UI所鼓勵的那樣),那麼你實際上是鼓勵他們培養一種個人偏好,在每次編寫完一行代碼時進行提交。

當然,說這會導致團隊開發人員每次更改一行代碼都會提交代碼,是一種極端的想法。但是,如果開發人員決定每小時提交一次工作,而不管他們從事的是什麼工作,又該怎麼辦呢?有責任心的開發人員會避免這種(完全合乎邏輯的)策略,以避免激怒他們的隊友。但你希望讓你的開發人員處於這樣的位置嗎?如果你是一名努力工作的開發人員,正在努力解決盡可能多的Jira問題,如果你知道,通過更頻繁地保存工作,你那些懶惰的同事將在提交計數排行榜上超過你,你會作何感想?

如果開發人員知道自己的經理會認真對待這個指標,那麼提交計數就會在他們中間製造一種有害的氛圍。編程人員可以每小時提交一次,這很容易。不好的激勵會導致不好的結果。

拒絕利用這一最具遊戲價值的度量指標的開發人員將會不斷地離開,不知道他們如何落後於那些不那麼細心的同行。

解決的問題,即“交付速度”

這個指標比其他兩個指標更有效,因為它關聯到一個有意義的輸出:在Jira或Github之類的問題跟踪系統中解決的問題。到目前為止一切順利——至少它度量的是一個有意義的數量。現在,讓我們在現實世界中試一下。

如果你比較最近關閉的10個問題中最大和最小的任務,它們之間的實現時間有多大差異?我們先中斷一下,讓你可以思考一下,檢查下自己的數據,從而確認答案,這應該只需要2分鐘…

在大多數團隊,這個差距可能是10倍或更多。例如,查看我們最近在Jira上解決的十個問題,其中最快的一個需要15分鐘。最長的已經持續了兩週,目前仍在進行中。如果一個工程師負責的領域多是小型工單(如QA傾向於提交大量的小型用戶界面工單),這對於後端開發人員來說就是一個大問題,因為他們需要處理一個為期兩週的基礎設施修改。 UI開發人員是否就因為他們恰好在一個小工單更多的領域而更有價值?當然不是。因此,中短期來看,這個度量指標可以很好地跟踪開發人員設法獲得簡單工單的程度。

如果我們將“解決的問題”與“故事點”結合起來使用,就可以提高“解決的問題”這個指標的質量,但是這種方法有它自己的缺點

代碼攪動,亦即“效率”

這是這個糟糕的指標集合中最現代化的度量指標。代碼攪動(Code churn)在GitPrimeVelocity中都是很突出的功能。代碼攪動作為一種指標的失敗在於對它的解釋不具有一慣性。關於代碼攪動是如何進入這個列表的,GitPrime自己的博文“代碼攪動的6個原因以及如何應對”提供了一個極好的參考。GitPrime列舉的原因有:需求不明確、利益相關者猶豫不決、難題、原型設計、優化和參與不足。

為了闡明每一項的含義,我們把這六個原因畫在了一個有坐標的圖表上:

這些年,我們發展出了多少種愚蠢的“程序員工作成績”衡量指標? 2

那麼,當代碼攪動變得嚴重時,你是按下了應急按鈕,還是踩下了油門?答案很複雜,因為有很多根本不同的原因導致代碼攪動。從上圖可以看出,在這些原因裡,三個主要源於開發人員的原因看起來實際上都帶來了好的結果——也就是說,大多數公司都從早期優化過的原型化產品中獲益。 “解決難題”通常是朝著一個大膽的目標前進時取得進展的必要條件。

但是,如果代碼攪動經常帶來積極的結果,那麼為什麼它的反面“效率”是GitPrime使用的核心指標之一呢?當然,其他三個原因是不受歡迎的。參與不充分、利益相關者猶豫不決和需求不明確將降低生產力。因此,如果我們試圖衡量產品經理的工作,“效率”是一個非常有用的度量指標。

小結

如果我們試圖度量開發人員的工作,那麼最好選擇一個不會影響優化代碼的度量指標。

考慮到2020年伊始上述指標仍被認為是可行的,這證明管理者仍然有許多機會來改進指標—>激勵—>團隊所取得的長期成果。值得讚揚的是,促使經理人利用這些指標的直覺是合理的。他們知道,最好的企業利用數據做出最佳決策。但這在很大程度上取決於數據的好壞。當你信任提交計數之類的指標時,可能會比完全不使用數據的情況更糟(例如讓兩個團隊互相競爭)。不管公司的規模有多大,都不要再自欺欺人地認為上面的度量指標可以揭示出有關開發團隊工作的一些深刻的東西。

那麼,親愛的讀者,你們公司是用什麼來衡量你的成績的呢?歡迎在評論中留言。

查看英文原文
The 4 Worst Software Metrics Agitating Developers in 2019