布魯克斯法則

布魯克斯法則（英語：Brooks's law）是人們關於軟體項目管理的一種觀點。根據這個觀點，「在一個已經進度落後的軟體項目上再增加人手只會使這個軟體項目進度更加落後」^[1][2]。這一觀點是由佛瑞德·布魯克斯在他1975年出版的《人月神話》一書中首先提出。根據佛瑞德·布魯克斯的說法，在某些情況下，增加一個軟體項目的人手只會花費更多的開發時間。

說明

布魯克斯本人認為此法則「過於簡化」^[1]，但可以說明一些大致的情形。布魯克斯認為布魯克斯法則的原因是因為以下三點：

1. 加入專案的人員需要一段時間後才會有生產力。布魯克斯稱此為ramp-up（英語：ramp-up）時間。軟體計畫是複雜的工程產物，在專案中的新成員需要接受訓練，瞭解之前專案進行的情形，而訓練就會分散可用在專案上的人力，在新成員還沒有產出時，會暫時讓專案的生產力下降。新成員除了會需要資深工程師花時間訓練，減少其生產力外，還可能因不熟悉而增加程式的錯誤，讓專案的進度後退。
2. 隨著人員增加，兩兩交流的數量也會快速增加（組合爆炸），溝通的成本也會增加^[3]。進行相同工作的人員需要維持訊息同步，若越多人加入，維持訊息同步花的時間也會更多。
3. 若是高度可分割的工作（像是清理旅館客房），多加人力可以減少整體進行的時間。但軟體專案中許多工作不容易分割，布魯克斯用一個例子來來說明：一個孕婦九個月可以生下小孩，「但九個孕婦無法在一個月內生下一個小孩」。

例外以及可能的處理方式

在布魯克斯法則中有些例外的部份，這也可能是可以避免布魯克斯法則的處理方式^[4][5]

第一點要注意到布魯克斯法則是針對已經落後的專案^[6]。若在專案開發的較早階段加入人力，可能就可以讓專案維持在時程內（或至少趕上時程）^[7]。很重要是要確定專案是否真的落後了，或者只是專案一開始過於樂觀所造成的。時間落後的專案時，大部份都是排程錯誤所導致的。若要讓專案在一個有意義並且可靠的時間內完成，修正排程是最好的作法^[8]

加入專案中人員的數量、品質以及其擔任角色也是需要考慮的。若要避免落後的專案出現布魯克斯法則，最簡單的方式是加上夠多的人，讓增加的生產力可以補足訓練以及溝通造成的生產力下降^[9]。可以加入優良的程式設計者或是專家，以減少訓練的時間^[10]。也可以讓加入的人員參與專案的其他工作，例如品質保證或是撰寫文件，只要任務夠明確，ramp up時間就可以減短^[11]。

良好的分割也可以讓團隊成員為了溝通花的心力降到最低。較小的團隊可以處理較小的子問題，再由最上層團隊負責系統整合。若要以這種方式工作，一開始就要將問題以正確的方式進行分割，若分割的不正確，會讓問題更惡化。會阻礙二個在不同團隊，但其任務緊密耦合成員之間的溝通，就算在專案計劃中這二個任務不是緊密耦合的，也是一樣。

分割的例子就是設計模式，可以簡化工作分散的情形，因為整個團隊可以在設計模式的架構下，進行各自的工作。設計模式定義了程式設計者需要依循的規則，用標準語言簡化溝通，並且提供一致性以及可擴展性。

「百慕達計劃」（Bermuda plan）是指移除專案中大部份的開發者（送到百慕達），讓剩下來的開發者完成軟體，曾有人提出以此方式來避免布魯克斯法則^[12][13]。

相關條目

• 死亡行軍 (專案管理)
• 反面模式
• 林納斯定律