導言

軟體撰寫裡，最難預測的莫過於完成的時間。
本書作者分享多年大型專案管理的經驗成著此書，是身為 IT 工程師必讀的經典之一。

架構

雖然本書章節頗多，但都為繞著一件事情，就是軟體專案管理，雖然有些程式技術的經驗有些過時，但仍不失為軟體專案管理的經典。

摘要

惡性循環的時程災難

當軟體專案延誤時,我們能做些什麼處置呢?通常是增加人力,但從 圖2.1到圖2.4看來,這麼做可能有效,也可能沒效。
我們用一個範例來說明。假設有一份工作估計需要12個人月,並且指派三個人工作四個月,時程上有A、B、C、D四個里
程碑,分別是在每個月的月底(圖2.5)。
現在假設第一個里程碑實際上花了兩個月才達到(圖2.6),身為專案經理,接下來的做法有哪些選擇呢?

1.假設工作必須準時完成,又假設只有第一個月的時程是估計錯誤的,如圖2.6所示,剩下9個月的工作量,時間剩下兩個月, 所以需要'/2個人來把工作做完,結論是加2個人。
2.假設工作必須準時完成,又假設是平均低估了所有的時程,如圖2.7 所示,剩下18個月的工作量,時間剩下兩個月,所以需要 9 個人來把工作做完,結論是加6個人。
3.重新安排時程。我推崇 P. Fagg所提出來的忠告,他是個很有經驗的硬體工程師,他說:「一丁點延誤的機會都不要有。」亦 即,在新時程中安排能夠保證工作可以很仔細,很徹底地完成的 足夠時間,使後頭的工作不會再發生需要重新安排時程的事情。 4. 刪減工作。實務上這經常發生,一旦察覺時程趕不及,而且延遲 將造成昂貴的衍生成本時,這是僅有的可行方案。專案經理唯一 的選擇就是規規矩矩、謹慎地重新安排時程,否則,你會看到工作還是會在暗中被匆促的設計與不完整的測試給悄悄刪減掉。

就前兩項方案而言,都是堅持不在時間上讓步,就是一定要在四個月內完成,而這是個非常糟糕的決定。例如,考慮一下第一個方案的後續影響(圖2.8),新加入的兩個人,不論如何能幹,不論多快進 入狀況,都需要一個老手抽身來負責訓練他們,如果這得花上一個 月,那麼這3個人的訓練工作量並不在原先的估計之內, 更糟的是,這工作原本是切分成三人份的,現在要用五人份的方式重新切 分,這意味著之前某些工作又得重做,而且系統測試的時間勢必延 長,於是,到了第三個月的月底,基本上還會剩下7個月以上的工作量,人力方面倒是有5個訓練有素的人可用,但時間只剩下一個月。如圖2.8所示,結果還是無法如期完成,而且延遲的程度跟不加 人的做法(圖2.6)是一樣的。

如果要在四個月內完成,並且將訓練的時間納入考量,但不考慮 工作重新切分和額外系統測試的時間,那麼在第二個月的月底時,應該要加4個人,而非2個人。如果工作重新切分和額外系統測試的 時間都一併納入考量,那麼就得加更多的人才行,這會演變成一個編 制至少是7個人的小組,而非原先的3個人,整個組織與工作配置已算是大幅改變,不是小幅的調整而已。

注意,到了第三個月的月底時,情況看起來會很悲慘,第三個月 該完成的里程碑並沒有按預期達成,表示之前在管理上的努力看不到效果,於是又會很想加新的人進來,重蹈覆轍,不斷地抓狂。

以上所述,只是假設第一個里程碑的時程是錯估的,這還是比較樂觀的想法。如果考慮圖2.7,保守地假設所有的時程都是錯估的, 於是加6個人,考量訓練、工作重新切分、額外系統測試的時間,這 些計算就留給讀者們當作練習了。無疑地,災難會不斷上演,並導致 做出來的是個爛東西,最後,到頭來還是會重新安排時程,就是照原來的方式叫那三個原班人馬去做,可千萬別再提加人的餿主意了。

雖然不夠嚴謹,看來也異於常理,我們還是在此提出 Brooks 定律:
在一個時程已經落後的軟體專案中增加人手,只會讓它更加落 後。(Adding manpower to a late software project makes it later.)

這定律破除了人月神話。軟體專案會耗費多少時間是看它有多少連續性的限制,該投入多少人力是看它可以切分成多少獨立的子工 作,根據這兩點,我們就可以推論出用人較少,耗時較多的時程(唯一的風險就是軟體落伍的問題),然而,你是無法得到一個用人較 多、耗時較少而又行得通的時程。軟體專案進行不順利的原因或許很多,但絕大部分都是缺乏良好的時程規劃所致。

心得

本書所提及，軟體撰寫最難預測的，就是沒有碰過的部份，而現下流行的 microservice & FP ，就是籍由功能的拆分，讓各個系統做到低耦合，而這其中一個好處，就是恰巧的將不可預測的因素降到最少。
一個好的架構師，將各個功能拆分清楚，就算遇到卡關的情況，也只會侷限某個 feature 的開發上，不會大幅度的去影響整個系統的開發進度，甚至在 milestone 接近也可以先對卡關的 feature 先進行捨棄，還是可以先讓整個系統上線。
這個操作，也是人月神話問世時所難以預測的。哈。