跳轉到

1975 - 神話人月：Brooks 定律與軟體複雜性的本質#

案件摘要#

1975 年，Fred Brooks 出版《The Mythical Man-Month》（神話人月）—— 他是 IBM OS/360 的專案總管（見「1964-IBMSystem360.md」），把那場五億美元賭注的 管理教訓寫成了書。核心控訴只有一句：「向延遲的專案加人，只會讓它更延遲。」 人力與時間不可互換——這是軟體專案管理的第一定律，也是此後所有 小團隊開發（含敏捷）的理論根據。本書 1975 年出版至今仍在印。

前因 -- 為什麼會有這個案子#

  • OS/360 的現場：360 的開發動員超過 1000 人、耗費 5000 人年， 卻延期多年、每版修正上千個 bug——Brooks 是親歷者，不是旁觀者。
  • 「人月」的迷信：專案落後時，管理者的直覺反應是加人—— 「工作量 100 人月，就派 100 人做 1 個月」——Brooks 指出這個換算從根本上是神話。
  • 書名的由來：取自西塞羅式的反諷——

    「計畫落後就加人，只會更落後（Adding manpower to a late software project makes it later）」——Brooks's Law。

  • 複雜性是元凶：軟體的本質困難（essential complexity）無法用工具消除—— Brooks 把 360 的「五個實驗室戰爭」（見 360 案）歸因於概念完整性的崩壞。
  • 關鍵推理：軟體專案是系統，不是任務堆疊——
\[ \text{產出} \ne n \times \text{個人產出} \quad\Longrightarrow\quad \text{產出} = f(n, \text{溝通}, \text{任務分割}, \text{一致性}). \]

線索與推理 -- 數學式、程式、理論#

第一條線索：溝通路徑 \(O(n^2)\)#

\(n\) 人的團隊，兩兩之間的溝通路徑數為：

\[ P(n) = \frac{n(n-1)}{2} \]
  • 5 人團隊：10 條；15 人：105 條；50 人：1225 條—— 人數線性成長，溝通成本二次方爆炸。
  • 每條路徑都有耗損：開會、同步、誤解、返工——設每次耗損 \(\tau\) ， 團隊總溝通負債為 \(\frac{n(n-1)}{2}\tau\) ，這是加人變延遲的數學核心。
  • 對比： \(n\) 個獨立農夫摘棉花（任務可完全分割）確實是線性的—— 「人月神話」之所以是神話，正是因為軟體不是摘棉花。

第二條線索：Brooks's Law 的推導#

設專案剩餘工作量 \(W\) 人月，原有人數 \(n\) ，新人數 \(m\) 個（訓練期 \(s\) 人月/人）：

\[ \text{加人後工期} \; T' = \frac{W + s\,m + \tau\,\frac{(n+m)(n+m-1) - n(n-1)}{2}}{n + m \cdot \eta(m)} \quad\text{vs}\quad T = \frac{W}{n} \]
  • 新人不是即時產出：他們要先被訓練（ \(s\,m\) ），訓練者還要從生產線上抽身。
  • 溝通負債暴增：加 \(m\) 人新增的溝通路徑為 \(\frac{(n+m)(n+m-1) - n(n-1)}{2}\) 條。
  • 當 \(m\,\eta(m)\) 的產出增益 < \(s\,m + \Delta P(n,m)\,\tau\) 的負債時——
\[ T' > T \quad\Longrightarrow\quad \text{加人反而更慢：Brooks's Law 成立}. \]
  • 任務可分割性是前提：只有任務完全可分割（如摘棉花）時加人才有效； 軟體的任務之間有隱含耦合（介面、時序、共享狀態），分割本身就是成本。

第三條線索：本質複雜度 vs 偶然複雜度（No Silver Bullet 前兆）#

Brooks 在 1986 年的《No Silver Bullet》中把本書的複雜性論證形式化：

\[ \text{總複雜度} = \underbrace{E}_{\text{本質（essential）}} + \underbrace{A}_{\text{偶然（accidental）}} \]
  • 偶然複雜度 \(A\) ：語言太原始、工具太差、文件缺失——高階語言、IDE、工具鏈可以消除。
  • 本質複雜度 \(E\) ：問題領域本身的糾結（規格、狀態空間、不可見性）——沒有銀彈能消除。
  • 軟體有「不可見性」：沒有幾何圖形可以畫出程式的全部結構—— 這是軟體比硬體更難管理的根本原因。
  • 推論：生產力的提升上限為 \(\frac{E+A}{E}\) ——當 \(A \to 0\) ， 再好的工具也只能逼近 \(E\) ——這是對「十年內自動寫程式」幻想的數學駁斥。

第四條線索：外科手術團隊與概念完整性#

  • 外科手術團隊（surgical team）：與其 10 人平權共寫一個模組， 不如1 位主刀（chief surgeon）＋ 1 位副手＋編輯、測試、工具支援各司其職—— 溝通路徑從 \(\frac{10 \cdot 9}{2}=45\) 條驟減為星形的 9 條（都通往主刀）。
  • 概念完整性（conceptual integrity）：

    「一個系統的品質，取決於概念完整性——比功能強大更重要。」 360 的 ISA 之所以成功（見 360 案），正是 Brooks 與 Blaauw 靠統一概念說服五個實驗室的結果。

  • 第二系統效應（second-system effect）：設計者的第二個系統最危險—— 第一次的成功讓他自信過剩，塞入所有花俏功能（360 的後續系統即是一例）； 解方：自我節制（self-restraint），功能要有取捨。

第五條線索：文件與設計的一致性#

  • 「文件就是系統」：Brooks 主張，大型專案的關鍵產出不是程式碼，而是一套一致性的文件 ——目標、規格、進度、預算、組織圖——它們是團隊之間唯一的共享真相。
  • 文件的一致性檢驗：五份文件互相矛盾，就是概念完整性崩壞的徵兆—— 360 的 ISA 手冊（Principles of Operation）正是「以文件統一概念」的實踐。
  • 與瀑布文書化的差別：瀑布把文件當簽核憑證（見「1970-Waterfall瀑布模型.md」）， Brooks 把文件當溝通工具——文件的存在是為了讓 \(\frac{n(n-1)}{2}\) 條溝通路徑 有一個共同的參考點，而不是為了蓋章。

Python 實作：Brooks's Law 模擬#

# 團隊完成 W 人月的任務，比較「不加人」vs「中途加人」的完成時間
# T = 剩餘工作量 / 有效產出 + 溝通負債

def finish_time(W, n, m=0, s=2.0, tau=0.02):
    """W: 剩餘工作量(人月), n: 原有人數, m: 加的人數
       s: 每個新人的訓練耗損(人月), tau: 每條溝通路徑的單位耗損"""
    total_people = n + m
    comm_paths = total_people * (total_people - 1) / 2 - n * (n - 1) / 2  # 新增的溝通路徑
    training = s * m                                    # 新人訓練成本（且占用老人時間）
    productivity = n + m * 0.5                          # 新人前期只有一半戰力
    return (W + training) / productivity + comm_paths * tau

W = 100                                                # 剩餘 100 人月的工作量
t_alone = finish_time(W, n=10)                         # 10 人自己做完
t_added = finish_time(W, n=10, m=10, tau=0.05)         # 中途再塞 10 人進去
print(f"10 人自己做完：{t_alone:.1f} 個月")
print(f"中途加 10 人：{t_added:.1f} 個月")
print("=> 加人更延期！" if t_added > t_alone else "=> 加人有幫助")

# 溝通路徑隨人數成長：n(n-1)/2
for n in (5, 15, 50):
    print(f"{n:>2} 人團隊的溝通路徑：{n*(n-1)//2} 條")
# 10 人自己做完：10.0 個月
# 中途加 10 人：15.2 個月
# => 加人更延期！
#  5 人團隊的溝通路徑：10 條
# 15 人團隊的溝通路徑：105 條
# 50 人團隊的溝通路徑：1225 條

結案 -- 後果與影響#

  • 專案管理的教科書：《The Mythical Man-Month》1975 年出版、1995 年二十周年紀念版， 至今仍在印——軟體管理書籍中唯一跨越半世紀的經典。
  • 敏捷小團隊的理論根據：「兩個披薩團隊」、7±2 人的衝刺團隊、跨功能小隊—— 都是對 \(O(n^2)\) 溝通成本的直接回應——Brooks 是敏捷的理論前驅。
  • Brooks's Law 進入日常語言：「加人只會更延期」成為專案管理的第一條共識定律， 與 Murphy's Law、Parkinson's Law 並列。
  • 「No Silver Bullet」（1986）的先聲：本書的本質複雜度論證在 1986 年被形式化—— Brooks 宣告「十年內不會有讓生產力提升十倍的銀彈」——至今仍未被推翻。
  • 概念完整性成為設計準則：從 360 的 ISA 到 Unix 的「do one thing well」、 再到產品設計的「簡潔優於功能」——節制是美德的設計哲學由此確立。
  • 外科手術團隊的遺產： chief programmer、tech lead 機制、 以及現代「主程式設計師＋支援團隊」的組織模式，皆源於此書第 7 章。
  • 獻給下一代的警告：1995 年紀念版新增四章，包括「Propositions of The Mythical Man-Month: True or False?」——Brooks 親自重審自己的定律，結論是二十年了，依然為真。

關鍵人物與文獻#

  • Fred Brooks（1931–2022，IBM → UNC Chapel Hill）：OS/360 專案總管； 《The Mythical Man-Month: Essays on Software Engineering》(Addison-Wesley, 1975； Anniversary Edition 1995)；「No Silver Bullet」(IEEE Computer, 1987)。
  • Gerrit Blaauw：360 架構文件化的合作者，概念完整性的理論夥伴 ——兩人後來合著 Computer Architecture: Concepts and Evolution (1997)。
  • Harlan Mills（IBM）：外科手術團隊思想的實踐者（chief programmer team） ——Cleanroom 軟體開發法的作者。
  • Barry Boehm：COCOMO 估算模型（1981）以實證資料支持 Brooks 的非線性論證 ——見「1968-NATO軟體工程會議.md」。
  • 文獻：F. Brooks, The Mythical Man-Month, 1975——「人月神話」的原始出處。
  • 相關案件：1964-IBMSystem360.md、1968-NATO軟體工程會議.md、1970-Waterfall瀑布模型.md。