hi，我(wo)是熵(shang)減，見字如面。

在軟件項目(mu)開(kai)發中，你是否遇到過這種(zhong)情況：

你的項目進度落后了，你的老板或客戶不滿意，你的團隊壓力很大，你覺得需要增加一些人手來加快速度。但是，當你增加了新的成員后，你發現項目的進度并沒有提高，反而變得更慢了，而且出現了更多的問題和沖突。

這就是(shi)布魯(lu)克定(ding)律（Brook’s Law）的一(yi)個典型例子。

什么是布魯克定律（Brook’s Law）？

布魯(lu)克(ke)(ke)定律（Brook’s Law）是(shi)一種關于軟件項目管理的(de)觀察，由弗雷德里克(ke)(ke)·布魯(lu)克(ke)(ke)斯（Frederick Brooks）在他的(de)1975年出版的(de)著作(zuo)《人月神(shen)話(hua)》（The Mythical Man-Month）中提出。

該定律指出：在一個已經延期的軟件項目中，增加人力反而會使項目更加延期，而不是加快進度。

背后的原因

這個(ge)定律粗看起來(lai)，是有些反直覺，因為(wei)(wei)我們通常認為(wei)(wei)人多(duo)力量大。那么(me)，為(wei)(wei)什么(me)在一個(ge)軟件項目中增加人手會讓事(shi)情變(bian)得更糟呢？

這個定(ding)律之所(suo)以(yi)在大部分情(qing)況下(xia)是(shi)有(you)效(xiao)的，是(shi)因為(wei)有(you)以(yi)下(xia)3個原(yuan)因：

• 新加入的人員需要一定的時間才能熟悉項目的背景、目標、架構和代碼，這個過程會消耗已有人員的時間和精力，降低他們的生產力。
• 新加入的人員可能會引入新的錯誤或與已有人員產生沖突，導致項目質量下降或工作效率降低。
• 隨著人員的增加，項目的溝通成本也會增加，因為每個人都需要與其他人保持同步和協調，這會增加項目的復雜度和風險。

當然，布魯(lu)克定律(lv)并不是(shi)一個(ge)絕(jue)對的(de)規律(lv)，而是(shi)一個(ge)經驗(yan)性的(de)原則，它反映了(le)軟件開發中存在的(de)一些(xie)固有的(de)限(xian)制和(he)挑戰。

例外和啟發

布魯克定(ding)律(lv)不僅適用(yong)于軟件項目，也適用(yong)于其他需要(yao)創造性和協作性的項目。它告訴我們，在一個復(fu)雜的項目中(zhong)，簡單地增加人手并不能(neng)(neng)解決問題(ti)，反而可(ke)能(neng)(neng)帶來(lai)更多(duo)的問題(ti)。

那么，我(wo)們應該如何避免或(huo)緩解布(bu)魯克定律呢？這里有一些可能的建議：

• 在項目早期就增加合適的人力，避免在項目后期才臨時招募新人。
• 制定合理和可靠的項目計劃，避免過于樂觀或悲觀的預估。
• 根據項目的可分解性和可并行性，合理地分配任務和資源，避免出現瓶頸或冗余。
• 建立有效的溝通機制和協作工具，減少信息的傳遞和處理時間。
• 優先保證項目的質量和穩定性，適當地調整項目的范圍和目標，分階段地交付項目成果。

最后

布魯(lu)克定律提(ti)醒我們，在軟件開(kai)發中，人并不是一(yi)個簡單的(de)可替代資源，而是一(yi)個復雜的(de)系(xi)統組成部分。

我(wo)們需要(yao)根據項(xiang)目(mu)(mu)的(de)(de)實際情況和需求，要(yao)能夠靈活地管理(li)和利用好人力資本，以(yi)實現項(xiang)目(mu)(mu)成功(gong)的(de)(de)最(zui)終目(mu)(mu)標。

在創造性和協作性的工程之中，我們始終要：以人為本，未雨綢繆。

閱讀(du)，思(si)考，練(lian)習，分享，日日不斷之(zhi)功。

嗯，寫完了。

新(xin)的(de)一天，加油哦 (? ??_??)?