布鲁克斯法则（）是人們关于軟件項目管理的一種观点。根据这个观点，“在一个已經進度落後的软件项目上再增加人手只会使這個軟件項目進度更加落後”。这一觀點是由佛瑞德·布魯克斯在他1975年出版的《人月神话》一书中首先提出。根据佛瑞德·布魯克斯的说法，在某些情况下，增加一个軟件项目的人手只會花费更多的開發時間。
說明
布魯克斯本人認為此法則「過於簡化」。進行相同工作的人員需要維持訊息同步，若越多人加入，維持訊息同步花的時間也會更多。
#若是高度可分割的工作（像是清理旅館客房），多加人力可以減少整體進行的時間。但軟體專案中許多工作不容易分割，布魯克斯用一個例子來來說明：一個孕婦九個月可以生下小孩，「但九個孕婦無法在一個月內生下一個小孩」。
例外以及可能的處理方式
在布鲁克斯法则中有些例外的部份，這也可能是可以避免布鲁克斯法则的處理方式
第一點要注意到布鲁克斯法则是針對已經落後的專案。若在專案開發的較早階段加入人力，可能就可以讓專案維持在時程內（或至少趕上時程）。很重要是要確定專案是否真的落後了，或者只是專案一開始過於樂觀所造成的。時間落後的專案時，大部份都是排程錯誤所導致的。若要讓專案在一個有意義並且可靠的時間內完成，修正排程是最好的作法
加入專案中人員的數量、品質以及其擔任角色也是需要考慮的。若要避免落後的專案出現布鲁克斯法则，最簡單的方式是加上夠多的人，讓增加的生產力可以補足訓練以及溝通造成的生產力下降。可以加入優良的程式設計者或是專家，以減少訓練的時間。也可以讓加入的人員參與專案的其他工作，例如品質保證或是撰寫文件，只要任務夠明確，ramp up時間就可以減短。
良好的分割也可以讓團隊成員為了溝通花的心力降到最低。較小的團隊可以處理較小的子問題，再由最上層團隊負責系統整合。若要以這種方式工作，一開始就要將問題以正確的方式進行分割，若分割的不正確，會讓問題更惡化。會阻礙二個在不同團隊，但其任務緊密耦合成員之間的溝通，就算在專案計劃中這二個任務不是緊密耦合的，也是一樣。
分割的例子就是設計模式，可以簡化工作分散的情形，因為整個團隊可以在設計模式的架構下，進行各自的工作。設計模式定義了程式設計者需要依循的規則，用標準語言簡化溝通，並且提供一致性以及可擴展性。
「百慕達計劃」（Bermuda plan）是指移除專案中大部份的開發者（送到百慕達），讓剩下來的開發者完成軟體，曾有人提出以此方式來避免布鲁克斯法则。
相關條目
*死亡行军 (项目管理)
*反面模式
*林纳斯定律
参考文献
评论 (0)