預估 | 人月神話：軟體專案管理之道

軟體預估的困境#

一個程式設計任務到底需要多少時間？Brooks 指出，整個軟體產業迫切需要更好的預估資料，但現有的數據少得可憐，而且大多數程式設計師對預估這件事既不情願也不擅長。

問題的核心在於：我們往往用樂觀主義來替代嚴謹的分析。程式設計師傾向於低估任務的困難度，而管理者又沒有足夠的經驗數據來質疑這些估計。

軟體開發的預估不能靠直覺。缺乏經驗數據支撐的時程承諾，無異於一場賭博。

Brooks 提出一個關鍵洞察：工作量與程式規模不是線性關係。研究數據顯示，工作量的增長大約遵循以下公式：

工作量 = （常數）×（指令數量）^1.5

這意味著一個兩倍大的程式，所需的工作量不是兩倍，而是接近三倍。程式越大，各部分之間的互動和整合成本就越高，這種超線性增長是無法避免的。

Brooks 蒐集了多個來源的實際生產力數據，揭示了一些令人警醒的事實：

在一個程式設計工作日中，只有大約 50% 的時間用於實際的程式設計和除錯。其餘時間被各種開銷所消耗：

這意味著在預估時，不能假設程式設計師每天有 8 小時的有效產出。實際的生產性工作時間大約只有一半。

Joel Aron 在 IBM 的研究顯示，生產力隨互動程度而劇烈變化：

當程式設計師需要與許多其他人協調工作時，生產力可以下降到原來的六分之一。這再次印證了《人月神話》中關於溝通成本的核心論點。

John Harr 在 Bell Labs 的電子交換系統（ESS）專案中發現：

這說明不同類型的程式設計工作，其生產力可以相差近四倍。作業系統涉及更多的互動、更複雜的約束條件和更嚴格的可靠性要求。

IBM OS/360 的實際經驗與上述數據一致：系統程式設計的生產力大約是每人每年 600 到 800 條已除錯的指令。這個數字低得令人沮喪，但卻反覆在不同的大型專案中得到驗證。

Brooks 引用了 Corbató 在 MIT MULTICS 專案中的數據，帶來了一個重要的好消息：

這意味著高階語言帶來了大約 五倍的生產力提升（以交付的機器指令計算）。

生產力以高階語言的陳述句數來衡量時大致恆定，而非以機器指令數來衡量。這意味著使用高階語言直接提升了每單位工作量所能交付的功能數量。

這是一個深刻的洞見：程式設計師的產出瓶頸在於思考和表達的複雜度，而非打字速度。高階語言讓每一行程式碼承載更多的功能，因此直接提升了實質產出。

Brooks 的結論是：我們不能僅依據程式碼行數來預估工作量。正確的預估必須考慮以下因素：

與其估算「寫多少行程式碼」，不如估算「解決多少個獨立的設計問題」。前者會因語言和風格而大幅波動，後者才真正反映了任務的本質複雜度。