布魯克斯定律：
     人月=人*月，月≠人月/人
     極端情況下，Brooks定律會出現這樣的情況：“投入更多的人到一項延遲的工作上，可以導致該項工作更加延遲”。
Barry Bohem：可以將軟體開發進度壓縮25%，但是不能再多了
200/20/6X現象：
–人數增加1倍，工期縮短20%，缺陷增加6倍
 
反思：
–1 在實踐中，我們是否經常通過給專案組增加人手的方式加快進度？
–2 有哪些合理的加快進度的措施？
 
 
定律分析
 
    布魯克斯定律（Brooks’Law）裡面用了幾個字眼“人、月”。是的，此布魯克斯就是彼布魯克斯，《人月神話》的作者。
 
    投入更多的人到一項延遲的工作上，可以導致該項工作更加延遲！這句話一筆點破IT行業的專案延期情況，以及專案經理為之頭疼的專案計劃進度。希望更多的老闆能知道此類的道理。
    但是為什麼這句話專案經理會有不同的意見？
    這就是投入的是新人還是老人的問題。如果一個團隊10個人，在某一個階段10個人分組，擴建為兩個團隊分別做不同的模組，那麼，在某優先順序高的專案中，一個組5個人搞不定，臨時從另外一個組湊掉2個人來做事。
 
    因為實際上是老員工做老的模組，所以會給人一種增加人手就能快速推進工作的印象。
    但是增加新員工，實際上對軟體開發來說，是非常失敗的東西，新人進團隊，常見的問題如下：
1、新人需要上手學習
2、一開始的時候，需要老手去指導他，這個階段，老手的工作效率實際上是降低的
3、如果沒有程式碼規範，你要重新交給他，在此之前，他的工作輸出是負面的。
4、各個模組的設計思路，空手借過來的程式碼，需要重讀、在別人的思路上繼續工作，甚至重構。
5、組內溝通成本會呈幾何級數增大：四個人可能只需要開碰頭會，十個人就要正兒八經的填寫日報、週報——因為一個ltm的精力有限，跟控不過來。
6、專案經理分心在管理事務上：人數多了，可是現在可以讓他們做的工作一下子沒有這麼多，專案經理得要想辦法安排工作給這些人都有事做。以免出現部分人閒置部分人牢騷的現象。這樣子反倒會讓專案經理沒有心思在真正該做的事情上。
7、如果有人沒事做，就會很害怕自己被裁員，就會做一些看起來像是工作的事情。戒是做一些抵銷工作進度的事情。
    以上很多觀點總結自《人月神話》：『Adding manpower to a late software Project makes it later.』引自The Mythical Man-Month.Chapter2 page25)
 
    所以，增加新人的做法是失敗的。增加原團隊中的人，是比較流行的方法，同時，也給人很多錯覺：增加人手，是可以縮短專案週期的！
 
200/20/6X現象：
–人數增加1倍，工期縮短20%，缺陷增加6倍
反思：
–1 在實踐中，我們是否經常通過給專案組增加人手的方式加快進度？
–2 有哪些合理的加快進度的措施？
 
 問題解答：
 
     如果用一個例子來解釋這種增加人手的方法。個人傾向於用籃球比賽。比如幾年前的丹佛掘金，招來了AI，但是兩個得分王並沒有 把掘金的戰績提升上去。一個新人和已有團隊的磨合，存在很大的風險點。
    在實踐中，增加老人和增加新人的區別在上文已經論述過，在此不再贅述。針對常規的情況，我們可以把四個維度的事情作為一個四個座標點：時間（快）、成本（省）、目標（多）、質量（好）。
 
    如何合理的加快專案進度？
    在通常的情況下，專案出現延期，或者要提前完成。在投入更多人力無效的情況下。還有哪兩種選擇？
1、放棄質量，帶著很多問題釋出版本。
2、減小目標，調整需求範圍，規劃跟多的迭代版本，分期實現功能。
    正常的選擇就是“砍需求”，調整需求範圍，能在短期內提供版本，供客戶使用。
    當面對deadline時，怎麼操作專案，能一目瞭然的看出團隊的成熟度，當然，更重要的是看出老闆對軟體行業的理解度。
    關於專案進度：可以理解完成90%就等同於完成50%。即：90%的工作等於一半。