人月神話

最近因為計畫結案，有一筆買書的錢可以用，在不用白不用
的心態下就往重慶南路跑了兩趟，買了一些有興趣，但是不
知道何時會看完的書，照pplong學長的說法就是「你對它的愛
不夠阿！」(指)，不管如何，在這些書當中，由於剛做完計畫的
關係，「人月神話」這本由Frederick P. Brooks, Jr所寫關於
軟體專案管理的書吸引了我的目光，作者以在IBM擔任 System/360、
OS/360軟體專案經理的經驗寫下這本探討軟體專案管理的書，
如果你跟我一樣，覺得以後在就業時非常有機會靠寫程式混口飯吃，
或許你會對這本「人月神話」有興趣。




人月(man-month or person month)指的是「一個人要花幾個月」
才能完成軟體開發的單位，通常用來評估一件軟體專案的大小，
也是目前許多外包軟體的計價方式，包括軟體協會所提的軟體計價
方式在內，都是用「人月」計算的。不過這種計算方式太過粗略，
事實上，就我的經驗和書上所提的，並不是愈多人投入東西會愈快
做出來，一來要看任務能不能切割成各自獨立的模組，二來人愈多
溝通的成本會更多，同時還要再看你跟什麼人溝通，如果他無法理解
你的想法，很多時候再花更多時間跟他解釋只是徒勞而已....

書上每一章節都是由短文所構成，作者的文筆很不錯，大部分的時候，
能夠用簡單的文句解釋複雜的東西，基本上這本書並不談怎麼寫又快又好
的程式，大部分都在討論一些管理上的議題以及人性，每章的開頭都附有
一句寓意深遠的古老格言，以下就摘錄一些我覺得不錯的以及作者的主張：

• 對航海的人來說，擱淺的船就是燈塔。
• 研究顯示，高手與庸手的表現有極大的差異，而且往往是一個數量級的差異。
• 練習就是最好的教練。
• 沒有人會給報壞消息的人好臉色看。
• 實務上看起來更糟的是：你得先把工作做成功，才會得到愈多實質上的權力。
• 由別人來設定目標，必須依賴無法由自己支配的事物(特別是別人的程式)來做事:權力與責任並不相稱
• 軟體專案進行不順利的原因或許很多，但絕大部分都是肇因於缺乏良好的時程規劃所致。
• 關於時程預估，我的經驗法則是1/3規劃、1/6寫程式、1/4組件測試、1/4系統測試

就我來說最有感觸的大概就是時程規劃這個部分，大四的專題跟這次的計畫，
到了最後都是急就章用暴力法把他完成，之前花了太多的時間在survey一些
架構上的問題，有些問題其實到後來根本就無關痛癢，換句話說就是這些survey，
除了讓我看了很多spec之外好像並沒有實質上的幫助，舉例來說，要怎麼用
ESB(Enterprise Service Bus)的Mediation Module？該繼續用NIST還是CISCO
的SIP proxy？很多時候我做這些survey並沒有規劃好該何時採煞車，該換條路
走了，以致於浪費了很多寶貴的時間，事實告訴我們，先用目前的知識把東西
做出來，之後再慢慢修比較實際，簡單的來說就是先求有再求好，時程的掌握
比什麼都重要阿！