推薦理由：

作為一部在軟件領域40年暢銷不衰的傳奇經典，很少能有像《人月神話》一樣具有深遠影響力和暢銷不衰的著作。Brooks博士為人們管理復雜項目提供了最具洞察力的見解，既有很多發人深省的觀點，又有大量軟件工程的實踐。本書內容來自Brooks博士在IBM公司SYSTEM/360家族和OS/360中的項目管理經驗，該項目堪稱軟件開發項目管理的典范。該書英文原版一經面世，即引起業內人士的強烈反響，后又譯為德、法、日、俄、中、韓等多種文字，全球銷售數百萬冊。確立了其在行業內的經典地位，被譽為軟件開發人員、軟件項目經理、系統分析師必藏之軟工圣經。

本書要點：

第一章 焦油坑

將大型系統的開發比做史前時代的焦油坑，如被其吞噬的成千上萬個力大無窮的巨獸一樣，今天的大型軟件項目則令無數龐大的開發團隊陷入無從逃脫的窘境。向我們闡述了程序、編程產品、編程系統產品這三個按開發目標、規模不同而劃分的程序員得出軟件程序產品，進而指出由這個帶來的無窮樂趣和行業苦惱的根源。

第二章 人月神話

項目滯后的眾多原因中最主要的是缺乏合理的時間進度，這比其他因素綜合起來還要大。指出幾個錯誤的思考方式：一、所有的編程人員都是樂觀主義者：“一切都將運作良好”；二、估計和進度安排中使用人月來作為工作量單位，而這個危險帶有欺騙性的度量暗示人員數量和時間是可以互相替換的，這種錯誤的暗示忽視了人員之間的交流以及任務分解存在次序限制。提出了Brooks法則：向滯后的軟件項目追加人手會使得進度更加落后。

第三章 外科手術隊伍

優秀的程序員的成產率平均比較差程序員的高達10倍，但純粹由優秀的程序員組成的小型、精干隊伍對于大型系統來說又太慢了。優秀的大型優秀團隊需要合理的配置，本章推薦大型軟件開發項目的團隊需要和外科手術組一樣妥善分工，各司其職協調配合。

第四章 貴族專制、民主政治和系統設計

概念的完整性是系統設計總最重要的因素，關乎項目能否順利進行，為了達到概念的完整性，架構設計由精簡的架構設計小組及負責所謂的貴族專制統治，而這不是否定實現人員的創造性，只是具體實現則圍繞核心概念展開，是另一種創造，彰顯了民主政治，架構設計和具體實現既相分離，又相輔相成。

第五章 畫蛇添足

第二個系統是人們所設計的最危險的系統，通常的傾向是過分地進行設計，成為畫蛇添足的犧牲品。為了避免這種冒進錯誤，要運用特別的自我約束準則來避免功能上的過于修飾，根據系統基本理念及目標變更舍棄一些功能，開發時審慎地考查技術環境的變化，廣泛進行交流和溝通，聆聽各方面的建議，確立嚴謹的估算和規劃。

第六章 貫徹執行

為保持系統概念上的完整性，須確保每個人聽到、理解并實現結構師的決策。本章以System 360的開發經驗為例介紹了文檔化的規格說明—手冊的重要性，采用形式化定義、會議、大會、電話日志等技術確保概念被精確地定義傳達貫徹執行。同時提出獨立的測試小組也是在系統設計實施中重要的保障環節。

第七章 為什么巴比倫塔會失敗

以巴比倫塔失敗為例，指出交流和交流的結果－組織是成功的關鍵，交流和組織的技能需要管理者仔細考慮，相關經驗的積累和能力的提高同軟件技術本身一樣重要。如果缺乏良好有效的溝通和協作，成員間難以有效的配合，團隊項目的目標就無法實現。清晰的工作文檔，明確的組織結構，合理的職責分配，都是大型軟件項目最終成功的保證。

第八章? 胸有成竹

僅僅對編碼部分的估計是無法的得出整個任務的估計，編碼部分只占問題的1/6左右，測試和調試時間更多。同時獨立小型程序的數據不適用于編程系統產品。

第九章 削足適履

規模是軟件系統成本的重要組成部分，開發人員設置規模目標，控制成本，合理減小不必要規模是設計人員重要的職責。使軟件系統在資源有限的情況下依然保證了良好的性能，從而實現良好的可伸縮性和健壯性，巧妙的數據表現形式往往能大幅度地儉省資源耗費，提高系統運行的性能，是編程的根本。

第十章? 提綱挈領

強調了在軟件項目開發過程中文檔的重要性。文檔能記錄決策，消除分析，使決策清晰明確；也可以作為溝通的渠道；作為數據基礎和檢查列表。介紹了項目中比較重要的幾種文檔。

第十一章 未雨綢繆

唯一不變的就是變化本身，對于大多數項目第一個開發的系統并不合用，為舍棄而計劃。要為變更設計系統，計劃組織架構。設計可替代的，易修改的接口，程序更能減少維護的成本。即使最熟練的軟件維護工作也只是放緩系統退化的進程，因此要時刻未雨綢繆。

第十二章 干將莫邪

本章強調了軟件開發項目所選擇的技術和工具對保障項目能否令人滿意地如期完成的重要性。我們應當同時合理運用個性化和公共通用編程開發工具、評測技術，為此需要制定一套合理的策略。本章提供了當年軟件開發項目選擇技術和工具的重要原則和建議。

第十三章 整體部分

本章細致介紹了如何開發一個可運行系統，測試系統，系統集成。我應當具體深入了解系統所有的局部設計的精確定義和技術，采用測試規格說明，自上而下的設計，結構化編程，構件單元測試等技術開發系統。實際工作中測試越早，集成越早代價更小，更早消滅隱患。采用一次添加一個構件。

第十四章 禍起蕭墻

項目進度的滯后經常來自不易察覺的點滴延誤的累積。設置里程碑可以有效幫助管理進度，但是其本身必須清晰明確可度量，不要自身變成負擔。經理在管理進度時需減少角色的沖突，使報告更真實或者采用猛拉地毯形式時刻關注，采用關鍵路徑圖等技術觀察進度合理調控。

第十五章 另一面

公共程序用戶與作者時空上都存在巨大距離，因此對于這類程序文檔就很重要，故而提供給用戶的使用說明等文檔是軟件呈現給用戶的另外一面，這也能直接影響用戶對軟件的滿意度和可用性評價。文檔內容取決于用戶需求：使用程序、驗證程序、修改程序，形式有流程圖、自動文檔化的程序（建立在高級編程語言之上）。

第十六章 沒有銀彈－軟件工程中的根本和次要問題

本章提出軟件工程中存在根本問題與次要問題之分，而只有解決根本問題才能極大提高生產率，而這種解決方法稱之為“銀彈”。由于軟件的復雜性，一致性，變化性和不可見性，解決軟件危機的銀彈并不存在。接著介紹了二十世紀80年代前期為業界寄予厚望的一些新技術，討論了它們在克服軟件危機中所具備的優勢和缺憾。給出了作者的結論：沒有任何單獨的軟件工程進展可以使軟件生產率有數量級的提高。

第十七章 再議“沒有銀彈”

本章在“沒有銀彈”發表多年之后，結合20世紀80年代后期到90年代前期之間軟件復用、面向對象程序開發等等新技術的發展狀況，回應了對《沒有銀彈》一文各種主要異議堅持了原文的觀點。

第十八章 《人月神話》的觀點：是與非

本章為作者對初版中十五個章節中概要的提煉和結合近年來軟件技術的發展狀況，對這些觀點進行強調、修正和反思。

第十九章 人月神話二十年

“ 在《人月神話》初版發布二十周年后，計算機技術領域已有很大變化，《人月神話》體現出深遠的影響力，初版中的許多觀點依然經常被人們談論和引用，其中有些斷言至今仍被軟件開放人員奉為圭臬。作者結合當前軟件工程領域的發展現狀重新梳理了初版中的各核心觀點，強調了概念完整性，重新評議了第二個系統效應，反省了瀑布模型的局限性，結合初版中的觀點，作者評述了圖形桌面系統、信息隱藏、面向對象高級語言等技術的發展，以及近年來軟件工程領域的重要成果。”

——引用自書評。

書摘：

首先是一種創建事物的純粹快樂。如同小孩在玩泥巴時感到愉快一樣,成年人喜歡創 建事物,特別是自己進行設計。我想這種快樂是上帝創造世界的折射,一種呈現在每片獨特、 嶄新的樹葉和雪花上的喜悅。

簡單、武斷地重復一下Brooks法則: 向進度落后的項目中增加人手,只會使進度更加落后。(Adding manpower to a late software project makes it later)

風格的一致和完整性來自8代擁有自我約束和犧牲精神的建筑師們,他們每一個人 犧牲了自己的一些創意,以獲得純粹的設計。同樣,這不僅顯示了上帝的榮耀,同時也體現 了他拯救那些沉醉在自我驕傲中的人們的力量。

如果要得到系統概念上的完整性,那 么必須控制這些概念。這實際上是一種無需任何歉意的貴族專制統治。

結構師如何避免畫蛇添足——開發第二個系統所引起的后果(second-system effect)?是的,他無法跳過二次系統。但他可以有意識關注那些系統的特殊危險,運用特 別的自我約束準則,來避免那些功能上的修飾;根據系統基本理念及目的變更,舍棄一些功 能。

項目經理最好的朋友就是他每天要面對的敵人——獨立的產品測試機構/小組。該 小組根據規格說明檢查機器和程序,充當麻煩的代言人,查明每一個可能的缺陷和相互 矛盾的地方。每個開發機構都需要這樣一個獨立的技術監督部門,來保證其公正性。

編程人員僅了 解自己負責的部分,而不是整個系統的開發細節時,工作效率最高。這種方法的先決條件是 精確和完整地定義所有接口。這的確是一個徹底的解決方法。如果能處理得好,的確是能解 決很多“災難”。一個好的信息系統不但能暴露接口錯誤,還能有助于改正錯誤。

交流和交流的結果— —組織,是成功的關鍵。交流和組織的技能需要管理者仔細考慮,相關經驗的積累和能力的 提高同軟件技術本身一樣重要。

實際上,數據的表現形式是 編程的根本。

然而,目標上的一些變化無可避免,事先為它們做準備總比假設它們不會出現要好得 多。不但目標上的變化不可避免,而且設計策略和技術上的變化也不可避免。拋棄原型概念 本身就是對事實的接受——隨著學習的過程更改設計 。

系統軟件開發是減少混亂度(減少熵)的過程,所以它本身是處于亞穩態的。軟件維 護是提高混亂度(增加熵)的過程,即使是最熟練的軟件維護工作,也只是放緩了系統退化 到非穩態的進程。

所有軟件活動包括根本任務——打造由抽象軟件實體構成的復雜概念結構,次要任務 ——使用編程語言表達這些抽象實體,在空間和時間限制內將它們映射成機器語言。

不僅僅是在目力所及的范圍內,沒有發現銀彈,而且軟件的特性本身也導致了不大可 能有任何的發明創新——能夠像計算機硬件工業中的微電子器件、晶體管、大規模集成一樣 ——提高軟件的生產率、可靠性和簡潔程度。我們甚至不能期望每兩年有一倍的增長。

夏明瑞 MF1632082