[好書介紹]人月神話 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)。

喜歡這篇文章嗎? 分享出去給作者一點鼓勵吧!
  • http://insectlin.wordpress.com 昆蟲

    FYI:

    The book emphasizes the idea of “no silver bullet” (no simple/straightforward solution) again and again.

    Fred also said that the best software engineering model is the “surgeon model”. However, people’s egos make it very difficult to implement.

    BTW, Fred is the legendary IBM 360/370 creator. Before his work, programs have to be rewritten for every new hardware. (You can imagine how old he is, right?)

    And, he built the first (or, one of the first) computer science department in USA from scratch.

    Fred also said that “computer science” is not science. He regretted that he used that name.

  • http://insectlin.wordpress.com 昆蟲

    FYI:

    The book emphasizes the idea of “no silver bullet” (no simple/straightforward solution) again and again.

    Fred also said that the best software engineering model is the “surgeon model”. However, people’s egos make it very difficult to implement.

    BTW, Fred is the legendary IBM 360/370 creator. Before his work, programs have to be rewritten for every new hardware. (You can imagine how old he is, right?)

    And, he built the first (or, one of the first) computer science department in USA from scratch.

    Fred also said that “computer science” is not science. He regretted that he used that name.

  • Kevin

    現實生活應該很多ㄑ字型的工作效率吧?人少的時候花很多月,人多的時候就手忙腳亂幫倒忙,人數剛好才是最高效率。

    最後是不是Typo? “No silver bullet” 還是 “So silver bullet”?

  • Kevin

    現實生活應該很多ㄑ字型的工作效率吧?人少的時候花很多月,人多的時候就手忙腳亂幫倒忙,人數剛好才是最高效率。

    最後是不是Typo? “No silver bullet” 還是 “So silver bullet”?

  • xoidiot

    ^_^
    2004年的時候我就拖了幾個朋友一起買來看… 對於當時還在軟體業的我, 感觸很深. 但是現在已經是2007年了, 我也已經離開了前一家公司…

    老實說, 這個東西對於有點急功近利的主管來講, 是一點用都沒有的. 對他們來講, 人月可以隨便的加減乘除(打折來算喔), 帳面上永遠都只有開發程式的時程, 上班永遠都是打卡制, 下班永遠都是責任制….

    但是我還是相信, 總會有個地方有個公司有個主管, 會相信這本書的.

  • xoidiot

    ^_^
    2004年的時候我就拖了幾個朋友一起買來看… 對於當時還在軟體業的我, 感觸很深. 但是現在已經是2007年了, 我也已經離開了前一家公司…

    老實說, 這個東西對於有點急功近利的主管來講, 是一點用都沒有的. 對他們來講, 人月可以隨便的加減乘除(打折來算喔), 帳面上永遠都只有開發程式的時程, 上班永遠都是打卡制, 下班永遠都是責任制….

    但是我還是相信, 總會有個地方有個公司有個主管, 會相信這本書的.

  • Maoke Jackson

    圖表上的人月標示是否對調了?
    我解讀起來總覺得不順利。

  • Maoke Jackson

    圖表上的人月標示是否對調了?
    我解讀起來總覺得不順利。

  • http://mmdays.wordpress.com/ Mr. Sunday

    Dear 昆蟲
    Thanks for your precious information.

    Dear Kevin
    Thanks for your correction. That should be “No Silver Bullet”

    Dear xoidiot
    Thanks for your feedbacks

    Dear Maoke Jackson
    Sorry for the wrong figures. I have fixed it. ^^

    Mr.Sunday

  • http://mmdays.wordpress.com/ Mr. Sunday

    Dear 昆蟲
    Thanks for your precious information.

    Dear Kevin
    Thanks for your correction. That should be “No Silver Bullet”

    Dear xoidiot
    Thanks for your feedbacks

    Dear Maoke Jackson
    Sorry for the wrong figures. I have fixed it. ^^

    Mr.Sunday

  • iguest

    這個部分很普通,這問題本應是很顯而易見的,卻為難作者花了不少篇幅告訴讀者人力與時間無法對等互換。知道了,一看即明;不知道,便要花費極大的力氣說明,別人還不一定懂,這就是人月無法對等互換的原因之一了。

  • Pingback: 人月神話 The Mythical Man-Month at enchao.com()

  • iguest

    這個部分很普通,這問題本應是很顯而易見的,卻為難作者花了不少篇幅告訴讀者人力與時間無法對等互換。知道了,一看即明;不知道,便要花費極大的力氣說明,別人還不一定懂,這就是人月無法對等互換的原因之一了。

  • Michael

    我不能同意xoidiot更多了啊~~
    尤其是狂趕release跟patch的時候,
    什麼人月? 那可以吃嗎?
    即便有主管讀過, 也只是當小說啊…

  • Michael

    我不能同意xoidiot更多了啊~~
    尤其是狂趕release跟patch的時候,
    什麼人月? 那可以吃嗎?
    即便有主管讀過, 也只是當小說啊…