布魯克斯定律：

人月=人*月，月≠人月/人

極端情況下，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%的工作等于一半。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的软件开发定律系列之布鲁克斯定律有感的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。