在軟件領域，很少能有像《人月神話》一樣具有深遠影響力和長銷不衰的著作。布魯克斯博士為人們管理復雜項目提供了頗具洞察力的見解，從宏觀角度有層次地分析了軟件工程的方方面面，不僅邏輯嚴謹，而且頗具文化底蘊。《人月神話(紀念典藏版)》內容主要來自布魯克斯博士在IBM公司研發并管理System/360計算機家族和OS/360軟件支持包期間的項目管理經驗，該項目堪稱軟件開發項目管理的典范。
《人月神話(紀念典藏版)》英文版一經面世，即引起業內人士的強烈反響，后譯為德、法、日、俄、中、韓等多種文字，成為軟件開發和管理人員的必讀經典。
再讀軟件經典 如品陳年佳釀
《人月神話》是軟件工程領域絕無僅有的經典佳作，歷時近半個世紀，作者Fred Brooks對大型軟件項目管理的經驗思考啟迪了一代代工程師的實踐。
《人月神話》一書的開篇強調了構建“系統產品”與構建“簡單程序”的任務不同。研發大型軟件系統不是簡單程序的堆疊組裝。軟件開發任務不總是像收割麥子的任務一樣可分解，要分析問題性質以及子任務間的依賴關系。軟件研發效能的量化估算不能對“人月”“人周”“人天”做簡單加法和乘法，正如不能基于個人百米成績來推算馬拉松成績一樣。新手培訓、溝通交互都會引入額外的成本，向延期的軟件項目添加新人會使項目拖得更久。軟件開發任務間復雜的依賴關系需要科學管理，避免無效的人力投入。
軟件不可見性和抽象性是導致軟件復雜性的根本原因，也是軟件工程學科要應對的基本問題。軟件系統的復雜性源于參與開發人員的概念模型是不完整和不一致的，正如“一千個人眼中有一千個哈姆雷特”，管理軟件項目的復雜性就需要達成各方對軟件系統概念模型的局部完整性與一致性。軟件項目開發團隊的組織要融合開源、群智，以及規模化敏捷組織的最新理念，還要堅守外科手術團隊這樣的組織結構，持續優化大規模軟件系統產品項目的組織與流程。
我國軟件產業規模已突破十萬億元，成為軟件大國的同時還處在“大而不強”的困境，在系統軟件與工業軟件領域還面臨著被“卡脖子”的風險。《人月神話》一書中的許多經驗、觀點對于我國關鍵基礎軟件技術、產品與產業創新發展具有重要指導意義。
今天作為數字經濟社會基礎設施的系統軟件和工業軟件，都是經過數十年長期演進與發展的軟件，是軟件產業的根技術。如何改變這種受制于人的被動局面？我想在全力投入攻堅之外，還要深入思考、深入探究這類軟件產品工程研發的內在規律。實現軟件產業高質量發展的關鍵在于建立開發“能用、管用、好用”的關鍵系統軟件和基礎工業軟件的工程方法與工具體系。
軟件工程“沒有銀彈”的觀點還成立嗎？用“塑料薄膜包裝的成品軟件”無疑已成為歷史，但并不妨礙它當年為軟件產業發展帶來的積極貢獻與影響。進入軟件開源與大語言模型時代，軟件工程領域的“銀彈”是否已經出現？大語言模型在代碼輔助生成以及算法編程優化等方面展現出強大的能力，它會將軟件領域帶向何種高度？
再讀“人月神話”，今時今日又繪新意。軟件定義美好世界， 既是國家示范性軟件學院成立的初心，也是清華大學軟件學院在建院二十周年時對初心的再次表達。軟件系統的形態，軟件工程的方法將在實踐者的持續探索和研究者的深入思考中不斷演進。
王建民 清華大學軟件學院院長
2023年6月
小弗雷德里克·P.布魯克斯（Frederick P. Brooks, Jr．1931—2022），圖靈獎得主、美國國家科學院院士，對計算機體系結構、操作系統和軟件工程做出里程碑式貢獻的計算機科學家。
布魯克斯博士于20世紀60年代初主持與領導了被稱為人類從原子能時代進入信息時代的標志的IBM/360系列計算機的開發工作，取得輝煌成功，被認為是“IBM 360系統之父”。布魯克斯博士創立了北卡羅來納大學的計算機科學系，并于1965—1985年擔任系主任。他還曾任職于美國國家科技局和國防科學技術委員會。
布魯克斯博士作為硬件和軟件的雙重專家和出色的教育家始終活躍在計算機舞臺上，因其專業成就和對計算機體系結構的卓越貢獻而屢獲表彰，包括美國國家技術獎、ACM杰出服務獎、ACM Fellow、ACM Newell獎、IEEE McDowell獎、計算機先驅獎、馮·諾伊曼獎、富蘭克林學會鮑爾獎、圖靈獎等。
第1章 焦油坑 / 001
編程系統產品 / 003
職業的樂趣 / 005
職業的苦惱 / 006
第2章 人月神話 / 009
樂觀主義 / 011
人 月 / 013
系統測試 / 016
怯懦的估算 / 018
重復產生的進度災難 / 019
第3章 外科手術團隊 / 025
問 題 / 027
Mills的建議 / 029
如何運作 / 032
團隊的擴建 / 033
第4章 貴族制、民主制和系統設計 / 035
概念上的完整性 / 037
獲得概念的完整性 / 038
貴族制和民主制 / 039
在等待時，實現人員做什么 / 042
第5章 第二系統效應 / 045
架構師的互動紀律 / 047
自律—第二系統效應 / 048
第6章 傳遞消息 / 053
書面規約—手冊 / 055
形式化定義 / 056
直接整合 / 059
會議和大會 / 059
第7章 為什么巴別塔會失敗 / 065
巴別塔的管理教訓 / 067
大型編程項目中的交流 / 068
項目工作手冊 / 068
大型編程項目的組織架構 / 072
第8章 胸有成竹 / 077
Portman的數據 / 080
Aron的數據 / 081
Harr的數據 / 082
OS/360的數據 / 083
Corbató的數據 / 084
第9章 削足適履 / 085
作為成本的程序空間 / 087
規模控制 / 088
空間技能 / 090
數據的表現形式是編程的根本 / 091
第10章 提綱挈領 / 093
計算機產品的文檔 / 095
大學科系的文檔 / 097
軟件項目的文檔 / 097
為什么要有正式的文檔 / 098
第11章 未雨綢繆 / 101
試驗性工廠和增大規模 / 103
唯一不變的就是變化本身 / 104
為變更設計系統 / 104
為變更計劃組織架構 / 105
前進兩步，后退一步 / 107
前進一步，后退一步 / 109
第12章 干將莫邪 / 111
目標機器 / 114
輔助機器和數據服務 / 116
高級語言和交互式編程 / 119
第13章 整體部分 / 123
剔除bug的設計 / 125
構件單元調試 / 127
系統集成調試 / 130
第14章 禍起蕭墻 / 135
是里程碑還是沉重的負擔 / 137
“其他的部分反正會落后” / 139
地毯的下面 / 140
第15章 另外一面 / 145
需要什么文檔 / 148
流程圖 / 150
自文檔化的程序 / 154
第16章 沒有銀彈—— 軟件工程中的根本和次要問題 / 161
摘 要 / 163
介 紹 / 163
根本困難 / 164
以往解決次要困難的一些突破 / 169
銀彈的希望 / 170
針對概念上根本問題的頗具前途的方法 / 179
第17章 再論“沒有銀彈” / 187
人狼和其他恐怖傳說 / 189
存在著銀彈—就在這里 / 189
含糊的表達將會導致誤解 / 190
Harel的分析 / 193
Jones的觀點—質量帶來生產率 / 199
那么，生產率的情形如何 / 199
面向對象編程—這顆銅質子彈可以嗎 / 201
重用的情況怎樣 / 203
學習大量的詞匯—對軟件重用的一個可預見但還沒有被預言的問題 / 206
子彈的本質—形勢沒有發生改變 / 207
第18章 《人月神話》的觀點：是與非 / 209
第19章 20年后的《人月神話》 / 233
為什么要出版20周年紀念版本 / 235
核心觀點—概念完整性和結構師 / 236
開發第二個系統所引起的后果—盲目的功能和頻率猜測 / 238
圖形界面的成功 / 241
沒有構建舍棄原型—瀑布模型是錯誤的 / 245
增量開發模型更佳—漸進地精化 / 247
關于信息隱藏，Parnas是正確的，我是錯誤的 / 252
人月到底有多少神話色彩？Boehm的模型和數據 / 254
人就是一切(或者說，幾乎是一切) / 256
放棄權力的力量 / 257
最令人驚訝的新事物是什么？數百萬的計算機 / 260
全新的軟件產業—塑料薄膜包裝的成品軟件 / 262
買來開發—使用塑料包裝的成品軟件包作為構件 / 265
軟件工程的狀態和未來 / 267
結束語 令人向往、激動人心和充滿樂趣的50年 / 269
譯后記 / 271
新書資訊