人月神話：軟體專案管理之道（20週年紀念版） pdf epub mobi txt 电子书 下载 2025

• 軟件工程
• 項目管理
• 軟件開發
• 團隊協作
• 軟件質量
• 人月神話
• 經典
• 技術管理
• 軟件項目
• Brooks's Law

有些書，對於讀者和作者就像是年金一樣，可以年年分紅。《人月神話》就是這樣一本書……年輕的軟體工程師、缺錢的研究生、懶惰的程式設計老手，常常問我哪一本電腦書是最好的。「如果我被睏在一個荒島上，隻能帶一本電腦書，」他們問，「應該是哪一本？」這問題很荒謬，但是他們堅持要答案。假如你真的被放逐到這樣的小島上，應該陪伴你的是《人月神話》。
　　　　　　　　　　　　　　　　　　　　　　　　－－Ed Yourdon，軟體界知名顧問與作傢

我唯一一本讀過一遍以上的計算機相關書籍，是Fred Brooks的《人月神話》，事實上我每隔幾年都會重讀其中的某些章節。一部分原因是這本書文筆很好，而且書中的忠告很有價值，即使是在這本書齣版瞭超過25年之後。當然，現在在很多細節上，還有我們做事的方法都不一樣瞭，我們的工作更自動化，電腦的「馬力」也更強瞭，但書中依然有非常多很好的忠告。我非常推崇這本書，這是我唯一覺得你能從中體會到樂趣和思想的計算機科學書籍。－－Brian Kernighan，The C Programming Language作者

　　很少有一本軟體專案管理的書，像《人月神話》這樣深具影響力而且曆久不衰，Fred Brooks以軟體工程上的實例，搭配發人深省的評論，為如何管理大型、復雜專案提供瞭精闢的見解。他曾經擔任過IBM System/360電腦係列，以及與之搭配的OS/360這種大型軟體係統的專案經理，書中文章即取材自他擔任這些職務的實際經驗。在這本書首次齣版二十年後，作者對他當初所提齣的理念做瞭一番迴顧，並加入瞭新的思維與建議，獻給對這本書已經熟悉的讀者，以及第一次接觸這本書的人。

　　二十週年紀念版新增的章節包括：（１）將本書初版中所主張的所有論斷整理齣一個簡潔的摘要，包括瞭原書的主要理念：就人力配置的比例而言，大型軟體專案所麵臨的是跟小型專案完全不同的管理問題，這引申齣産品的概念整體性是其中的關鍵，而達成概念整體性雖然睏難，但卻是可能辦到的；（２）作者對他當初所提齣的這些論斷，在經過一個世代之後所做的觀察；（３）轉載他1986年發錶於IEEE Computer的經典論文〈沒有銀彈〉；以及（４）他對於他1986年的論斷「十年內不會有任何銀彈」所做的迴應。

　　1975年齣版的《人月神話》是軟體開發方麵的經典之作。近三十年來，這本書能在技術日新月異的計算機領域持續受到歡迎，正是因為它不僅是技術性的書籍，還包括要開發一個大型係統所應注意的管理層麵問題，這使得本書涵蓋軟體、管理的層次，而經得起考驗。如果您從事程式設計工作，或是和程式設計者共事，或負責軟體專案的管理，甚至如果您是IT産業的領導者，您都應該閱讀這本書。

作者簡介
　　Frederick P. Brooks, Jr.任教於北卡羅萊納大學Chapel Hill分校，擔任計算機科學的Kenan講座教授。由於他在IBM System/360開發階段擔任專案經理一職，遂以「IBM System/360之父」聞名於世，隨後擔任過OS/360設計階段的軟體專案經理，為此，他與Bob Evans、Erich Bloch共同獲頒瞭1985年國傢科技成就奬的殊榮，在此之前，還曾經是IBM Stretch和Harvest電腦的架構設計師。1999年，他獲頒美國計算機協會（ACM）的圖靈奬（A. M. Turing Award），這是在計算機領域中最具權威性的技術奬項，美國計算機協會盛贊他「對計算機結構、作業係統和軟體工程做齣瞭劃時代的貢獻」。
　　Brooks博士在Chapel Hill分校創建瞭計算機科學係，並自1964至1984年間擔任該係的係主任，也曾任職於國傢科學委員會和國防科學委員會。目前，他所從事的是計算機結構（computer architecture）、分子模型繪圖（molecular graphic），以及虛擬環境（virtual environment）方麵的教學和研究。

譯者簡介
　　錢一一，1968年生，中正理工學院電子工程碩士，目前任職於中山科學研究院，從事大型係統的軟體架構設計工作。《人月神話》是他的第一本譯作。

二十週年紀念版序
初版序

• 第1章焦油坑
• 第2章人月神話
• 第3章外科手術團隊
• 第4章專製、民主與係統設計
• 第5章第二係統效應
• 第6章意念的傳達
• 第7章巴彆塔為什麼失敗？
• 第8章預估
• 第9章地盡其利，物盡其用
• 第10章文件假說
• 第11章失敗為成功之母
• 第12章神兵利器
• 第13章化整為零
• 第14章釀成大災難
• 第15章一體兩麵
• 第16章沒有銀彈——軟體工程的本質性與附屬性工作
• 第17章再論「沒有銀彈」
• 第18章《人月神話》的主張：是真是假？
• 第19章《人月神話》20年

後記

註解與參考資料

索引

譯後記

〔推薦序一〕

大型復雜係統的創新管理經驗與智慧

李仁芳

颱灣不缺創新人纔，供給嚴重不足的是創新管理人纔。
我們有世界級的電影導演，但優秀的製作人(Producer)鳳毛麟角。
我們有個人擁有上百個專利的科技怪傑，但很難找到能經營企業研究中心(Corporate Lab)的技術長。
我們也有能寫優美程式的駭客級好手，但能管理一個大型復雜軟體係統開發的專案管理者則遍尋不著。
科技的創新與美學的創新，半靠天份，半靠後天的專注與努力﹔
但是創新專案的管理，特彆是大型復雜係統創新的管理，其綜覽全局的眼光與對係統産品概念的整體性(Conceptual integrity)的掌控，則非仰賴蓄積的經驗厚度不可。
這種對大型復雜係統創新的管理經驗紋路與智慧奧義非常內隱，很少被彰顯齣來。
微軟公司近年來非常重視新産品開發專案開發完成後的「專案稽核」(Project Audit)文件，強製要求未完成此文件的專案領導人不得結案交差。比爾．蓋茲的用意即在藉這些文件，讓復雜軟體開發的管理經驗得以在微軟內部流通，增益後來的微軟産品創新管理成效。
System/360與OS/360是人類軟體工程技術開發史上非常重要的裏程碑，不論在技術成就或商業績效上，都是使IBM公司成為「大藍」(The Big Blue)的關鍵産品。
本書的作者Frederick P. Brooks, Jr.與另一要角Bob Evans（TSMC張忠謀先生好友，曾任行政院孫前院長的科技顧問及世界先進公司總經理）當年即為IBM此大型復雜係統專案的兩位主導人。
他們為System/360規劃瞭一係列不同的機型：Model 20、Model 30、Model 40、Model 50、Model 60、Model 62、Model 67……等等。
OS/360的創新開發，尖峰時期曾超過1,000人為之工作－－程式設計師、文件編寫員、機器操作員、助理、秘書、經理、支援小組等。從1963到1966年間，大約有5,000個人年（man-year）的工作量是投入到OS/360係統的設計、建構和文件撰寫工作。
雖然從效能最初階、最便宜到效能最佳、最貴多重等級都有，但這些機型的外觀係統都一樣，操作方式也彼此相容，隻是內部的實作方式按等級做瞭調整。客戶可以視需要與預算來選擇適當的機型，而且拜單一架構之賜，使用者介麵不需改變。因此客戶未來因業務成長想要升級時，門檻也很低——這是當時System/360一個很大的軟體工程技術成就與商業賣點。
Brooks的《人月神話》是記述人類工程史上一項裏程碑式的大型復雜軟體係統開發經驗的「創新管理」經典之作。
書中揭示瞭許多大型復雜係統創新管理的經驗紋路與智慧奧義，是為有誌於追求創新專案之管理專業人士參考。
創新管理是一極具「領域專屬」(Domain-Specific)特質的知識與技能。
管理大型復雜軟體專案的開發，與管理其他任何大型的專案(登月計畫、隱形轟炸機開發、局端交換機係統開發……)相比，類似的地方固然很多－－比大部分程式設計師所相信的還要多。
然而，管理大型復雜軟體專案的開發，與其他領域大型專案不同的地方也很多－－比大部分的專案經理所預料的還要多。
程式的創作必須呈現得非常完美，就像哈利波特要施展魔法一樣，咒文中的一個字或一個停頓，隻要稍有差池，魔法就施不齣來。
人類並不習慣做到這麼完美，人類的活動也很少需要做到這麼完美－－而調適自我及團隊成員習於追求完美是軟體工程創新管理最睏難的部分。
這種極緻追求完美的大型復雜係統創新管理經驗，是人類智慧寶藏中極為重要、極為寶貴的一個環節，值得看重創新管理的人士仔細咀嚼。
Brooks以內行人的經驗深度與形象化深入淺齣的語言，對這段智慧寶藏做齣瞭貢獻。
他所稱的：
‧ （新係統）概念整體性（Conceptual Integrity）；
‧ 外科手術團隊；
約束對（軟體工程開發）藝術而言是件好事（Discipline is good for art）；
形式就是解放（Form is liberating）；
架構（architecture）的外部規格製定齣來，事實上反而會增加實作小組創意風格，而非貶損；
架構設計師和實作人員越早進行持續性、充分、仔細而和諧的溝通，可以使架構設計師具有良好的成本概念，而實作人員也會對設計更有信心，不會模糊瞭各自的分工；
巴彆塔的失敗不是因為缺乏明確的目標與充沛的資源與技術，而是因為溝通（communication）以及隨之而來的組織（organization）問題！
這些創新管理的深刻經驗與見解，不隻對大型軟體開發的管理十分寶貴，對其他領域的復雜係統之創新管理，也極具參考價值。
像Brooks具備這種經驗厚度的人，寫齣《人月神話》這樣的書，是人類知能纍積過程中極大的福氣。社會應多鼓勵有這樣成就的人士多寫齣類似的著作來。

（本文作者為政治大學科技管理研究所教授兼所長）

　　實在是令我感到驚訝與喜悅，二十年來《人月神話》一直如此受到歡迎，齣版瞭超過25萬本。人們常常問我，當初在1975年所提齣的理念與建議，有哪些仍然是為我所堅持的，有哪些則是已經改變，以及是如何改變的。雖然我有時會在演講中迴應這些問題，但其實很早就想把它寫下來瞭。

　　任職於Addison-Wesley公司的齣版夥伴Peter Gordon，他從1980年起就跟我一起共事，很有耐心、對我幫助很大；他提議來齣個紀念版，我們決定不重新修訂原文，一字不改地再版（除非是一些小的錯誤改正），然後以更現代的想法來擴增其內容。

　　第16章是轉載自1986年在IFIPS發錶的文章〈沒有銀彈：軟體工程的本質性與附屬性工作〉，這篇文章醞釀自我所主持的一項國防科學委員會對軍用軟體研究的經驗，參與那項研究的工作夥伴，也就是我們的執行祕書Robert L. Patrick，是他促使我重新接觸實務上的大型軟體專案，這份經驗相當珍貴。這篇文章在1987年曾經轉載於IEEE《Computer》雜誌上，因而使這篇文章得以廣為流傳。

　　事實證明〈沒有銀彈〉相當具爭議性，它預測十年內不會有任何軟體開發的技術能夠單獨帶給軟體生産力一個數量級的提升，這十年還有一年就要期滿瞭，看來我的預言應該是會應驗。在文獻上，〈沒有銀彈〉已經比《人月神話》引發瞭更多熱烈的討論，所以，第17章是針對一些齣現過的評論所做的註解，並且更新瞭在1986年所提齣的那些理念。

　　在為《人月神話》的迴顧與更新做準備的同時，我突然想到，當年所做的論斷有多少引發瞭爭論、有多少通過瞭驗證、有多少已因軟體工程上持續的研究與經驗而證明是錯誤的呢？剝除掉原來所支持的理由與資料，將這些論斷做一個赤裸裸的分類，現在，已證明瞭這麼做對我是有所助益的，期望這些不加任何掩飾的陳述能夠鼓勵大傢藉由評論與事實來對這些論斷加以驗證、舉齣反證、更新、或粹煉，而這些綱要，我放在第18章。

　　第19章是屬於最新資訊的短文，先跟讀者聲明，這一章所談到的最新評論並不像初版書中的評論都經過瞭實務經驗的確認，我個人已經脫離業界，並在大學裏教瞭好一陣子書，所接觸到的都是小案子，不再是大型專案，自1986年以來，我隻教授軟體工程的課程，並沒有進行相關的研究工作，我所研究的部分僅限於虛擬環境的領域及其應用方麵。

　　在為這本書的迴顧所做的準備過程中，我曾經嚮一些仍在軟體工程界工作的朋友們請教一些屬於當代的觀點，他們很樂意地分享這些觀點，並在文稿上提齣創見性的評語，以及對我的再教育，這份熱心是值得贊揚的，這方麵讓我受惠的有Barry Boehm、Ken Brooks、Dick Case、James Coggins、Tom DeMarco、Jim McCarthy、David Parnas、Earl Wheeler和Edward Yourdon。而新章節在技術麵的製作則得力於Fay Ward高水準的經營。

　　感謝我在國防科學委員會軍用軟體專案小組的同事Gordon Bell、Bruce Buchanan、Rick Hayes-Roth，特彆是David Parnas，他們提供瞭深入的見解與激發創意的構想，而第16章的那篇文章在技術麵的製作則是得力於Rebekah Bierly。因分析軟體問題而引齣本質性（essence）與附屬性（accident）工作的分類，靈感是得自於Nancy Greenwood Brooks，她在一篇談鈴木小提琴教學的文章中使用這種分析方式。

　　按照Addison-Wesley的齣版慣例，並不允許我在這篇序言中嚮1975年初版的一些關鍵人物緻謝，但是有兩個人的貢獻是應當要提齣來的：Norman Stanton，當時的執行編輯；以及Herbert Boes，當時的美術指導。這本書的典雅風格是由Boes一手精心創造齣來的，其中有一位審稿人還特彆贊揚：「寬闊的書頁邊緣，〔與〕富涵創造力的字體運用和版麵配置」，更重要的，就是他提齣瞭每一章都用一幅圖做為開場的重大建議（當時，我手上隻有焦油坑和Reims大教堂的圖），為瞭找這些圖片還額外多花瞭我一年的時間，但我永遠感激他所提齣的這個構想。

　　Soli Deo gloria── 感謝老天。