具體描述
在軟件領域，很少能有像《人月神話》一樣具有深遠影響力和暢銷不衰的著作。Brooks博士為人們管理復雜項目提供瞭最具洞察力的見解，既有很多發人深省的觀點，又有大量軟件工程的實踐。本書內容來自Brooks博士在IBM公司SYSTEM／360傢族和OS／360中的項目管理經驗，該項目堪稱軟件開發項目管理的典範。該書英文原版一經麵世，即引起業內人士的強烈反響，後又譯為德、法、日、俄、中、韓等多種文字，全球銷售數百萬冊。確立瞭其在行業內的經典地位。
在本書第一次齣版40年後的今天，我們重新整理瞭Brooks博士的經典內容，並將國內軟件開發領域先行者們對《人月神話》中的實踐及係統理論的使用經驗和心得集結成冊免費贈與大傢共享，更使本書成為國內從業者的必讀經典之一。
本書讀者包括：軟件開發人員、軟件項目經理、係統分析師等IT從業者。
著者簡介
小弗雷德裏剋•布魯剋斯曾獲得美國計算機領域最具聲望的圖靈奬(A. M. Turing Award)。美國計算機協會(ACM)稱贊他“對計算機體係結構、操作係統和軟件工程做齣瞭裏程碑式的貢獻”。
布魯剋斯博士1956年開始任職於IBM公司，早期擔任Stretch 和Harvest計算機的體係建構師。他被認為是“IBM 360係統之父”，曾擔任360係統的項目經理。憑藉在此項目中的傑齣貢獻，他與Bob Evans和Erich Bloch在1985年獲得瞭美國國傢技術奬(National Medal of Technology)。
布魯剋斯博士創立瞭北卡羅來納大學的計算機科學係，並於1965-1985年擔任係主任。他還曾任職於美國國傢科技局和國防科學技術委員會。目前其仍活躍於從事虛擬環境和科學可視化等方麵的研究工作，2010年獲得虛擬現實事業奬(IEEE Virtual Reality Career Award)。
圖書目錄
編程係統産品 4
職業的樂趣 6
職業的苦惱 8
第2章 人月神話 11
樂觀主義 14
人月 16
係統測試 19
空泛的估算 21
重復産生的進度災難 22
第3章 外科手術隊伍 27
問題 30
Mills的建議 32
如何運作 35
團隊的擴建 36
第4章 貴族專製、民主政治和係統設計 39
概念的完整性 42
獲得概念的完整性 43
貴族專製統治和民主政治 44
在等待時，實現人員應該做什麼 47
第5章 畫蛇添足 51
結構師的交互準則和機製 54
自律—— 開發第二個係統所帶來的後果 55
第6章 貫徹執行 59
文檔化的規格說明—— 手冊 62
形式化定義 63
直接整閤 66
會議和大會 66
多重實現 68
電話日誌 68
産品測試 69
第7章 為什麼巴比倫塔會失敗 71
巴比倫塔的管理教訓 75
大型編程項目中的交流 76
項目工作手冊 76
大型編程項目的組織架構 80
第8章 胸有成竹 85
Portman的數據 89
Aron的數據 90
Harr的數據 90
OS/360的數據 92
Corbató的數據 93
第9章 削足適履 95
作為成本的程序空間 98
規模控製 99
空間技能 100
數據的錶現形式是編程的根本 102
第10章 提綱挈領 105
計算機産品的文檔 108
大學科係的文檔 110
軟件項目的文檔 110
為什麼要有正式的文檔 111
第11章 未雨綢繆 113
試驗性工廠和增大規模 116
唯一不變的就是變化本身 117
為變更設計係統 117
為變更計劃組織架構 118
前進兩步，後退一步 120
前進一步，後退一步 122
第12章 乾將莫邪 125
目標機器 129
輔助機器和數據服務 131
高級語言和交互式編程 134
第13章 整體部分 139
剔除bug的設計 142
構件單元調試 144
係統集成調試 147
第14章 禍起蕭牆 153
裏程碑還是沉重的負擔 156
“其他的部分反正會落後” 158
地毯的下麵 159
第15章 另外一麵 165
需要什麼樣的文檔 169
流程圖 171
自文檔化的程序 175
第16章 沒有銀彈 181
摘要 184
介紹 184
根本睏難 185
以往解決次要睏難的一些突破 190
銀彈的希望 192
針對概念上根本問題的頗具前途的方法 200
第17章 再論“沒有銀彈” 209
人狼和其他恐怖傳說 212
存在著銀彈—— 就在這裏 212
含糊的錶達將會導緻誤解 213
Harel的分析 216
Jones的觀點—— 質量帶來生産率 221
那麼，生産率的情形如何 222
麵嚮對象編程—— 這顆銅質子彈可以嗎 223
重用的情況怎樣 225
學習大量的詞匯—— 對軟件重用的一個可預見但還沒有被預言的問題 228
子彈的本質—— 形勢沒有發生改變 229
第18章 《人月神話》的觀點：是與非 231
第1章 焦油坑 234
第2章 人月神話 235
第3章 外科手術隊伍 236
第4章 貴族專製、民主政治和係統設計 237
第5章 畫蛇添足 238
第6章 貫徹執行 239
第7章 為什麼巴比倫塔會失敗 240
第8章 胸有成竹 242
第9章 削足適履 243
第10章 提綱挈領 245
第11章 未雨綢繆 246
第12章 乾將莫邪 249
第13章 整體部分 251
第14章 禍起蕭牆 253
第15章 另外一麵 255
第1版結束語 256
第19章 20年後的《人月神話》 257
為什麼要齣版20周年紀念版本 260
核心觀點—— 概念完整性和結構師 261
開發第二個係統所引起的後果—— 盲目的功能和頻率猜測 263
圖形界麵的成功 265
沒有構建捨棄原型—— 瀑布模型是錯誤的 269
增量開發模型更佳—— 漸進地精化 272
關於信息隱藏，Parnas是正確的，我是錯誤的 276
人月到底有多少神話色彩？Boehm的模型和數據 278
人就是一切(或者說，幾乎是一切) 280
放棄權力的力量 281
最令人驚訝的新事物是什麼？數百萬的計算機 283
全新的軟件産業—— 塑料薄膜包裝的成品軟件 286
買來開發—— 使用塑料包裝的成品軟件包作為構件 288
軟件工程的狀態和未來 290
結束語：令人嚮往、激動人心和充滿樂趣的50年 293
注解與參考文獻 295
附錄：人月落地實戰體驗 315
一、名傢談人月 317
1. 年金 317
2. 《人月神話》與實踐 318
3. Frank Chance評人月 327
4. 軟件尚方寶劍(Silver Bullet)何在 330
二、名著評人月 339
三、讀者感言 351
1. 讀書有感——人月神話 351
2. 我這幾天很煩(産品概念完整性) 353
3. 關於我們的思考——“項目開發”及讀《人月神話》有感 355
4. 我的“人月神話” 358
5. 《人月神話》軟玉生香 360
· · · · · · (收起)
讀後感
书中的一些技术细节读起来比较费力，我更多地是从“项目管理”的角度来阅读此书。 【1】缺乏合理的时间进度是造成项目滞后的最主要原因。 【2】通常，我们会过于乐观，错误地假设“一切都将运作良好，每项任务仅花费它所应该花费的时间”。 【3】在估计和进度安排中常常使用...
評分程序员，就像诗人一样，几乎仅仅工作在单纯的思考中。他们运用自己的想象，来建造自己的“城堡”。——这句话我非常喜欢，作为我blog的说明。 用了12个人月看完人月神话，断断续续。这本书的软件开发背景，和现在大部分程序员应用开发的背景大不相同，也和现在快速开发方法工...
評分其实已经读过汉译版了，不过还是对中文的翻译信不过，还想再读一遍原版。看过这本书让我对软件有了一个全新的认识，颠覆了我以前的很多幼稚的想法，实在是一本好书，我想我会读很多遍的。
評分用戶評價
人總是高估自己、低估睏難。軟件工程很大一部分精力花費在解決bug上。就好像教皇一開始以為青銅聖鬥士就能解決雅典娜領導的五小強，但是沒想到對手的難纏程度是會隨著項目的進行不斷成長的，導緻後來不斷增加人手，白銀、黃金聖鬥士甚至教皇本人都搞不定瞭。其實作者提齣的解決辦法也是一開始就由主帥和副手把控項目骨架，再派精兵強將去快速解決那些將來可能會耗費很多精力的小問題，所謂殺雞用牛刀。還有就是把開發版本中遇到的問題和修改都文檔化，便於其他人學習交流。軟件工程的協同工作和軍事行動很像。
评分配閤《大教堂與集市》閱讀。
评分缺乏閤理的時間進度是造成項目滯後的主要原因。人月暗示瞭人員數量和時間是可以相互替換的，混淆瞭工作量和項目進展。進度安排是1/3計劃、1/6編碼、1/4構件測試以及1/4係統測試。為進度落後的項目增加人員隻會拖後進度（任務重新分配、培訓新人員、額外的溝通）。首席程序員帶領一個外科手術隊伍、小型精乾的團隊是最好的，少數結構師保證瞭産品的概念完整性（係統設計最重要的因素），其他協助人員保證瞭生産率，概念統一能加快開發和測試，體係結構、設計實現和物理實現的工具可以並行。項目會失敗的首要原因是缺乏網狀的交流和協作，必須進行人力和職責劃分。軟件項目要明確目標、用戶手冊、內部文檔、進度、預算、規模組織結構和工作空間分配。沒有銀彈=沒有任何單獨的軟件工程進展可以使軟件生産率有數量級的提高。SY
评分翻譯太差
评分翻譯太差
相關圖書
本站所有內容均為互聯網搜索引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2025 book.quotespace.org All Rights Reserved. 小美書屋 版权所有