無法衡量生產力

2003 年 8 月 29 日

我們看到許多關於軟體流程、設計實務等充滿情緒的討論。其中許多爭論無法解決,因為軟體產業缺乏衡量軟體開發效能某些基本元素的能力。特別是,我們沒有合理衡量生產力的方法。

當然,生產力是透過觀察活動的輸入和輸出而決定的。因此,要衡量軟體生產力,您必須衡量軟體開發的輸出 - 我們無法衡量生產力的原因是因為我們無法衡量輸出。

這並不表示人們沒有嘗試。我最惱火的其中一件事是根據程式碼行數進行的生產力研究。首先,有關於程式語言之間差異、不同的計數風格以及格式化慣例導致的差異等所有問題。但即使您對同一程式語言的程式使用一致的計數標準,並全部自動格式化為單一風格 - 程式碼行數仍然無法適當地衡量輸出。

任何優秀的開發人員都知道,他們可以使用程式碼行數的極大差異來編寫相同的東西,此外,設計良好且經過整理的程式碼會更短,因為它消除了重複。複製貼上程式設計會導致高 LOC 數量和不良設計,因為它會產生重複。如果您使用支援 內聯方法 的重構工具處理程式,您可以自行證明這一點。僅在常見例程中使用它,您就可以輕鬆將 LOC 數量增加一倍。

您會認為程式碼行數已經過時了,但看來我每個月都會看到根據程式碼行數進行的生產力研究 - 甚至在應該更了解的 IEEE Software 等受人尊敬的期刊中。

現在,這並不表示 LOC 是一個完全無用的指標,它相當能顯示系統的大小。我相當有信心 100 KLOC 系統比 10KLOC 系統大。但是,如果我在一年內寫了 100KLOC 系統,而 Joe 在同一時間內用 10KLOC 寫了相同的系統,這並不會讓我更有生產力。事實上,我會得出結論,我們的生產力差不多,但我的系統設計不良得多。

另一種經常被談論的衡量產出的方法是功能點數。我對它們稍微更有好感,但仍然不認同。我聽過的故事並沒有幫助,這些故事談到同一個系統由不同的功能點數計算器使用同一系統計算,結果相差三倍。

即使我們確實找到了準確的方法來使用功能點數來確定功能,我仍然認為我們錯過了生產力的重點。我可能會說,衡量功能是查看軟體開發直接產出的方法,但真正的產出是另一回事。假設有一個準確的 FP 計算系統,如果我花了一年時間交付一個 100FP 系統,而 Joe 花了同樣的時間交付一個 50FP 系統,我們可以假設我更有生產力嗎?我會說沒有。我的 100FP 中可能只有 30 實際上對我的客戶有用的功能,但 Joe 的都是有用的。因此,我會認為,雖然我的直接生產力較高,但 Joe 的真實生產力較高。

Jeff Grigg 指出,有一些內部因素會影響功能點數的交付。「我的 100 個功能點數非常相似的功能,我花了一年時間來完成它們,因為我未能適當地利用重複利用。Joe 的 50 個功能(對他來說是個壞消息)都非常不同。幾乎無法重複利用。但儘管必須實作 50 個非常不同的功能點數,幾乎無法重複利用,但 Joe 是一個了不起的人,所以他只花了一年時間就完成了所有工作。」

但所有這些都忽略了一個重點,即使是有用的功能也不是真正的衡量標準。隨著我的進步,我產生了 30 個有用的 FP 功能,而 Joe 只產生了 15 個。但有人發現,Joe 的 15 個功能為我們的客戶帶來了 1000 萬美元的額外利潤,而我的工作只帶來了 500 萬美元。我再次認為,Joe 的真實生產力較高,因為他提供了更多的業務價值——我斷言,任何衡量軟體開發生產力的真正標準都必須基於提供的業務價值。

這種思考方式也影響了成功率。關於軟體成功的常見說法是錯誤的,因為人們不了解 WhatIsFailure。我可能會認為,一個成功的專案是提供比專案成本更多的業務價值。因此,如果我和 Joe 各執行五個專案,我成功了四個,而 Joe 成功了一個——我最後是否比 Joe 做得更好?不一定。如果我的四個成功專案每個產生 100 萬美元的利潤,但 Joe 的一個成功專案比他所有專案成本總和多產生 1000 萬美元——那麼他應該獲得晉升。

有些人說「如果你無法衡量它,你就無法管理它」。那是一種逃避。企業總是在管理他們無法真正衡量價值的事物。你如何衡量一家公司的律師、其行銷部門、一所教育機構的生產力?你不能——但你仍然需要管理它們(請參閱 Robert Austin 以了解更多資訊)。

如果團隊生產力難以釐清,那麼衡量團隊中個人的貢獻就更難了。你可以透過查看每個迭代交付多少功能來粗略了解團隊的產出。這是一種粗略的感覺,但你可以感覺到團隊是否正在加速,或者粗略地感覺一個團隊是否比另一個團隊更有生產力。但個人貢獻更難評估。雖然有些人可能負責實作功能,但其他人可能扮演支援角色——幫助其他人實作其功能。他們的貢獻在於他們提升了整個團隊的生產力——但除非你是該團隊的開發人員,否則很難了解他們的個人產出。

如果這一切還不夠複雜的話,《經濟學人》(2003 年 9 月 13-19 日)刊登了一篇關於生產力趨勢的文章。看來經濟學家現在看到企業的生產力因 90 年代的電腦投資而增加。重點是改善落後於投資:「投資電腦並不會自動提升生產力成長;企業也需要重新組織其業務實務」。電力發明時也出現了相同的落後情況。

因此,不只是業務價值難以衡量,還存在時間差。所以,也許你無法在軟體發布後幾年內衡量一個團隊的生產力。

我明白為什麼衡量生產力如此誘人。如果我們能做到,我們就能比現在更容易、更客觀地評估軟體。但錯誤的衡量只會讓事情變得更糟。這是我們必須承認自己無知的地方。