The Introduction of The Mythical Man-Month

這是人月神話：軟體專案管理之道（20週年紀念版）的第二章：人月神話，與書名同名，這一章講的是軟體的專案管理，ㄚ琪在專案管理的研究上，主要是師承工業工程系所所教導的要徑法(CPM)與計劃評核術(PERT) ，當然甘特圖也是常用工具，而且曾有一度幻想，會了這套技術可能連蓋房子也沒問題吧！哈哈…今天看了這一章之後，你會發覺用這套技術在軟體的專案管理上可能會有點行不通。

這一章的導引就是『好菜都得多花些時間準備，為了能讓您享受到更美味，更可口的佳餚，請您務必耐心稍待。』–紐澳良．ANTOINE餐廳的點菜單

嗯，好菜總是要等，可能也是要花時間去找，在東京為了找給新手的: 到東京必吃 絕不能錯過的十大美食(2010.8.27更新)的新宿西口/讃岐烏龍大使 東京麵通團，整個晚上都在找，因為我們迷路了，到最後找不到那一家店，還嘔氣不吃晚餐回飯店了！

所以真的有些事情就是要等，可是經理人一看見你估了一個軟體完成的時間，不管他們懂不懂軟體，總是會給你來個質疑，時間是不是太長了，如果你軟弱了，變更了時間，好戲就會上場，我稍微列一下這一章的重點讓你看看吧！

『第一，我們目前的時程預估技術還非常不成熟』，而且糟糕的是我們都很樂觀的預估我們都會很順利，這一點我是很有感觸的，所以經過一些年來，也練了一些預估的能力，不過我還是傾向保守的預估。

『第二，我們的預估技術誤把工作量和專案進度混為一談』，這就好像說一間房子1個人蓋要10天，2個人蓋不就只要5天就好，國小的數學你還在用嗎？千萬不要那麼地隨便用，怎麼死的都不知道，不過我發覺有些人在預估時間是用程式碼的長度來預估說，嘿嘿，好詭異喔，最近一個專案我竟然用這個方法來預估，打我吧！

『第三，由於我們對自己所做的預估都無法篤定，所以專案經理通常缺乏Antoine餐廳廚師那種委婉的堅持。』這就是我所說的堅持，因為自己虛了，所以才會弱不是嗎？從今天起，大家要理直氣壯一點才行得通！

『第四，時程進行缺乏監控，並把其他工程領域上被證明可行或慣用的技術套在軟體工程上進行改革。』嗯，我就是把蓋房子的技術用在軟體專案管理上的，很遜吧！

『第五，當發現時程延誤的時候，自然而然的反應就是增加人手』，因為小學數學有教ㄇㄟ，當然最好用業最直覺了，結果就是死得很慘的下場。

第一個來自過份樂觀的錯誤假設就是，『每項工作都將只會耗費掉它「理應」耗費的時間』，不過ㄚ琪早期真的會因為心虛把這段時間少掉，為的就是可以取悅客戶，唉，真是不智。『有一本很棒的書叫《The Mind of the Maker》，是Dorothy Sayers所寫的，她在書中將創作的過程分為三個階段：構想(idea)、實作(implementation)、互動(interaction)。』這本書現在缺中文翻譯，有意願的人可以上網去提交。

第二個錯誤的想法，『就是來自於預估和排定時程所使用的人月(man-month)，這正是一般用來衡量工作量的單位。』…『所以用人月來衡量工作歸模的大小是危險的，也是一個容易遭到誤解的迷思(myth)。』…『只有當工作可被切分(partition)，而且投入工作的人彼此不用溝通(communication)，人力和工時的互換才算成立』，所以軟體的專案管理覺可能靠增加人手來縮短時程的。

在軟體專案管理中，『組件除錯(component debugging)和系統測試(system test)是受連續性限制影響最徹底的部份』，但是我猜大部分的程式設計師包括我自己在內，可能都無法接受自己會產生錯誤的程式碼，因此就會分配這裡的時間較少，但是作者他在安排軟體專案管理時程，他的安排是這樣的：

『1/3 規劃

1/6 寫程式

1/4 組件測試和早期系統測試

1/4 系統測試，完成所有的組件』

我想以後我可以蕭規曹隨了。

雖然我知道我們很菜，但是在預估時程的能力還未精進之前，還是只有堅持自己的估計是正確的，因為就自己的能力做估計，是最正確的，縱使我們的軟體顧客沒有耐心，我想他們如果不接受的話，我猜也只能到別家去吃了！

惡性循環的時程災難，有一種俗話就是牛牽到北京還是牛，因為如果有這種錯誤的觀念的時候，常人就會為時程的延誤加派人手，這樣惡性循環就開始了，最後使用Brooks定律：『在一個時程已經落後的軟體專案中增加人手，只會讓它更加落後。』

『軟體專案進行不順利的原因或許很多，但絕大部分都是缺乏良好的時程規劃所致。』

感謝你看到這裡，很快就可以離開了，但最好的獎勵行動就是按一下幫我分享或留言，感恩喔～