布魯克斯法則
布魯克斯法則（英語：Brooks's law）是人們關於軟件項目管理的一種觀點。根據這個觀點，「在一個已經進度落後的軟件項目上再增加人手只會使這個軟件項目進度更加落後」[1][2]。這一觀點是由佛瑞德·布魯克斯在他1975年出版的《人月神話》一書中首先提出。根據佛瑞德·布魯克斯的說法，在某些情況下，增加一個軟件項目的人手只會花費更多的開發時間。
說明
[編輯]布魯克斯本人認為此法則「過於簡化」[1]，但可以說明一些大致的情形。布魯克斯認為布魯克斯法則的原因是因為以下三點：
- 加入專案的人員需要一段時間後才會有生產力。布魯克斯稱此為ramp-up時間。軟件計劃是複雜的工程產物，在專案中的新成員需要接受訓練，瞭解之前專案進行的情形，而訓練就會分散可用在專案上的人力，在新成員還沒有產出時，會暫時讓專案的生產力下降。新成員除了會需要資深工程師花時間訓練，減少其生產力外，還可能因不熟悉而增加程式的錯誤，讓專案的進度後退。
- 隨着人員增加，兩兩交流的數量也會快速增加（組合爆炸），溝通的成本也會增加[3]。進行相同工作的人員需要維持訊息同步，若越多人加入，維持訊息同步花的時間也會更多。
- 若是高度可分割的工作（像是清理旅館客房），多加人力可以減少整體進行的時間。但軟件專案中許多工作不容易分割，布魯克斯用一個例子來來說明：一個孕婦九個月可以生下小孩，「但九個孕婦無法在一個月內生下一個小孩」。
例外以及可能的處理方式
[編輯]在布魯克斯法則中有些例外的部份，這也可能是可以避免布魯克斯法則的處理方式[4][5]
第一點要注意到布魯克斯法則是針對已經落後的專案[6]。若在專案開發的較早階段加入人力，可能就可以讓專案維持在時程內（或至少趕上時程）[7]。很重要是要確定專案是否真的落後了，或者只是專案一開始過於樂觀所造成的。時間落後的專案時，大部份都是排程錯誤所導致的。若要讓專案在一個有意義並且可靠的時間內完成，修正排程是最好的作法[8]
加入專案中人員的數量、品質以及其擔任角色也是需要考慮的。若要避免落後的專案出現布魯克斯法則，最簡單的方式是加上夠多的人，讓增加的生產力可以補足訓練以及溝通造成的生產力下降[9]。可以加入優良的程式設計者或是專家，以減少訓練的時間[10]。也可以讓加入的人員參與專案的其他工作，例如品質保證或是撰寫文件，只要任務夠明確，ramp up時間就可以減短[11]。
良好的分割也可以讓團隊成員為了溝通花的心力降到最低。較小的團隊可以處理較小的子問題，再由最上層團隊負責系統整合。若要以這種方式工作，一開始就要將問題以正確的方式進行分割，若分割的不正確，會讓問題更惡化。會阻礙二個在不同團隊，但其任務緊密耦合成員之間的溝通，就算在專案計劃中這二個任務不是緊密耦合的，也是一樣。
分割的例子就是設計模式，可以簡化工作分散的情形，因為整個團隊可以在設計模式的架構下，進行各自的工作。設計模式定義了程式設計者需要依循的規則，用標準語言簡化溝通，並且提供一致性以及可擴展性。
「百慕達計劃」（Bermuda plan）是指移除專案中大部份的開發者（送到百慕達），讓剩下來的開發者完成軟件，曾有人提出以此方式來避免布魯克斯法則[12][13]。
相關條目
[編輯]參考文獻
[編輯]- ^ 1.0 1.1 Frederick P. Brooks, Jr. 《人月神話》. 1995 [1975]. Addison-Wesley.
- ^ Maggie 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 the "best and the brightest』 might not be the right fix, either, software experts note. They often cite Brooks’s Law, which holds that adding people to a project slows it down."
- ^ James Taylor, "A Survival Guide for Project Managers", 2nd edition, AMACOM [需要解釋], 2006, ISBN 978-0814408773, p. 21.
- ^ "In spite of Brooks's law, adding people to a late project remains commonplace" ... "I have evangelized this well-worn software engineering chestnut many times myself, but I no longer think it's true". (McConnell, 1999)
- ^ "The trouble is that there are important exceptions that many people do not take the time to consider when using Brooks's 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 you're in a project's 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 isn't three weeks away, it's six months away. Go ahead and add staff. You'll have time for them to become productive. Your project will still be later than your plan, but that's not a result of Brooks's law. It's a result of underestimating the project in the first place." (McConnell, 1999)
- ^ "Gordon and Lamb studied Brooks's 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, I'd consider it." (Berkun, 2006)
- ^ "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, they'll be set up to make a smooth transition." (Berkun, 2006)
- ^ Shea, Tom. Developers Unveil 'Vaporware'. InfoWorld (InfoWorld Media Group). 7 May 1984, 6 (19): 48 [2010-04-13]. ISSN 0199-6649.
- ^ Bruno, Eric J. Curly Braces #9: Was Fred Brooks wrong about late software projects?. Java Magazine. Oracle Corporation. 2023-02-06 [2024-03-18]. （原始內容存檔於2024-01-19）.