布魯克斯法則
出自 MBA智库百科(https://wiki.mbalib.com/)
布魯克斯法則(Brook's Law)也叫Brooks法則是指一種實踐，應用全面、嚴密的方法來描述組織流程、信息系統、人員和組織子單元的當前或未來結構，以便其與組織的核心目標和戰略方向保持一致。
目錄 |
布魯克斯法則是指投入更多的人來開發一個緊急的項目只會讓進度更慢。更多並不意味著更好，有些事最好是一個人來乾。
布魯克斯法則是由被認為是“IBM 360系統之父”的Frederick P. Brooks，Jr提出的，他認為：向進度落後的項目中增加人手，只會使項目更加落後。例如“三個和尚沒水吃，廚師太多做壞湯。”
Frederick P. Brooks，Jr.是北羅萊納大學Kenan-Flagler商學院的電腦科學教授。Brooks被認為是“IBM 360系統之父”，他擔任了360系統的項目經理，以及360操作系統項目設計階段的經理。憑藉在上述項目的傑出貢獻，他、Bob Evans和Erich Bloch在1985年榮獲了美國國家技術獎（National Medal of Techology）。早期，Brooks曾擔任IBM Stretch和Harvest電腦的體繫結構師。
在查布爾希爾，Brooks博士創立了電腦科學系，併在1964至1984年期間擔任主席。他曾任職於美國國家科技局和國防科學技術委員會。Brooks目前的教學和研究方向是電腦體繫結構、分子模型繪圖和虛擬環境。
布魯克斯是上世紀60年代IBM System/360的操作系統OS/360的開發負責人，這之後基於當時的經驗寫了人月神話一書。
這是描述大規模軟體開發難度的一本劃時代的書。看下麵的示例。有這樣一個項目需要12個人月，那麼3個人4個月就能完成該任務。然後，在每個月設定觀測點A/B/C/D。
但是一個月就需要結束的A結果花了兩個月完成。這相比於預估時已經是兩個月之後了。怎麼辦？管理者有下麵的對策。
- 雖然當初的估算是對的，僅僅是最初的工程弄錯了。也就是說推斷剩下9人月。因為有9人月的工作，兩個月完成的話需要9/2=4.5人。追加兩個人到這3人團隊中。當初的估算弄錯了，不是12人月而是需要24人月。因為已經花了6人月的時間了剩下需要18人月。2個月完成的話，需要18/2=9人。追加6人到當初的3人團隊。
- 重新安排任務。追加充足的時間到新的計劃了。
- 調整工作目標。減少工作。
那麼，應該採用什麼方法呢。最開始的二個方法，不修改工作目標和工作進度表的話最初4個月完成目標的期望就破滅了。
假如追加2個人，這兩人的培訓成本，3人完成的工作用5個來做，就需要重新安排工作，這些成本沒有被追加到估算中，結果的話最終期限無法完成。追加6個人的情況，這種成本加的更多。
這就是布魯克斯法則：追加人員到延遲的項目更會影響項目的進度。如布魯克斯所寫的那樣，無法按進度完成工作的話，只能降低工作目標作業。
首先，我們對估算技術缺乏有效的研究，更加嚴肅地說，它反映了一種悄無聲息，但並不真實的假設——一切都將運作良好。
第二，我們採用的估算技術隱含地假設人和月可以互換，錯誤地將進度與工作量相互混淆。
第三，由於對自己的估算缺乏信心，軟體經理通常不會有耐心持續地進行估算這項工作。
第四，對進度缺少跟蹤和監督。其他工程領域中，經過驗證的跟蹤技術和常規監督程式，在軟體工程中常常被認為是無謂的舉動。
第五，當意識到進度的偏移時，下意識（以及傳統）的反應是增加人力。這就像使用汽油滅火一樣，只會使事情更糟。越來越大的火勢需要更多的汽油，從而進入了一場註定會導致災難的迴圈。
- 解析
第二點中提到的關於人月不可互換。舉個例子就是說:有一個10人月工作量的項目不能單純的分配個5個人用2個月的時間來完成。因為程式員在工作當中還需要交流的時間，各子項目間還可能會有依賴關係，因此本來10人月的項目分配給5個人之後，它的實際成本就提升了。
有人可能會說一個人做就可以了，但為了節省時間，在規定的時間里完成項目，還是需要團隊合作的。
第三點:為了更有效的實施這一點，我們需要使用一個版本控制工具，比如說:SVN。還需要設置檢查點，里程碑，以及基線，從而準確的跟蹤項目進度。
第五點:當項目延後而增加人手，導致的結果卻是負面的。為了按期完成任務而增加新人，你需要從原來的項目組中調配人員來培訓新人，而且根據第二點，人員的增多，無形中也加大了任務開銷，最後導致項目難以控制。
A：“離系統上線只有3個月時間了，還有這麼多功能沒有做，怎麼辦？”
B：“可以從隔壁團隊抽調一個工程師來幫忙嗎？領導對這個項目很重視。”
A：“好，應該可以抽調兩個來，他們都是經驗豐富的程式員，爭取在1個月內完成。”
最後他們成功地把項目拖延了4個月，比沒有添加人手的預計還要晚。
——《人月神話》
