2007年12月29日 星期六

人月神話

最近因為計畫結案,有一筆買書的錢可以用,在不用白不用
的心態下就往重慶南路跑了兩趟,買了一些有興趣,但是不
知道何時會看完的書,照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並沒有規劃好該何時採煞車,該換條路
走了,以致於浪費了很多寶貴的時間,事實告訴我們,先用目前的知識把東西
做出來,之後再慢慢修比較實際,簡單的來說就是先求有再求好,時程的掌握
比什麼都重要阿!


沒有留言: