譯至：
雖然摩爾法則比較有名（18個月半導體的效能翻番），但與之相比布魯克斯法則大家對之知之甚少。
布魯克斯是上世紀60年代ibm
system/360的作業系統os/360的開發負責人，這之後基於當時的經驗寫了人月神話
這是描述大規模軟體開發難度的一本劃時代的書。是it從業人員必讀的一本書。如果你是軟體開發人員或是專案管理者的話，姑且聽我的，讀一讀這本書比較好。我的日記裡也介紹了好幾次。
先不談人月神話的第二章，看下面的示例。有這樣乙個專案需要12個人月，那麼3個人4個月就能完成該任務。然後，在每個月設定觀測點a/b/c/d。
但是乙個月就需要結束的a結果花了兩個月完成。這相比於預估時已經是兩個月之後了。怎麼辦？管理者有下面的對策。
雖然當初的估算是對的，僅僅是最初的工程弄錯了。也就是說推斷剩下9人月。因為有9人月的工作，兩個月完成的話需要9/2=4.5人。追加兩個人到這3人團隊中。
當初的估算弄錯了，不是12人月而是需要24人月。因為已經花了６人月的時間了剩下需要１８人月。２個月完成的話，需要18/2=9人。追加６人到當初的３人團隊。
重新安排任務。追加充足的時間到新的計畫了。
調整工作目標。減少工作。
那麼，應該採用什麼方法呢。最開始的二個方法，不修改工作目標和工作進度表的話最初４個月完成目標的期望就破滅了。
假如追加２個人，這兩人的培訓成本，３人完成的工作用５個來做，就需要重新安排工作，這些成本沒有被追加到估算中，結果的話最終期限無法完成。追加６個人的情況，這種成本加的更多。
這就是布魯克斯法則。「追加人員到
延遲的專案更會影響專案的進度」
如布魯克斯所寫的那樣，無法按進度完成工作的話，只能降低工作目標作業。
這是軟體產品開發中５０年前發現的法則現在也是正確的。但是，幾乎所有的開發者都不了解布魯克斯法則，就算知道也不會去實踐。
給延遲的專案加了就像是火上澆油。不理解這個法則的各位要好好的讀一下人月神話。不管如何聽我一句好好讀讀。作為專案管理在做決定前的共識，大家都要好好讀讀。推薦在此之上根據每個專案的特殊性來調整作業。
你的上司讀過人月神話嗎？試著問一下看看。
布魯克斯法則解釋及論證
布魯克斯法則 brook s law 簡單理解就是 向進度落後的it專案增加人手，只會使專案更加落後。具體解釋及論證如下 1 解釋 布魯克斯法則 brook s law 由被認為是 ibm 360系統之父 的frederick p.brooks，jr提出，也叫brooks法則是指一種實踐，應用全面 ...
專案管理 掙得值分析法
掙值法又稱為贏得值法或偏差分析法.掙得值分析法是在工程專案實施中使用較多的一種方法，是對專案進度和費用進行綜合控制的一種有效方法。1967年美國國防部 d0d 開發了掙值法並成功地將其應用於國防工程中。並逐步獲得廣泛應用。掙值法的核心是將專案在任一時間的計畫指標，完成狀況和資源耗費綜合度量。將進度轉...
軟體專案管理 掙值分析法
掙值分析法是對專案實施的進度 成本狀態進行效績評估的有效方法，是計算實際花在乙個專案上的工作量。bcws 到目前為止的總預算成本。它表示 到目前為止原來計畫成本是多少？或者 到該日期為止應該完成的工作是多少？acwp 到目前為止所完成工作的實際成本。它表示 到日期為止所完成工作的實際成本。說明了 到...