軟體開發定律系列之布魯克斯定律有感

skydust1979發表於2020-11-06

布魯克斯定律:

人月=人*月,月≠人月/人

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

相關文章