ch2
好菜都得多花些時間準備，為了能讓您享受到更美味、更可口的佳餚，請您務必耐心稍待。
——紐奧良，ANTOINE餐廳的點菜單
軟體專案進行不順利的原因或許很多，但絕大部分都是肇因於缺乏良好的時程規劃所致:
- 我們目前的時程預估技術還非常不成熟，糟的是，這些不成熟的技術背後都反映出一個假設，亦即，一切都會進行得很順利，但這實在是大錯特錯。
- 我們的預估技術誤把工作量和專案進度混為一談，這又隱含了另一個假設，以為人力和工時可以互換。
- 由於我們對自己所做的預估都無法篤定，所以專案經理通常缺乏Antoine餐廳廚師那種委婉的堅持。
- 時程進行缺乏監控，並把其他工程領域上被證明可行或慣用的技術套在軟體工程上進行改革。
- 當發現時程延誤的時候，自然而然的（也很典型的）反應就是增加人手，但這簡直就是火上加油，只會把情況弄得更糟。
第一個錯誤假設就是一切都會進行得很順利，亦即，每項工作都將只會耗費掉它「理應」耗費的時間。
就單獨一件工作而言，如果假設一切都將順利進行，其結果會對時程造成何種影響就要看運氣。從機率分佈的角度來看，「完全不延期」也是有一定的機會，所以， 或許它真的能如計畫所預期地進行，但是，如果面對的是大型軟體開發專案，包含的是一大群工作，而且彼此環環相扣，那麼，一切都將進行得很順利的機率將是微 乎其微。
人月的迷思 :
第二個錯誤的想法，是來自於預估和排定時程所使用的人月，這正是一般用來衡量工作量的單位。成本確實會隨著人力與工時的乘積而變， 但工作的進度可不是如此，所以用人月來衡量工作規模的大小是危險的，也是一個容易遭到誤解的迷思，使用人月的前題必須是在人力和工時可以互換 的情況之下。
只有當工作可被切分，而且投入工作的人彼此不用溝通，人力和工時的互換才算成立，像割小麥或採收棉花就是這樣，但這對程式設計來說卻完全不適用。
當一份工作因具有連續性的限制而不可切分時，就算投入再多的人力，也不會對時程有所影響，生小孩就是需要九個月，你叫多少個媽一起生都一樣，軟體工程就是像這樣的工作，因為它必須除錯，而除錯就具有連續性的本質。
系統測試 :
在時程中，組件除錯（component debugging）和系統測試（system test）是受連續性限制影響最徹底的部分，甚至，需要耗費的時間是基於所遭遇到的錯誤數目以及錯誤的棘手程度，理論上，這個數目應該是零，但因為樂觀， 使我們預期的錯誤數目往往會比真正遭遇到的少，因此測試總是大大地延誤時程。
我要特別指出，沒有分配足夠的時間給系統測試，就會釀成大災難，這是因為等到交貨在即，發現時間不夠用的時候，時間卻已經快用光了，而在這之前，都沒有人會意識到時程有什麼不對勁，結果，在噩耗、落後竟然都沒有任何預警的情況下，把你的顧客和老闆嚇一大跳。
要有勇氣堅持自己的預估 :
請注意，程式設計師的遭遇跟廚師一樣，顧客的催促也許會左右工作的預定完成時間，但對工作的實際完成時間不會有什麼影響。一客煎蛋卷，答應兩分鐘做 好，而且看起來應該可以順利上桌，但是如果到了兩分鐘還沒有做好，那麼這位顧客只有兩種選擇──繼續等，或者吃生的。你的軟體顧客也是只有這兩種選擇。
當然廚師還有另外一種選擇，他可以把火加大，那煎蛋卷就完蛋了──有一半燒焦，另一半還是生的。
我不認為軟體 專案經理在先天上就缺乏廚師的勇氣與堅持，或是在這點上比其他工程領域的管理者還差，但是在軟體界，以錯誤的時程去配合顧客期望的日期，這是比其他工程領 域還普遍的現象。對於缺乏數據、僅憑很少的資料、主要靠著專案經理的直覺所預估出來的時程，很難提出一個強而有力、能夠自圓其說，並足以擔保一切風險的辯 解。明顯地，這必須從兩方面來解決。我們先要蒐集並告知大家有關生產力的資料、錯誤發生率的資料、預估時程的法則等等，唯有藉著分享這些資料，整個軟體界才能夠獲利。
另一方面，在為預估方法找到一個更為堅實的基礎之前，專案經理個人必須挺起胸膛，勇敢為自己的估計堅持立場，保證就算是他的直覺再不濟，也比用願望來做預估要好。
雖然不夠嚴謹，看來也異於常理，我們還是在此提出Brooks定律：在一個時程已經落後的軟體專案中增加人手，只會讓它更加落後。（Adding manpower to a late software project makes it later.）
這 定律破除了人月神話。軟體專案會耗費多少時間是看它有多少連續性的限制，該投入多少人力是看它可以切分成多少獨立的子工作，根據這兩點，我們就可以推論出 用人較少、耗時較多的時程（唯一的風險就是軟體落伍的問題），然而，你是無法得到一個用人較多、耗時較少而又行得通的時程。軟體專案進行不順利的原因或許 很多，但絕大部分都是缺乏良好的時程規劃所致。
