布魯克斯法則是人們關於軟體專案管理的一種觀點。根據這個觀點，在一個已經進度落後的軟體專案上再增加人手只會使這個軟體專案進度更加落後 Frederick P Brooks Jr 《人月神話》 1995 1975 AddisonWesleyMaggie Fox NBC News October 21 2013 Better use the phone Why Obamacare website is such a fail Accessed Oct 21 2013 And sending in too many of thebest and the brightest might not be the right fix either software experts note They often cite Brookss Law which holds that adding people to a project slows it down。這一觀點是由佛瑞德布魯克斯在他 1975 年出版的《人月神話》一書中首先提出。根據佛瑞德布魯克斯的說法，在某些情況下，增加一個軟體專案的人手只會花費更多的開發時間。 說明 布魯克斯本人認為此法則「過於簡化」，但可以說明一些大致的情形。布魯克斯認為布魯克斯法則的原因是因為以下三點： 加入專案的人員需要一段時間後才會有生產力。布魯克斯稱此為時間。軟體計畫是複雜的工程產物，在專案中的新成員需要接受訓練，瞭解之前專案進行的情形，而訓練就會分散可用在專案上的人力，在新成員還沒有產出時，會暫時讓專案的生產力下降。新成員除了會需要資深工程師花時間訓練，減少其生產力外，還可能因不熟悉而增加程式的錯誤，讓專案的進度後退。 隨著人員增加，兩兩交流的數量也會快速增加（組合爆炸），溝通的成本也會增加 James Taylor A Survival Guide for Project Managers 2nd edition AMACOM 2006 p 21。進行相同工作的人員需要維持訊息同步，若越多人加入，維持訊息同步花的時間也會更多。 若是高度可分割的工作（像是清理旅館客房），多加人力可以減少整體進行的時間。但軟體專案中許多工作不容易分割，布魯克斯用一個例子來來說明：一個孕婦九個月可以生下小孩，「但九個孕婦無法在一個月內生下一個小孩」。 例外以及可能的處理方式 在布魯克斯法則中有些例外的部份，這也可能是可以避免布魯克斯法則的處理方式 In spite of Brookss law adding people to a late project remains commonplace I have evangelized this wellworn software engineering chestnut many times myself but I no longer think its true McConnell 1999The trouble is that there are important exceptions that many people do not take the time to consider when using Brookss law to justify something Berkun 2006 第一點要注意到布魯克斯法則是針對已經落後的專案 Implicit in those projects is that it applies only to the final phases of a project The question is How do you know whether youre in a projects final phases McConnell 1999。若在專案開發的較早階段加入人力，可能就可以讓專案維持在時程內（或至少趕上時程）We have found that adding people to a late project will always increase its cost but the project may not always be late since there may be sufficient schedule to absorb them and the project may not be at maximum staffing Only under certain degree of sequential constraints among project tasks will the project be delayed Hsia Hsu Kung 1999。很重要是要確定專案是否真的落後了，或者只是專案一開始過於樂觀所造成的。時間落後的專案時，大部份都是排程錯誤所導致的。若要讓專案在一個有意義並且可靠的時間內完成，修正排程是最好的作法 Late chaotic projects are likely to be much later than the project manager thinks project completion isnt three weeks away its six months away Go ahead and add staff Youll have time for them to become productive Your project will still be later than your plan but thats not a result of Brookss law Its a result of underestimating the project in the first place McConnell 1999 加入專案中人員的數量、品質以及其擔任角色也是需要考慮的。若要避免落後的專案出現布魯克斯法則，最簡單的方式是加上夠多的人，讓增加的生產力可以補足訓練以及溝通造成的生產力下降 Gordon and Lamb studied Brookss law and suggested that the best way to recover from a slipping schedule is to add more people than might be expected to be necessary and to add them early Hsia Hsu Kung 1999。可以加入優良的程式設計者或是專家，以減少訓練的時間 The law assumes that all added labour is equal which is not true Given the choice of adding a good programmer who knows the code base and is friends with half the team Id consider it Berkun 2006。也可以讓加入的人員參與專案的其他工作，例如品質保證或是撰寫檔案，只要任務夠明確，ramp up 時間就可以減短 The sad but popular approach is to throw people in without much explanation and let everyone figure it out for themselves But if the manager clarifies why Sally and Rupert are joining and defines good roles for them with input from the team theyll be set up to make a smooth transition Berkun 2006。 良好的分割也可以讓團隊成員為了溝通花的心力降到最低。較小的團隊可以處理較小的子問題，再由最上層團隊負責系統整合。若要以這種方式工作，一開始就要將問題以正確的方式進行分割，若分割的不正確，會讓問題更惡化。會阻礙二個在不同團隊，但其任務緊密耦合成員之間的溝通，就算在專案計劃中這二個任務不是緊密耦合的，也是一樣。 分割的例子就是設計模式，可以簡化工作分散的情形，因為整個團隊可以在設計模式的架構下，進行各自的工作。設計模式定義了程式設計者需要依循的規則，用標準語言簡化溝通，並且提供一致性以及可擴充套件性。 「百慕達計劃」（Bermuda plan）是指移除專案中大部份的開發者（送到百慕達），讓剩下來的開發者完成軟體，曾有人提出以此方式來避免布魯克斯法則。 相關條目 死亡行軍 專案管理 反面模式 林納斯定律 參考文獻 Category 資源浪費 Category 協作 Category 電腦結構陳述