[譯]軟體開發中個人生產力的差異
一些部落格讀者要求更多關於 “10x”名稱由來的背景資訊。這名稱的主要是研究人員發現，具有相同經驗的程式設計師或同一行業的不同團隊之間，生產力和品質有10倍的差異。
軟體開發中個人生產力的差異
Sackman, Erikson, and Grant (1968) 在 19世紀60年代末期的原始研究發現，個人的程式設計生產力有巨大差異。他們研究了平均有7年經驗的程式設計師，最好與最差的程式設計師比率在初始程式設計時間的比例是 20:1；debug 時間的比率超過 25:1 ;程式大小比例是 5:1；程式執行時間是 10:1；他們發現程式設計師的經驗與程式碼質量與生產力之間沒有任何關係。
詳細檢查 Sackman, Erickson, and Grant 的實驗會發現他們方法論的一些缺陷（包括將使用低階語言的程式設計師和高階語言的程式設計師的結果混在一起）。然而，即使考慮到這些缺陷，他們的資料仍然顯示出最好的程式設計師與最壞的程式設計師之間的效率相差 10 倍。 自原始研究以來的這些年，得出普通的結論是“程式設計師之間存在數量級的差異”，並得到了很多專業的程式設計師證實。 (Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000). 對程式設計師之間的巨大差異也有很多軼事支援。在20世紀80年代中期我在波音期間，有一個專案有大約80名程式設計師參與，有可能錯過一個不能錯過的截止日期。該專案對波音公司至關重要，因此他們將80名員工中的大多數人從該專案中移除，並帶來了一個人，
在壞的方面，個體的極端差異
Augustine 的研究發現，由於有些人沒有做出任何實際意義上的貢獻（沒有達到觸地得分的四分衛，沒有專利的發明人，沒有關閉案件的偵探等等），這些資料可能低估了生產力的實際變化。 但這在軟體中似乎是正確的。在一些已發表的關於軟體生產力的研究中，實驗中大概有10%的受試者無法完成實驗任務。在這些研究中，筆者寫道：“因此那些實驗物件的結果會被排出在我們資料集之外“。但在現實生活，如果某人“沒有完成任務”，你就不能只是“將他們的資料排出在資料集之外”。你必須等待他們完成，分配其他人做他們的工作，等等。有趣（並讓你恐懼）的是，軟體開發那些10%中的人在他們專案實際上貢獻是 負數 。
軟體開發中的團隊生產力變化
軟體專家長期觀察到，團隊的成產力和個人生產力的差異一樣多——都是一個數量級（Mills 1983.）部分原因是好的程式設計師傾向於集中在一些組織，糟糕的程式設計師傾向於另一些組織，這一觀察得到來自18個組織的166名程式的一項研究證實。（Demarco and Lister 1999） 在對七個相同專案的一項研究中，花費的努力比例是 3.4 :1 ，程式大小是 3:1 (Boehm, Gray, and Seewaldt 1984)。儘管生產力的範圍很廣，但在這項研究程式設計師們不是一個不同的群體。他們都是具有多年經驗並且參加電腦科學研究生課程的專業程式設計師。有理由認為對不太同質的群體的研究會產生更大的差異。 一個對程式設計團隊的早期研究表示，團隊完成統一的專案的程式大小比率是 5:1，時間差異是 2.6:1 (Weinberg and Schulman 1974). 用超過20年的資料構建了 Cocomo II 評估模型回看，Barry Boehm 和其他的研究者得出的結論是，用團隊中能力排15%的開發人員開發程式(效率)相當於排 90% 的 3.5 倍人月時間。如果一個團隊在程式語言或應用領域或兩者中都比另一個團隊更有經驗，那麼差異會更大。 用一份特別的資料來指出成產力的不同，那就是 Lotus 123 版本和 Microsoft Excel 3.0。他們都在1989-1990 間完成的電子表格桌面程式。找到兩家公司釋出類似專案的資料的案例是很少見的，這讓面對面比較（head-to-head comparison）特別有趣。在兩個專案的結果如下，Excel 用了 50 個工作年的時間寫了 649,000 行程式碼，而 Lotus 123 用了 260 個工作年的時候生產了 400,000 行程式碼。Excel 的團隊每一個工作年產生大概 13,000 行程式碼，而 Lotus 團隊每個工作年產生 1,500 行程式碼。這兩個團隊的生產力差異超過 8 倍，這資料支撐了不同個體及不同團隊成產力有數量級差異，這一普遍主張。
你看到了什麼？
您是否看到不同個體之間的能力差異為10; 1？不同的團隊之間？你工作過的最好的程式設計師比最差的程式設計師好多少？ 10：1甚至超過了範圍嗎？ 我期待聽到你的看法。
相關關聯
Augustine, N. R. 1979. “Augustine’s Laws and Major System Development Programs.” Defense Systems Management Review: 50-76.
Boehm, Barry W., and Philip N. Papaccio. 1988. “Understanding and Controlling Software Costs.” IEEE Transactions on Software Engineering SE-14, no. 10 (October): 1462-77.
Boehm, Barry, et al, 2000. Software Cost Estimation with Cocomo II, Boston, Mass.: Addison Wesley, 2000.
Boehm, Barry W., T. E. Gray, and T. Seewaldt. 1984. “Prototyping Versus Specifying: A Multiproject Experiment.” IEEE Transactions on Software Engineering SE-10, no. 3 (May): 290-303. Also in Jones 1986b.
Card, David N. 1987. “A Software Technology Evaluation Program.” Information and Software Technology 29, no. 6 (July/August): 291-300.
Curtis, Bill. 1981. “Substantiating Programmer Variability.” Proceedings of the IEEE 69, no. 7: 846.
Curtis, Bill, et al. 1986. “Software Psychology: The Need for an Interdisciplinary Program.” Proceedings of the IEEE 74, no. 8: 1092-1106.
DeMarco, Tom, and Timothy Lister. 1985. “Programmer Performance and the Effects of the Workplace.” Proceedings of the 8th International Conference on Software Engineering. Washington, D.C.: IEEE Computer Society Press, 268-72.
DeMarco, Tom and Timothy Lister, 1999. Peopleware: Productive Projects and Teams, 2d Ed. New York: Dorset House, 1999.
Mills, Harlan D. 1983. Software Productivity. Boston, Mass.: Little, Brown.
Sackman, H., W.J. Erikson, and E. E. Grant. 1968. “Exploratory Experimental Studies Comparing Online and Offline Programming Performance.” Communications of the ACM 11, no. 1 (January): 3-11.
Valett, J., and F. E. McGarry. 1989. “A Summary of Software Measurement Experiences in the Software Engineering Laboratory.” Journal of Systems and Software 9, no. 2 (February): 137-48.