《人月神話》20周年紀念版評論集

領測軟件測試網 原文：http://www.dearbook.com.cn/Guide/ViewGuide.aspx?GuideID=301

陳懋戍 編譯 


Brian Kernighan
      我唯一一本讀過一遍以上的書，是Fred Brooks的《人月神話》，實際上我每過一兩年都重讀一遍。部分原因是這本書文筆很好，部分原因是書中的忠告很有價值，即使是25年以后。當然，現在很多細節上的地方，和我們做事情的方法，都有不同。我們的工作更自動化，計算機的“馬力”更強勁，但書中依然有許多好的忠告，我非常推崇這本書。這是我唯一能想起來的你能從中體會到樂趣和思想的計算機科學書籍。 

Ed Yourdon
      有些書對于讀者和作者象是年金，它們年復一年的分紅�！度嗽律裨挕肪褪沁@么一本書。我直到在1994年接到Brooks教授的電話，才真正完全賞識它。

      原因來自他的電話，電話中他說，他的出版商請他修訂他在1975年第一次出版的這本書。我立刻表示了我的一點妒忌、羨慕；因為我的出版商從未叫我修訂一本出版接近20周年的書。確實，我甚至表示了這樣的意見： 當代的軟件工程師不會考慮閱讀這本如此古老的書，因此，可能無法賣出一本�！芭�，不”，Brooks教授回答道，“《人月神話》到目前為止，每年穩定的賣出10000本�！�

      嫉妒、羨慕和突然的現實：什么是我們擁有的象年金一樣的東西。我高興地說，自此書出版至今，我已讀過1975版至少四遍；在接到Brooks電話后，我再次將它從書架上拿下來，重讀了一遍。但這次，是有特殊目的的：實際的原因來自于他的電話，Brooks教授告訴我，目的是發現自這本書1975年出版以來，計算機領域是否有有意義的事件發生。

      我必須申明，這樣的問題是相當難以回答的。Brooks繼續告訴我，他現在已基本離開軟件工程社團，將他的大部分專業精力投身于虛擬現實領域的研究。所以，在準備再版這本書時，他想知道：什么已經改變了，什么還沒有？他的原書中哪些是正確的，哪些是錯誤的，哪些是不切題的。

      當然，我不是向他提供同樣信息的唯一的人；我的一些同僚、大量的業界領袖、作者、顧問和搖旗吶喊者都被邀請回答這個問題…。我們所有人很高興地做了。并且，象你所期望的一樣，我們的輸入被Brooks教授處理、分析、過濾、綜合進那個非凡的新版本??它是真正的國際財富。

      原書的內容仍在那兒，現在新增了四章。它們是Brooks教授對他的思想的反思和對我們的反饋的反應。新增的第一章由恰到好處地濃縮的原書主題組成；包括可以被稱為書的中心論點的東西：大型編程項目忍受管理問題，這些問題因為勞力的分配而與小項目有本質上的差別；軟件產品的概念完整性是如此關鍵；概念完整性是困難的但可達到的。第二章小結了二十年后Brooks對這些主題的觀點。第三章是他1986年首發于IEEE Software的經典報告：《沒有銀彈》的重印。最后一章是對Brooks1986年的斷言 “在未來十年，依然沒有銀彈”的思考。

      年輕的軟件工程師、吝嗇的研究生、懶惰的軟件老手常請我標示出當前為止最好的軟件圖書�！叭绻�我帶著僅有的一本計算機書在沙漠荒島上，”他們問，“應該是哪本書？”這是個荒謬的問題，但人們堅持要個答案。假如你真的被放逐到這樣的小島（或者你決定躲藏到這樣的地方去避免2000年軟件崩潰的恐懼�。�，《人月神話》應該緊隨著你。


Jason Bennett
背景
      在我提交我的關于《人月神話》的書評前，我意識到沒有介紹此書的第一版是我的疏忽。那是1975年。程序員辛苦的在最早的啞終端上工作，這些終端連著來自IBM的笨重主機。也許，如果足夠幸運，程序員可以工作在一臺小型計算機，它來自于業界的新星公司DEC，和它們的PDP系列計算機上。FORTRAN和COBOL是主要語言，夾帶著一些PL/1。C是地平線上的亮點，剛剛開始離開Bell實驗室走它自己的路。在整個工業范圍中，匯編語言仍在廣泛的應用。進入Frederick Brooks的書，工業界的原作之一。Brooks在反思他在IBM的時間，特別是他在1960年代中期工作于System/360和它的操作系統，OS/360（獨特的名字，不是嗎？）的一段。Brooks試圖指出哪些做對了，哪些沒有，特別是如何構造和管理全部程序。他因此開始書寫軟件項目管理的第一個條約，一個軟件工程不可缺少的部分。二十五年后，我們仍然讀這本書，學習它。在業界，大部分書六個月后就無用了，這本書則是空前的。記住，雖然，最終會有書能達到它的水平。


哪些是好的？
      你可能很想知道，為什么這本書能持續如此長的時間。答案是簡單的：書中的技術對大眾的教訓來說是次要的。簡單說，Brooks指出下列幾點：

1． 編程必須進入到軟件工程，以便持續改進技藝的狀態；

2． 任何好的工程產品，必須是概念和體系結構的完整結合；

3． 軟件開發中的焦油坑（the tar pit）可以通過盡責、專業的過程得以避免；

書中有如此之多的經典語錄，以致這篇簡單的書評不能全部包括。當然，最著名的是Brooks定律：加人將延遲工程（隱義：這樣做沒有幫助）。在MMM（《人月神話》）中外科開發團隊、第二系統效應、文檔的重要性等均被覆蓋，有些還是第一次出現。通過這本書，Brooks覆蓋了所有因素，這些因素是成功完成一個主要軟件項目必須做的；同時，在書的各部分中，他給出了一致的軟件工程與項目管理的堅實的基礎。事實上，這是第一本主要的正確匯集工程師需要的關于大型軟件項目開發知識的書，書中相關知識來自于對已完成項目的看法。除了原書，Brooks 1986年的隨筆《沒有銀彈》也被包括進去，同時帶著Brooks在這本書出版二十五年后的思想。這些隨筆每篇都值得一讀，因為它們給出了當前工業所處位置的精確評價�？梢赃@么說，容易的部分已在我們身后，讓我們從這兒開始實際的工作。

哪些是有害的？
      關于這本書哪些是有害的，答案是：人們沒有讀它。沒有特別的好理由，他們僅僅是太忙于讀最新的關于今天時尚的書了。當然，具有諷刺意味的是，今天的時尚可能是明年的笑話，而MMM（《人月神話》）將從現在開始下一個十年。如果，學校發給你這本書，再次讀它（你可能不是第一次:-））。如果你從沒聽說過它，明天開始讀。

書中哪些是對我們的有用的？
      為什么我們每一人都應該讀這本書？對于一串半組織化的小組哪些項目管理是要緊的？在我們為世界大同努力奮斗時，我們是否做的不好？嘿，是或不是。

      首先，我們沒有商業軟件的壓力。如果Apache明天發布而不是今天，沒問題。每個人可能是壞的，所以我們不會做的更糟。因為如此，大部分開放源碼項目，依賴一個或幾個領導者，他們追蹤著每件事和版本。我們沒有許多擁有大量不同文檔的項目。

      其次，我們也依賴于低的期望值。沒有人對我們有成功的預期，所以，對于這個運動，任何一個成功都是個勝利�，F在，所有的眼睛都盯著我們。如果一個發布版延遲一個月發布，每個人都會說我們在保持時間表上做得不如微軟。如果我們因為我們的可憐的設計而重寫了一個應用，我們將不能提供有效的替代品。我們將不得不做得比其他人更好以證明我們自己，并且我們不能做面向特定平臺環境的產品。如果開放源碼社區比工業界學習MMM學得更好，那么，我們將獲勝。

      再次，作為一個工業，我們必須提升我們軟件的期望。我們要為精確的時間表努力奮斗。我們需要避免第二系統的影響。我們需要知道為什么你不能加人到已經延誤的項目去加速開發。長話短說，我們需要仔細工作以及時產出合格的軟件，而不是僅僅將原料放在那兒。


Francis Glassborow
      我第一次接觸這本書在近二十年前。作為一個學校老師，我毫不懷疑這本書應是我的天才計算機專家的小伙子們需要讀的。也許我的成功不能表示它的價值，也許人們不知道它。

      計算機圖書常常在用舊前很長時間就已過時了，但這部書是一個值得注意的例外。作者描述了管理的失敗導致延誤了在恰當時候交付的問題，在今天——《人月神話》首次出版以來二十周年后，依舊在發生。加倍的工作力量在今天和他那時一樣不能解決時間（表）的流逝。

      如果，你已經擁有了老版本，你仍然會為帶有額外的四章的新版感到高興；如果你以前從未讀過它，把其他事放在一邊，立刻補上這重要的一課。象老版本對暴露關于延遲六、七十次的IBM感興趣一樣，這個版本增加了一些關于微軟的注釋（盡管如此，每晚重建開發項目的策略不能解釋為何Windows95的M8 beta版的版本是950版）。


Chris Larson
      自Frederick P. Brooks, Jr. 出版經典著作《人月神話：軟件工程隨筆》已經20年了。在這部注重實效、明晰的書中，Brooks剖析了許多工程管理的神話，這些神話來自他在年輕的軟件工業中有意義的實踐。典型的，他抨擊了在項目中增加人手可以促進項目的完成的幻想。帶著實例、幽默、嚴密的邏輯，Brooks展示了這些神話實際上如何給軟件項目帶來災難并導致延遲。


你不能用人力換取時間 
      他的思想恰到好處地應用于文檔項目的管理。有多少次查看文檔項目的經理思考通過增加人手縮短時間表？這是個簡單的導致陷入的謬誤，但Brooks清晰地表達了這樣的思想－“人力可以與時間互換”的實際效果。
Brooks說，“導致大量軟件項目進入失控的原因是時間表的缺漏，這比所有其它因素的組合還多�！彼�給出了幾個原因。首先，Brooks責備可憐的估計技術，它錯誤的“搞亂了前進中的努力�！币驗楣烙嫷牟淮_定性，經理們缺少“禮貌的倔強”去支持那些看上去比其它需要更長的時間線的步驟。一旦時間（表）流逝，傾向于加入更多的人力，而這就像“火上澆油”，會導致一個新的災難生成的循環。

      當然，一個基本的錯誤就是假定人力可以嚴格的和時間交換。Brooks指出，這個公式僅在項目成員不需要和其他人交流的項目中成立，比如：拾棉花。

      然而，一旦項目中包含連續任務和依賴關系時，可以交換的思想立刻就土崩瓦解了�！敖涣鞯呐�力，”Brooks說，“必定導致加入大量要做的工作……。三個工作者要求的成對交互交流三倍于兩個；四個六倍于兩個�！边@個交流的時間（不包括培訓時間）吸收了許多增加人力分擔任務帶來的好處。

那么，答案是什么？
      Brooks認為由一個組織，其結構類似于外科團隊的，由一些專家設計并完成全部項目的核心工作而由另外的人力在特定的途徑上支持他們的努力，來執行產品開發可以治愈上述病癥。

      Brooks說到，這條僅有的路是在一個項目早期完成“概念完整性”的通途。大部分關于這些完整性的重要的表述通過這個規范發生，“那是一本計算機手冊加上性能規范……第一批文檔中的一篇產生計劃中的一個新產品，最后的文檔完成它�！�

文檔是關鍵
      Brooks繼續雄辯的支持文檔，列出用戶需要的每一項，以免只見樹木不見森林：程序的目的、環境、選項、邏輯、“運行時間、”等等。并且認為：“大部分文檔需要在程序編寫前起草，因為它把基本的計劃決策具體化了�！�

      作為技術交流者，我們需要聽到來自工程方面的更多的各種各樣的支持。盡管Brooks的環境——運行于大機上的大型編程項目——已經轉換到我們今天的分布式計算環境，Brooks的邏輯和清晰的思想依舊吹走了仍然威脅卷入項目管理中的迷霧。


Frank Chance
介紹
      出版于1975年的《人月神話》是軟件開發方面的經典作品。1995年版包括了令人感興趣的新的幾章，但原來的隨筆依然是這本書的心臟與靈魂。在這本書中，Brooks解決了如何組織和管理大規模編程項目的問題。這些項目要求成百上千的程序員，產生幾百萬行代碼（想想SAP、Oracle數據庫引擎、Windows2000）。這部書由一系列簡明的隨筆組成。在這篇評論中我將討論開篇隨筆——我的最愛之一。

焦油坑
      Brooks將大系統編程作比喻作史前的焦油坑來開始他的第一篇隨筆：“記憶中，我們看到恐龍、猛犸象、劍齒虎正在掙脫瀝青的魔爪。掙扎得越劇烈，陷入的越深，沒有哪只野獸足夠強壯或熟練，它們最終都沉沒了。大系統編程在過去的十年間就像焦油坑，許多大而強有力的野獸在其中已經慘烈地失敗了。大部分已實現并在運行的系統，很少有達到目標、時間表和預算的。大和小、厚重和細實，一個接一個的團隊卷入了瀝青（陷阱）。沒有什么事情似乎會導致這個困難——任何特殊的手掌都能被拉出來。但同時并相互作用的因數的相互聚集導致運動越來越慢。每個人似乎都驚訝于問題的難纏，難于面對它的本質�！�

記住，這些話寫于1975年。今天它們仍然可用嗎？考慮一下WindowsNT5.0。第一次計劃于1997年發布，隨后延遲到1998年早期，1998年末，然后是1999年（為此它被重新命名為Windows2000）。這兒是一些公開的估計：


   5,000程序員。

  35,000,000 行代碼。

顯然，NT5.0是個大系統編程項目。同樣顯而易見，Brooks的焦油坑在今天同1975年一樣普遍！

讓我們繼續NT5.0的例子。假設最糟糕的情況，全部35,000,000 行代碼都是新編的。有理由假設開發工作大致在1994年開始。所以我們有：

  5,000 程序員 X 5 年 = 25,000 程序員年

   35,000,000 行代碼 / 25,000 程序員年 = 1,400 行／程序員年。

如果你是個程序員，或者你只接受過編程課程的教育，這個數字（1,400行每年）似乎令人驚異的低。我們當中的大部分人都能在一兩天內堆積出接近一千行的代碼。什么使得Microsoft的程序員一整年才產出1,400行代碼？

兩種可能性躍入我們的腦海：

  Microsoft 雇用了5,000名不合格的程序員去開發NT 5.0。

或者

  寫一個大規模的程序系統產品遠難于堆砌出單一的程序。

Brooks將討論認為后一個答案是正確的。他由定義術語開始：

（1） 程序

一個獨立的程序是我們兩天編程狂歡的結果。它是準備自己運行于我們編程的那臺機器上的。如果我們加上文檔、通用化代碼、編寫測試用例、使得代碼可以由其他無關的編程人員來維護，我們就有了：

（2） 程序產品

另外，如果我們接受我們的程序，并且完整地定義了它的接口使得它達到預定義的規范，并且測試了它和大量的其它組件的交互作用，我們就有：

（3） 程序系統組件

并且如果我們都做了（加上文檔、通用化代碼、編寫測試用例、使得代碼可維護、定義了接口、測試了交互作用），我們就有：

（4） 程序系統產品組件

Brooks用手邊的三倍規則說明在上述每個步驟中的工作要求：

（2）＝3倍（1）的人力

（3）＝3倍（1）的人力 （4）＝9倍（1）的人力

或者，換句話說，開發一個獨立的程序僅僅要求開發一個程序系統組件的1／9的人力。

回到Microsoft的例子，如果我們將這個9倍的因子乘以1,400行每程序員年的生產力測量，我們得到12,600行每程序員年（舉例來說，假設我們掌握每一程序員，并且使得他們獨立工作，堆砌在單一的程序上）。在一篇獨立的隨筆中，Brooks引用一個發現這點的經理的話說，平均他的每個程序員僅能將他的一半時間用于開發——其它時間由文書工作、會議和各種其它任務所占據。把這些因素考慮到Microsoft的例子中，我們達到了25,200行每程序員年。那么，Microsoft的程序員開始看來非�？删�。另一個測量自1975年來有了很小的改變，Brooks引用的估計是1,000行每程序員年。如果上面引用的1,400行每程序員年是精確的，那么，它表現了在1975年到1995年20年間，生產力僅僅提升了1.75%每年。這個結果證實了Brooks的另一個假定——程序員的生產力相對是個常量，它不受開發所用的語言的影響。因此，實際的生產力收獲來自于遷移到高級語言編程，這些語言每行表達了更多的實際工作。盡管目標是大系統項目，Brooks的解釋常常被廣泛的應用。例如，這個第一篇隨筆用標有“手藝的快樂”和“手藝的悲哀”的小節來結束。在悲哀中，他討論了荒廢的問題：

“…這個人們已經工作了很長時間的產品，顯然在完成前將被廢棄。同事和競爭者已經在熱烈地用新的和更好的主意反擊。人們的孩童般想法的取代已經不僅僅在構思，而且付諸時間表。這一切總是似乎比它的實際更糟糕。新的和更好的想法通常在完成之前不被應用；它僅僅被談論。真老虎永遠不能和紙老虎相比�！�

小結
Brooks的隨筆涉及到了大系統編程所固有的多種挑戰，但對任何投身于軟件開發的人來說讀這本書都是有用的。題名的隨筆（《人月神話》）討論了許多編程任務的不可分割性，和為什么增加人力到軟件項目中無法產生效用。我的另一篇最愛是“貴族、民主和系統設計”（概念完整性的討論）和“計劃和投放之路”（在付運前多次交付的明確計劃的益處）。一些問題已經因為技術的進步而廢棄，例如關于如何在一個大型團隊中分發寫好的文檔。然而，你可能驚訝Brooks面對的許多問題今天如何阻止我們。另外的益處是Brooks簡潔、清晰的作品讀起來令人愉快。如果你是個程序員，如果你和程序員一起工作，如果你管理程序員，你應該閱讀這本書。


TAL COHEN
人們說在計算機世界中每件事都在迅速的變化，然而，在二十多年間，一些重要的事情依舊沒有改變。

如果某個工作可以由十個人在一個月內完成，人們說這個工作要求十個人月（man-months，也叫“person-months”）。簡單算術表明，如果你分配二十個人去作同樣的工作，它應在五個月內被完成。（譯注：應該是半個月）我想這個邏輯在許多項目中大概都是正確的，否則，經濟學家將不會那么令人喜愛。

然而，在軟件設計的世界，這個承諾是個徹底的謬誤。沒有那條途徑可以產生它。一個能由一個程序員在兩個月內完成的程序，也許會花去兩個程序員三個月的時間。早在1975年，當軟件工程還是非常年輕的專業時，Frederick Brooks敏銳地觀察到人月概念僅僅是個神話。

在70年代，軟件工程項目管理的問題背景是：大部分經理是受的經濟領域的教育而不是計算機，并且他們熟悉的理論不能簡單的用于軟件項目。事實上，沒有用于軟件設計項目的相同的理論。因為直到今天，大部分軟件項目仍不能按照時間表發布，所以我們有個大膽的暗示：這個問題象許多Brooks在書中談到的那些問題一樣，仍未解決。

在20周年紀念版的序言中，Brooks寫到：

讓我高興和驚訝的是，《人月神話》在20年后依舊流行。

實際上，這真令人羞愧。它指出了在二十年間，軟件工業沒有學到一些嚴重的教訓，它仍在付著學費。軟件工程依然被認為和其它工程專業相比是個很陌生的藝術。真的，我是第一次接納軟件編寫中存在藝術的觀點。它是一種美麗的、精巧的藝術，僅僅能被那些掌握同樣藝術的人所欣賞。我相信，當一個真正的代碼藝術家完工時，它比建筑更加迷人、比油畫更加引人入勝、比音樂更加令人思潮澎湃。然而，一個建筑師不會讓房屋設計的藝術外觀將他從房屋可以經受住最起碼的地震的保證中轉移出來。這個事實正漸漸的被大部分軟件專家——那是些認為自己是藝術家而拒絕承認自己是工程師的人，所理解。（一個有趣的解決方案，是由我的好朋友提出的，他認為他自己是個“軟件架構師”。） Brooks的工作是簡單的而且對于那些被認為在軟件業務領域是個專家的人是必需的，尤其對于在這個領域從事管理工作的人。這部書不僅僅指出了問題，而且也提出了些有趣的解決方案（例如：“外科團隊”）。它指出了這個領域的每個專業人士都應該知道的一些非常重要的缺陷（例如“第二系統”效應）。最后，它提供了許多重要的見解和案例研究。

書中大部分材料和今天依然相關，就象它在原書寫出來的時候。盡管，眾所周知，部分材料已經過期時。在20周年紀念版中，相對于原文——叫做“經典”——的修訂，Brooks聰明地決定加入修改的章節。那些用來討論暴露于90年代燈光下的出現的問題。我個人認為，在讀完前面的每一章后應讀第18章中有關的部分。第18章的標題是“人月神話的主題：是或非？”，它包括了從1到17章的修改信息。

最后，這個新版本包括重印的Brooks的著名隨筆，“沒有銀彈”，那是在都柏林IFIP86會議上的特邀論文，后來在Computer雜志上發表。在這篇文章中，Brooks推測在他的文章出版（1986年）后的十年，不會發現有技術可以大大增強軟件開發過程。九年過去了，Brooks悲哀地回顧：他還是正確的。

延伸閱讀

文章來源于領測軟件測試網 http://www.kjueaiud.com/