Martin Fowler：仍無法衡量軟件開發的生產效率
英文原文：Can not Measure Productivity 譯文鏈接
2003 年 8 月 29 日，軟件行業大牛 Martin Fowler 寫過《無法衡量生產效率》。10 年后的 8 月 29 日，Martin 在其網站首頁以《十年后仍無法衡量生產效率》標題再次推薦了這篇文章，并附言：“軟件行業的巨大挫敗之一，是我們沒有合理建立研究，去思考諸如面向對象編程和測試驅動開發之類的開發工具和技術、還有其他更高級的語言是否對我們有益。我們經常看到不當的研究，并且常常很糟糕，是因為它們是基于一個錯誤的衡量方法（比如員工每天所編寫代碼的行數）。十年前的今天，我的挫敗感促使我寫了《無法衡量生產效率》一文。我認為該文在今天看起來，和十年前沒什么不同。”
</blockquote>我們見到過太多關于軟件開發過程、設計實踐以及類似內容充滿激情的討論。它們當中有很多是無法驗證的，因為軟件行業沒有能去衡量代表開發效率的一些基本元素。特別是我們無法合理地衡量生產效率。
當然，生產效率可以通過觀察生產過程的輸入與產出來衡量。所以，要衡量軟件開發的生產效率，你就必須去衡量軟件開發的產出。我們無法衡量生產效率的根源就在于我們無法衡量產出。
并不是說人們沒有嘗試過。最令我氣憤的就是那些用代碼行數來衡量生產效率的研究。首先，總是存在不同的語言、不同的計數方式、不同的格式化風格造成的問題。即使采用一致的計數標準，衡量相同語言代碼，且代碼被自動格式化為統一的風格，代碼行數仍然無法正確反映產出。
任何優秀的開發者都知道，讓他們去實現一個特定功能所需的代碼行數可能相差巨大。除此之外，精心設計以及重構過的代碼都會更短小，因為它消除了冗余。復制粘貼風格的程序會有更多的行數以及更差的設計，因為它充滿冗余。這很好證明，只要你使用一個支持 inline method 的重構工具去修改一個程序。只需用這個工具去重構那些普通函數，你就可以輕易讓代碼行數翻倍。
你可能覺得已經沒人再用代碼行數了，實際上每個月我都能看到基于代碼行數的生產效率研究論文，甚至是在類似 IEEE Software 這樣令人尊敬的期刊上。
也不是說代碼行數是個完全沒用的衡量，它能很好代表系統規模。我可以很確定一個 100 KLOC（KLOC=千代碼行）的系統比一個 10KLOC 的系統要大。但是如果我用了一年時間寫了那個 100KLOC 的系統，而 Joe 在一年內用 10KLOC 實現了同樣的系統，這無法說明我更高產。實際上我得到的結論是：我們的生產效率差不多，但我的系統設計得更差。
另一個經常被用來衡量產出的方法是使用功能點（Function Points）。雖然我更同情這種做法，但它并不能令我信服。我聽過很多這樣的故事：同一個系統，不同人統計的功能點數目相差有 3 倍之多。
即使我們能夠找到一種方式用功能點精確衡量功能，我認為這仍然無助于解決生產效率的衡量問題。可以這么說，衡量功能點是觀察軟件開發直接產出的方式，但真實產出確是另一回事。假設有一個精確的功能點計算系統，如果我花一年發布了一個有 100 個 FP（功能點）的系統，同時 Joe 也用一年發布了一個 50FP 的系統，是不是就能說我更高產？我覺得不是。很可能我做的 100FP 中只有 30 個對我的客戶來說是真正有用的功能，而 Joe 開發的功能則全部都是有用的。我會這么說：雖然我的直接生產效率更高，但 Joe 的真實生產效率更高。
Jeff Grigg 向我指出，還存在影響功能點交付的內因。我的 100 個功能點可能提供的都是很相似的功能，我之所以花了一年時間，是因為我沒有很好的重用代碼。Joe 的 50 個功能都是差別相當大的（對他來說可不是個好消息），所以幾乎沒有重用的可能。盡管需要實現 50 個相當不同的功能，并且幾乎無法重用代碼，但 Joe 真的很棒，他在一年之內就全部完成了。
但這些都忽視了一點：即使是有用的功能也無法真正用來做衡量。假設我有了進步，完成了 30 個有用的功能點，同時 Joe 只完成了 15 個。但有人會發現 Joe 的 15 個功能點為我們的客戶增加了 1 千萬的盈利，但我的工作成果帶來的盈利只有 500 萬。我仍然認為 Joe 的真實生產效率要比我高，因為他產出了更多的商業價值。并且我堅信任何真正的軟件生產效率衡量必須基于其所帶來的商業價值。
這種思想也適用于成功率。通常關于軟件項目成功的判斷都是虛假的，因為人們并不理解什么是失敗。我可以說一個成功的項目就是產生的商業價值大于研發成本的項目。假如 Joe 和我各參與了 5 個項目，我的 4 個項目是成功的，而 Joe 只有一個項目成功。這是不是就意味著我干的比 Joe 好呢？這可不一定。如果我的 4 個項目每個盈利 1 百萬，而 Joe 那個成功項目的收入比他所有的 5 個項目成本的總和還要多出 1 千萬，那么他才是那個應當獲得提拔的人。
有些人會說“如果無法衡量，就無法管理”，這是站不住腳的。商業領域中，人們一直在管理著那些他們無法衡量價值的東西。你如何衡量一個公司里律師的生產效率？如何衡量市場部門、教育機構？你無法衡量，但你任然需要去管理它們（更多信息參考 Robert Austin）。
如果團隊的生產效率都很難衡量，那么個人對團隊的貢獻就更難衡量了。通過觀察每個迭代產出特性的多少，你可以對團隊的產出有個大致的概念。這是個很粗糙的感受，但是你可以感覺出團隊的速率是否有所提高，或者大致感覺出兩個團隊的生產效率哪個更高一些。但是個人的貢獻值就很難計算了。可能有的成員職責是實現特性，而有些成員的角色可能是協助者——他們負責幫助他人實現特性。他們的作用是提升整個團隊的生產效率——除非你是這個團隊中的一個開發者，你將很難搞清楚這些人的產出到底是什么。
如果你覺得這些情況還不夠復雜，在《經濟學人》（sep 13-19,2003）上有一篇關于生產效率趨勢的文章。經濟學家們似乎發現，由于 90 年代中對計算機產業的投資導致了如今商業領域中生產效率的提升。
這其中的重點是——增長是落后于投資的：“對計算機方面的投資并不會自動地推動生產效率提升，公司同時也需要重組他們的商業實踐”。同樣的滯后效應也出現在電力發明之后。
所以商業價值不僅難于衡量，還存在時延。很可能直到團隊構建的軟件發布多年之后，你才能夠衡量團隊的生產效率。
我可以理解為什么衡量生產效率如此具有誘惑性。如果可以做到，我們就可以更容易、更客觀地評估軟件。然而錯誤的衡量方式只會使問題惡化。我覺得必須承認：在這一領域，我們任然很無知。
來自: blog.jobbole.com本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！