[好書介紹]人月神話 The Mythical Man-Month

Posted by Mr.Sunday

我想任何對於軟體工程有興趣的人,或多或少應該都聽過或看過這一本書。如果都沒有的話,現在應該就趕快去找一本來讀一下。 這本書的作者是Frederick P.Brooks, Jr,目前還任教於北卡Chapel Hill分校,而且他是1999年Turing Award的得主,原因是「對計算機結構、作業系統和軟體工程做出了劃時代的貢獻」。

Brooks大師約在60年代擔任IBM的Architect (總工程師),開發OS/360。 想想那居然是四五十年前的時代,而這本書的初版日期,居然是1975年。 對於一個發展如此迅速的資訊領域,其實很難想像現在四五十年後的現在,還有多少地方可以從這本書學習或是借鏡? 但事實卻是,即然是現在的我多次閱讀,我還是每次都會有一些新的感受跟心得,也愈讀愈有意思,也不禁為作者在那麼久遠的年代,就有辦法思慮如此清楚,令人肅然起敬。

Mr.Sunday大學的時候發現許多資源最後都指向這本經典的時候,我十分好奇地找到了這本老舊的書,然後想辦法印了一份慢慢閱讀。 但是其實我很快就放棄了,因為這本書不同於一般的原文書或是教科書,裡面的英文用了大量的故事、引喻跟較艱澀的單字,縱然那時候也花了許多時候唸出了一些意思出來,但是常常還是會卡在語言層次上面。 十分幸運的台灣在2004年出現在中譯本,譯名「人月神話」而且是譯的20週年紀念版,還有許多新的章節作及對當年初版的一些比較。 我拿到了一本中譯本,陸陸續續也看了不少遍,雖然我不認識譯者,但是我真的要大力讚賞譯者翻譯的功力以及用心程度,讓人看中譯本看的很過癮而且舒服。 這本書的每一章節前面都會有一個富十分有意思的插圖跟一些諺語,但是如果只看英文或是只照翻,說實話也完全看不懂,但是譯者用心地自己加了清楚明白的譯著,減輕了許多負擔,也讀起來更有意思。

我想我花點幾次的篇幅,慢慢把一些有意思的章節內容摘要節錄出來,有些加上一些自己的心路歷程跟想法跟大家分享一下。但是還是鼓勵對軟體工程,或是在軟體產業的人可以想辦法獲得這本書來細讀,相信一定會有很多收穫的。這本書分成19章,其實章節之間不太有關聯,反而是像一篇篇鬆散的論文集,分別論述著作者的一些開發經驗與心得。

Part I 人月神話 (原文第二章)

這一章讓我覺得最意思的地方,就是Brooks利用圖表來詮譯為什麼評估軟體專案用「人月」 (Man-Month)的方式是一件謬誤不可行的事情。

軟體專案的預估衡量標準,其實我們常常用人月(Man-Month)的方法來評量,也就是一個工程師可以在一個月內做多少事。(即然至今,我還是有看到不少專案在用 @@) 因為人月是最容易直覺思考的標準,但是這個人月的迷思,卻是來自一個不易存在的假設「人力與工時是可以互換的」,也就是說,當工作是可以被切分的時候,而且彼此不必溝通的話,人力才可以跟工時互換,例如工廠的生產線、農田的收割、搬運貨物等,但是,程式設計卻完全無法適用這個假設。

下圖可以看的出,如果工作是可以完美切割,不需要溝通的話,人與月是可以互換取代的。 如一個工作需要10個人月,我可以找一個人做十個月完成,或是找10個人一個月完成,只要符合「人 * 月 = 工作規模 」

windowslivewriterd2330d80724b-3324mm112.jpg

Man & Month的關係圖 – 可完美切分的工作

但是有些工作是無法切割的,例如生小孩就是需要十個月,即使多找幾位媽媽來幫忙,十個月卻一點不得少,這樣本質的工作,就會如下圖一般,加了多少個人力也對工作進度沒有幫助。 而設計軟體本質的確有這樣的屬性,因為在寫程式以及除錯的過程中,是需要大量的理解現在軟體的狀況、設計細節方法等等,如果即然多幾個人,還是得花或許更多的時間讓新的人才能進入狀況,那不如讓原來已經進入狀況的人,專心除錯。

windowslivewriterd2330d80724b-3324mm211.jpg

Man & Month的關係圖 – 完美無法切分的工作

而事實上,除卻幾個不可切分的短期除錯之外,軟體專案是可以切分但不同的是,需要在不同切割的小工作間進行溝通。 所以下圖有點像可完美切分的情況,但是會因為切分工作的影響,造成人一多的時候,需要花的月份並不會愈來愈慢遞減,因為工作切的愈多,造成需要溝通的負擔愈大,所以也會比完美切分的曲線來的久一點

windowslivewriterd2330d80724b-3324mm311.jpg

Man & Month的關係圖 –

A:可完美切分 B:可切分但需要溝通

但若是除了溝通之外,工作跟工作之間也需要進行協調交流,產生更多的複雜度,其實愈多的切割,更會造成愈多的工作量。 就軟體設計的本性來看,或許程式的modules數字是變成一倍,但是有經驗的軟體工程師其實知道,複雜度覺得不僅僅只變一倍,當牽涉的函式庫與參與的人員變大的時候,複雜度可能不僅僅以倍數成長,而是以指數來成長。 所以如果是對於一個規模不小的軟體專案,可能有其適合的人數開發限制,即然為了加速開發,一直加入進入落後的專案,其實一點用也沒有,如以下圖。windowslivewriterd2330d80724b-3324mm411.jpg

Man & Month的關係圖 – 交互關係複雜的工作

(右端因為切割過多,交互複雜度負擔大於增加人力的好處,於是花的時間又上昇了)

所以為了專案落後新加入的人手,還必須得經過人員訓練,了解相關技術,軟體的原始設計,目標以及策略的時間,以及承擔切割更多的工作所造成的溝通與協調負荷,不見得是比較划算的。

所以本章作者提出了Brooks定律作為本篇的一個句點

「在一個時程落後的軟體專案增加人手,只會讓它更加落後….」

(Adding manpower to a late software project makes it later)

看完本章我覺得Brooks分析的清楚有條理。 就我的經驗的確軟體專案的落後,其實增加人手常常反而是最後也極可能是最沒有用的方法。 但是我覺得若能了解「人月神話」的迷思的狀況下,其實我們若能有系統地來增加一定數量內的人力,我想還是對專案是有幫助的。 首先是能了解專案落後的關鍵因素是否真為人力不夠? 其實常常落後的原因是在於前期的分析不周全或是設計錯誤、後期整合問題造成的。 所以當問題造成落後的時候,大家坐下來討論問題核心才是最關鍵所在。 而在分析核心之後,評估能以系統性的訓練新人員,或是獨立出不會造成更多負擔的工作來做,我想對時程還是會有幫忙。

我只節錄幾個關鍵點,有興趣可以試著找出全文來閱讀。 當然對於現在愈來愈多的書籍在教大家如何更實務地作專案評估,或是找到最好的實際方法 (Best Practices)。 但是就整個本質性的觀念與關鍵核心的呈現上,Brooks真的很能用簡單易懂,深入潛出的方法告訴我們整個難題與迷思的所在,而之後有機會我再介紹其它一些很有意思的章節,例如很有名的「沒有銀彈」 (No Siliver Bullet)。

喜歡這篇文章嗎? 分享出去給作者一點鼓勵吧!