人月神話（注釋版）

Chapter 1　The Tar Pit　3
Chapter 2　The Mythical Man-Month　13
Chapter 3　The Surgical Team　29
Chapter 4　Aristocracy, Democracy, and System Design　41
Chapter 5　The Second-System Effect　53
Chapter 6　Passing the Word　61
Chapter 7　Why Did the Tower of Babel Fail?　73
Chapter 8　Calling the Shot　87
Chapter 9　Ten Pounds in a Five-Pound Sack　97
Chapter 10　The Documentary Hypothesis　107
Chapter 11　Plan to Throw One Away　115
Chapter 12　Sharp Tools　127
Chapter 13　The Whole and the Parts　141
Chapter 14　Hatching a Catastrophe　153
Chapter 15　The Other Face　163
Chapter 16　No Silver Bullet——Essence and Accident　179
Chapter 17　“No Silver Bullet” Refired　207
Chapter 18　Propositions of The Mythical Man-Month: True or False?　229
Chapter 19　The Mythical Man-Month after 20 Years　253
Epilogue　291
Notes and References　293
Index　309

中文目錄
第1章　焦油坑　3
　　史前時代的焦油坑吞噬了成千上萬個力大無窮的巨獸，今天的大型軟件項目則令無數(shù)龐大的開發(fā)團隊陷入無從逃脫的窘境。軟件程序依其規(guī)模和目標的不同，對開放過程的要求也有極大的不同，這給軟件開發(fā)這一職業(yè)帶來無窮樂趣，同時也是這一行業(yè)苦惱的根源。
第2章　人月神話　13
　　軟件開發(fā)項目常以人月來衡量工作量，這種度量暗示著人手和時間是可以互換的。這種“人多力量大”的想法是一種一廂情愿的虛妄神話，Brooks法則：向滯后的軟件項目追加人手會使得進度更遲緩。自本書第1版出版以來，這一法則在軟件業(yè)廣為傳誦。
第3章　外科手術團隊　29
　　雖然優(yōu)秀的程序員的工作效率往往數(shù)倍于平庸的程序員，但若是缺乏合理的配置，優(yōu)秀的成員未必能構成優(yōu)秀的團隊。大型軟件開發(fā)項目的團隊需要和外科手術組一樣妥善分工，各司其職協(xié)調配合。
第4章　元老制、民主制和系統(tǒng)設計　41
　　概念完整性是系統(tǒng)設計中最重要的因素，尤其對于大型軟件系統(tǒng)來說，概念完整性是項目順利完成的必要保障。為獲得概念完整性，架構設計由精簡的架構設計小組負責，具體實現(xiàn)則圍繞核心概念展開。架構設計和具體實現(xiàn)既相分離，又相輔相成。
第5章　第二個系統(tǒng)效應　53
　　人們在第一個系統(tǒng)成功完成后，往往會在開發(fā)后續(xù)的第二個系統(tǒng)時犯冒進的錯誤。第二個系統(tǒng)經(jīng)常成為過度設計或畫蛇添足的犧牲品。要避免這種錯誤，必須在第二個系統(tǒng)開發(fā)時審慎地考查技術環(huán)境的變化，廣泛進行交流和溝通，聆聽各方面的建議，確立嚴謹?shù)墓浪愫鸵?guī)劃。
第6章　溝通順暢　61
　　架構設計通常由核心設計小組完成，將設計概念傳達到整個開發(fā)團隊是貫徹概念完整性的必然要求。以System 360的開發(fā)經(jīng)驗為例，要貫徹概念完整性，需要在團隊中保持良好順暢的溝通和交流，采用形式化定義等技術可以確保概念被精確地定義和傳達。獨立的測試小組是系統(tǒng)質量的良好保證。
第7章　巴別塔為何失敗　73
　　如果缺乏良好有效的溝通和協(xié)作，成員間難以有效地配合，團隊項目的目標就無法實現(xiàn)。清晰的工作文檔，明確的組織結構，合理的職責分配，都是大型軟件項目最終成功的保證。
第8章　掌控之中　87
　　對大型軟件系統(tǒng)產(chǎn)品的開發(fā)所需的時間和資源進行準確地估測，能讓我們對項目進度和前景胸有成竹。軟件代碼的開發(fā)效率和代碼模塊之間所需的交互相關。界面交互復雜的程序需要更多的測試和調試時間，單純地增加人手并不能有助于開發(fā)效率的提高。
第9章　袖里乾坤　97
　　最大化資源利用率，減少不必要的資源占用，合理規(guī)劃，使軟件系統(tǒng)在資源有限的情況下依然保證良好的性能，從而實現(xiàn)良好的可伸縮性和健壯性，這能體現(xiàn)軟件開發(fā)人員精湛的設計技巧。巧妙的數(shù)據(jù)結構往往能大幅度地儉省資源耗費，提高系統(tǒng)運行的性能。
第10章　文檔先行　107
　　在軟件項目開發(fā)過程中，文檔是不可或缺的，文檔為整個團隊規(guī)范了概念，以便于團隊中的溝通協(xié)作以及進度校驗。本章闡述了軟件系統(tǒng)項目中至關重要的幾類文檔，這些關鍵文檔應及時地更新，始終作為項目進展的有效指南。
第11章　準備拋棄　115
　　變化是永恒的，用戶的需求和期望在變化，開發(fā)者對用戶需求的理解在變化，適用的技術也在變化，故而最佳的解決策略也可隨之變化。軟件開發(fā)團隊應靈活地配置人力和資源，適應開發(fā)過程中的種種問題。程序的復雜性、用戶需求的不確定性、軟硬件技術環(huán)境的發(fā)展等因素導致了軟件維護工作并非總是能夠百分之百地獲得回報。
第12章　良工利器　127
　　軟件開發(fā)項目所選擇的技術和工具對保障項目能否令人滿意地如期完成至關重要。合適的開發(fā)工具、評測技術能有事半功倍之效果，切于實用的工具和技術是項目團隊的重要財富。本章提供了當年軟件開發(fā)項目選擇技術和工具的重要原則和建議。
第13章　整體和局部　141
　　大而無當?shù)幕\統(tǒng)見地并不能表現(xiàn)你真正地理解了一個軟件系統(tǒng)，應該具體而系統(tǒng)地深入了解各個局部的技術。良好的自頂向下的設計，不僅能保證概念完整性，也能及早消滅許多隱患。應及早在軟件項目中引入測試，錯誤發(fā)現(xiàn)得越早，修復錯誤的代價就越小。
第14章　潛伏的禍患　153
　　項目進度的滯后經(jīng)常源自不易察覺的點滴延誤的累積。軟件項目的經(jīng)理應該盡量建立可以明確量化的階段性目標，定期進行嚴謹而規(guī)范的項目階段性驗收，了解項目的進展狀況，并及時進行計劃、資源和人力的調整。關鍵路徑圖等技術有助于觀察項目的進度。
第15章　另一面　163
　　雖然用戶直接使用軟件系統(tǒng)，但在許多應用領域中，用戶不可能僅僅憑借與軟件的直接交互就迅速掌握其所有功能。故而提供給用戶的使用說明等文檔是軟件呈現(xiàn)給用戶的另外一面，它也能直接影響用戶對軟件的滿意度和可用性評價。文檔的用途決定它的形式和內(nèi)容。
第16章　沒有銀彈——軟件工程的必然和偶然　179
　　本文最初發(fā)表于1985年的IFIP第十屆世界計算機大會上，此時距《人月神話》初版發(fā)行已有10年，其間計算機技術領域的變化令人振奮。但作者在此提出，由于軟件的復雜性、一致性、變化性和不可見性，解決軟件危機的銀彈并不存在。作者點評了20世紀80年代前期被業(yè)界寄予厚望的一些新技術，討論了它們在克服軟件危機中所具備的優(yōu)勢和缺憾。作者預言在近十年內(nèi)，沒有任何單獨的軟件工程進展可以使軟件生產(chǎn)率有數(shù)量級的提高。
第17章　再議“沒有銀彈”　207
　　相比《人月神話》初版而言，1986年發(fā)表的“沒有銀彈”(第16章)發(fā)表后引發(fā)了熱烈的爭論，本章結合20世紀80年代后期到90年代前期之間軟件復用、面向對象程序開發(fā)等新技術的發(fā)展狀況，回應了對《沒有銀彈》一文的各種主要異議，認為由于《沒有銀彈》一文歸納的軟件的幾大特性，人們期待中的重大突破不可能在近期內(nèi)到來。
第18章　人月神話中的提議：是耶非耶　229
　　在撰寫《人月神話》的回顧和更新過程中，作者發(fā)現(xiàn)初版中斷言的觀點甚少被軟件工程研究和實踐所抨擊、證實或證偽，因此在本章中作者提煉了初版中15個章節(jié)中的概要，結合近年來軟件技術的發(fā)展狀況，對這些觀點進行強調、修正和反思。
第19章　人月神話二十年　253
　　在《人月神話》初版發(fā)布二十周年后，計算機技術領域已有很大變化，《人月神話》體現(xiàn)出深遠的影響力，初版中的許多觀點依然經(jīng)常被人們談論和引用，其中有些斷言至今仍被軟件開發(fā)人員奉為圭臬。作者結合當前軟件工程領域的發(fā)展現(xiàn)狀重新梳理了初版中的各核心觀點，強調了概念完整性，重新評議了第二個系統(tǒng)效應，反省了瀑布模型的局限性。結合初版中的觀點，作者評述了圖形桌面系統(tǒng)、信息隱藏、面向對象高級語言等技術的發(fā)展，以及近年來軟件工程領域的重要成果。
跋　291
注解與參考文獻　293
索引　309