Martin Fowler：仍無法衡量軟件開發(fā)的生產(chǎn)效率
我們見到過太多關于軟件開發(fā)過程、設計實踐以及類似內(nèi)容充滿激情的討論。它們當中有很多是無法驗證的，因為軟件行業(yè)沒有能去衡量代表開發(fā)效率的一些基本元素。特別是我們無法合理地衡量生產(chǎn)效率。
當然，生產(chǎn)效率可以通過觀察生產(chǎn)過程的輸入與產(chǎn)出來衡量。所以，要衡量軟件開發(fā)的生產(chǎn)效率，你就必須去衡量軟件開發(fā)的產(chǎn)出。我們無法衡量生產(chǎn)效率的根源就在于我們無法衡量產(chǎn)出。
并不是說人們沒有嘗試過。最令我氣憤的就是那些用代碼行數(shù)來衡量生產(chǎn)效率的研究。首先，總是存在不同的語言、不同的計數(shù)方式、不同的格式化風格造成的問題。即使采用一致的計數(shù)標準，衡量相同語言代碼，且代碼被自動格式化為統(tǒng)一的風格，代碼行數(shù)仍然無法正確反映產(chǎn)出。
任何優(yōu)秀的開發(fā)者都知道，讓他們?nèi)崿F(xiàn)一個特定功能所需的代碼行數(shù)可能相差巨大。除此之外，精心設計以及重構過的代碼都會更短小，因為它消除了冗余。復制粘貼風格的程序會有更多的行數(shù)以及更差的設計，因為它充滿冗余。這很好證明，只要你使用一個支持inline method的重構工具去修改一個程序。只需用這個工具去重構那些普通函數(shù)，你就可以輕易讓代碼行數(shù)翻倍。
你可能覺得已經(jīng)沒人再用代碼行數(shù)了，實際上每個月我都能看到基于代碼行數(shù)的生產(chǎn)效率研究論文，甚至是在類似IEEE Software這樣令人尊敬的期刊上。
也不是說代碼行數(shù)是個完全沒用的衡量，它能很好代表系統(tǒng)規(guī)模。我可以很確定一個100 KLOC（KLOC=千代碼行）的系統(tǒng)比一個10KLOC的系統(tǒng)要大。但是如果我用了一年時間寫了那個100KLOC的系統(tǒng)，而Joe在一年內(nèi)用10KLOC實現(xiàn)了同樣的系統(tǒng)，這無法說明我更高產(chǎn)。實際上我得到的結論是：我們的生產(chǎn)效率差不多，但我的系統(tǒng)設計得更差。
另一個經(jīng)常被用來衡量產(chǎn)出的方法是使用功能點（Function Points）。雖然我更同情這種做法，但它并不能令我信服。我聽過很多這樣的故事：同一個系統(tǒng)，不同人統(tǒng)計的功能點數(shù)目相差有3倍之多。
即使我們能夠找到一種方式用功能點精確衡量功能，我認為這仍然無助于解決生產(chǎn)效率的衡量問題。可以這么說，衡量功能點是觀察軟件開發(fā)直接產(chǎn)出的方式，但真實產(chǎn)出確是另一回事。假設有一個精確的功能點計算系統(tǒng)，如果我花一年發(fā)布了一個有100個FP（功能點）的系統(tǒng)，同時Joe也用一年發(fā)布了一個50FP的系統(tǒng)，是不是就能說我更高產(chǎn)？我覺得不是。很可能我做的100FP中只有30個對我的客戶來說是真正有用的功能，而Joe開發(fā)的功能則全部都是有用的。我會這么說：雖然我的直接生產(chǎn)效率更高，但Joe的真實生產(chǎn)效率更高。
Jeff Grigg向我指出，還存在影響功能點交付的內(nèi)因。我的100個功能點可能提供的都是很相似的功能，我之所以花了一年時間，是因為我沒有很好的重用代碼。Joe的50個功能都是差別相當大的（對他來說可不是個好消息），所以幾乎沒有重用的可能。盡管需要實現(xiàn)50個相當不同的功能，并且?guī)缀鯚o法重用代碼，但Joe真的很棒，他在一年之內(nèi)就全部完成了。
但這些都忽視了一點：即使是有用的功能也無法真正用來做衡量。假設我有了進步，完成了30個有用的功能點，同時Joe只完成了15個。但有人會發(fā)現(xiàn)Joe的15個功能點為我們的客戶增加了1千萬的盈利，但我的工作成果帶來的盈利只有500萬。我仍然認為Joe的真實生產(chǎn)效率要比我高，因為他產(chǎn)出了更多的商業(yè)價值。并且我堅信任何真正的軟件生產(chǎn)效率衡量必須基于其所帶來的商業(yè)價值。
這種思想也適用于成功率。通常關于軟件項目成功的判斷都是虛假的，因為人們并不理解什么是失敗。我可以說一個成功的項目就是產(chǎn)生的商業(yè)價值大于研發(fā)成本的項目。假如Joe和我各參與了5個項目，我的4個項目是成功的，而Joe只有一個項目成功。這是不是就意味著我干的比Joe好呢？這可不一定。如果我的4個項目每個盈利1百萬，而Joe那個成功項目的收入比他所有的5個項目成本的總和還要多出1千萬，那么他才是那個應當獲得提拔的人。
有些人會說“如果無法衡量，就無法管理”，這是站不住腳的。商業(yè)領域中，人們一直在管理著那些他們無法衡量價值的東西。你如何衡量一個公司里律師的生產(chǎn)效率？如何衡量市場部門、教育機構？你無法衡量，但你任然需要去管理它們（更多信息參考Robert Austin）。
如果團隊的生產(chǎn)效率都很難衡量，那么個人對團隊的貢獻就更難衡量了。通過觀察每個迭代產(chǎn)出特性的多少，你可以對團隊的產(chǎn)出有個大致的概念。這是個很粗糙的感受，但是你可以感覺出團隊的速率是否有所提高，或者大致感覺出兩個團隊的生產(chǎn)效率哪個更高一些。但是個人的貢獻值就很難計算了。可能有的成員職責是實現(xiàn)特性，而有些成員的角色可能是協(xié)助者——他們負責幫助他人實現(xiàn)特性。他們的作用是提升整個團隊的生產(chǎn)效率——除非你是這個團隊中的一個開發(fā)者，你將很難搞清楚這些人的產(chǎn)出到底是什么。
如果你覺得這些情況還不夠復雜，在《經(jīng)濟學人》（sep 13-19,2003）上有一篇關于生產(chǎn)效率趨勢的文章。經(jīng)濟學家們似乎發(fā)現(xiàn)，由于90年代中對計算機產(chǎn)業(yè)的投資導致了如今商業(yè)領域中生產(chǎn)效率的提升。
這其中的重點是——增長是落后于投資的：“對計算機方面的投資并不會自動地推動生產(chǎn)效率提升，公司同時也需要重組他們的商業(yè)實踐”。同樣的滯后效應也出現(xiàn)在電力發(fā)明之后。
所以商業(yè)價值不僅難于衡量，還存在時延。很可能直到團隊構建的軟件發(fā)布多年之后，你才能夠衡量團隊的生產(chǎn)效率。
我可以理解為什么衡量生產(chǎn)效率如此具有誘惑性。如果可以做到，我們就可以更容易、更客觀地評估軟件。然而錯誤的衡量方式只會使問題惡化。我覺得必須承認：在這一領域，我們?nèi)匀缓軣o知。
原文鏈接： Martin Fowler 翻譯： 伯樂在線 - 治不好你我就不是獸醫(yī)
