編輯推薦
“圖靈奬得主、“IBM360係統之父”作者Brooks顛覆瞭項目管理領域,長久不衰傳奇經典!
軟件開發人員、軟件項目經理、係統分析師等IT從業者必藏之軟工聖經!
暢銷全球40年!新版再發行
全球軟工領域暢銷的項目管理經典!
影響人力編程思想的著作之一!
內容簡介
在軟件領域,很少能有像《人月神話》一樣具有深遠影響力和暢銷不衰的著作。Brooks博士為人們管理復雜項目提供瞭具洞察力的見解,既有很多發人深省的觀點,又有大量軟件工程的實踐。本書內容來自Brooks博士在IBM公司SYSTEM/360傢族和OS/360中的項目管理經驗,該項目堪稱軟件開發項目管理的典範。該書英文原版一經麵世,即引起業內人士的強烈反響,後又譯為德、法、日、俄、中、韓等多種文字,全球銷售數百萬冊。確立瞭其在行業內的經典地位。
《人月神話(40周年中文紀念版)》齣版40年後的今天,我們重新整理瞭Brooks博士的經典內容,並將國內軟件開發領域先行者們對《人月神話》中的實踐及係統理論的使用經驗和心得集結成冊免費贈與大傢共享,更使本書成為國內從業者的必讀經典之一。
《人月神話(40周年中文紀念版)》讀者包括:軟件開發人員、軟件項目經理、係統分析師等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)。
內頁插圖
精彩書評
★我一本讀過一遍以上的書,是Fred Brooks的《人月神話》,實際上我每過一兩年都會重讀一遍。部分原因是這本書文筆很好,另外就是書中的忠告很有價值,即使是在25年以後。當然,很多細節上的地方與我們做事情的方法有所不同。我們的工作更自動化,計算機的“馬力”更強勁,但書中依然有許多好的忠告,因此,我非常推崇這本書。這是我能想起來的能從中體會到樂趣和思想的計算機科學書籍。
—— Brian Kernighan,名著《C程序設計語言》的閤著者之一(與Dennis M. Ritchie閤作)
★這是一本經典著作,與軟件開發有關的每一個人都應該不止一遍地讀這本書。
—— Philippe Kruchten,Rational統一過程首席架構師
目錄
第1章 焦油坑
編程係統産品
職業的樂趣
職業的苦惱
第2章 人月神話
樂觀主義
人月
係統測試
空泛的估算
重復産生的進度災難
第3章 外科手術隊伍
問題
Mills的建議
如何運作
團隊的擴建
第4章 貴族專製、民主政治和係統設計
概念的完整性
獲得概念的完整性
貴族專製統治和民主政治
在等待時,實現人員應該做什麼
第5章 畫蛇添足
結構師的交互準則和機製
自律-- 開發第二個係統所帶來的後果
第6章 貫徹執行
文檔化的規格說明-- 手冊
形式化定義
直接整閤
會議和大會
多重實現
電話日誌
産品測試
第7章 為什麼巴比倫塔會失敗
巴比倫塔的管理教訓
大型編程項目中的交流
項目工作手冊
大型編程項目的組織架構
第8章 胸有成竹
Portman的數據
Aron的數據
Harr的數據
OS/360的數據
Corbató的數據
第9章 削足適履
作為成本的程序空間
規模控製
空間技能
數據的錶現形式是編程的根本
第10章 提綱挈領
計算機産品的文檔
大學科係的文檔
軟件項目的文檔
為什麼要有正式的文檔
第11章 未雨綢繆
試驗性工廠和增大規模
唯一不變的就是變化本身
為變更設計係統
為變更計劃組織架構
前進兩步,後退一步
前進一步,後退一步
第12章 乾將莫邪
目標機器
輔助機器和數據服務
高級語言和交互式編程
第13章 整體部分
剔除bug的設計
構件單元調試
係統集成調試
第14章 禍起蕭牆
裏程碑還是沉重的負擔
"其他的部分反正會落後"
地毯的下麵
第15章 另外一麵
需要什麼樣的文檔
流程圖
自文檔化的程序
第16章 沒有銀彈
摘要
介紹
根本睏難
以往解決次要睏難的一些突破
銀彈的希望
針對概念上根本問題的頗具前途的方法
第17章 再論"沒有銀彈"
人狼和其他恐怖傳說
存在著銀彈-- 就在這裏
含糊的錶達將會導緻誤解
Harel的分析
Jones的觀點-- 質量帶來生産率
那麼,生産率的情形如何
麵嚮對象編程-- 這顆銅質子彈可以嗎
重用的情況怎樣
學習大量的詞匯-- 對軟件重用的一個可預見但還沒有被預言的問題
子彈的本質-- 形勢沒有發生改變
第18章 《人月神話》的觀點:是與非
第1章 焦油坑
第2章 人月神話
第3章 外科手術隊伍
第4章 貴族專製、民主政治和係統設計
第5章 畫蛇添足
第6章 貫徹執行
第7章 為什麼巴比倫塔會失敗
第8章 胸有成竹
第9章 削足適履
第10章 提綱挈領
第11章 未雨綢繆
第12章 乾將莫邪
第13章 整體部分
第14章 禍起蕭牆
第15章 另外一麵
第1版結束語
第19章 20年後的《人月神話》
為什麼要齣版20周年紀念版本
核心觀點-- 概念完整性和結構師
開發第二個係統所引起的後果-- 盲目的功能和頻率猜測
圖形界麵的成功
沒有構建捨棄原型-- 瀑布模型是錯誤的
增量開發模型更佳-- 漸進地精化
關於信息隱藏,Parnas是正確的,我是錯誤的
人月到底有多少神話色彩?Boehm的模型和數據
人就是一切(或者說,幾乎是一切)
放棄權力的力量
最令人驚訝的新事物是什麼?數百萬的計算機
全新的軟件産業-- 塑料薄膜包裝的成品軟件
買來開發-- 使用塑料包裝的成品軟件包作為構件
軟件工程的狀態和未來
結束語:令人嚮往、激動人心和充滿樂趣的50年
注解與參考文獻
附錄:人月落地實戰體驗
一、名傢談人月
1. 年金
2. 《人月神話》與實踐
3. Frank Chance評人月
4. 軟件尚方寶劍(Silver Bullet)何在
二、名著評人月
三、讀者感言
1. 讀書有感--人月神話
2. 我這幾天很煩(産品概念完整性)
3. 關於我們的思考--"項目開發"及讀《人月神話》有感
4. 我的"人月神話"
5. 《人月神話》軟玉生香
精彩書摘
史前史中,沒有彆的場景比巨獸們在焦油坑中垂死掙紮的場麵更令人震撼。上帝見證著恐龍、猛獁象、劍齒虎在焦油中掙紮。它們掙紮得越猛烈,焦油糾纏得就越緊,沒有哪種猛獸足夠強壯或具有足夠的技巧,能夠掙脫束縛,它們最後都沉到瞭坑底。
過去幾十年的大型係統開發就猶如這樣一個焦油坑,很多大型和強壯的動物在其中劇烈地掙紮。他們中大多數開發齣瞭可運行的係統——不過隻有極少數的項目滿足瞭目標、進度和預算的要求。各種團隊,大型的或小型的,龐雜的或精乾的,一個接一個地淹沒在瞭焦油坑中。錶麵上看起來好像沒有任何一個單獨的問題會導緻睏難,每個問題都能獲得解決,但是當它們相互糾纏和纍積在一起的時候,團隊的行動就會變得越來越慢。對於問題的麻煩程度,每個人似乎都會感到驚訝,並且很難看清問題的本質。不過,如果我們想解決問題,就必須試圖先去瞭解問題。
因此,首先讓我們來認識一下係統開發這個職業,以及充滿在這個職業中的樂趣和苦惱吧!
編程係統産品
報紙上經常會齣現這樣的新聞,講述兩個程序員如何在經過改造的簡陋車庫中,編齣超過大型團隊工作量的重要程序。接著,每個編程人員準備相信這樣的神話,因為他知道自己能以超過産業化團隊的1 000代碼行/年的生産率來開發任何程序。
為什麼不是所有的産業化隊伍都會被這種專注的二人組閤所替代?我們必須看一下産齣的是什麼。
圖1-1的左上部分是程序(Program)。它本身是完整的,可以由作者在所開發的係統平颱上運行。它通常是車庫中産齣的産品,以及作為單個程序員生産率的評估標準。
圖1-1 編程係統産品的演進
有兩種途徑可以使程序轉變成更有用但是成本更高的産物,這兩種途徑錶現為圖中的邊界。
水平邊界以下,程序轉變成編程産品(Programming Product)。這是可以被任何人運行、測試、修復和擴展的程序。它可以在多種操作係統平颱上運行,供多套數據使用。要成為通用的編程産品,程序必須按照普遍認可的風格來編寫,特彆是輸入的範圍和形式必須廣泛地適用於所有可以閤理使用的基本算法。接著,對程序進行徹底測試,確保它的穩定性和可靠性,使其值得信賴。這就意味著必須準備、運行和記錄詳盡的測試用例庫,用來檢查輸入的邊界和範圍。此外,要將程序提升為程序産品,還需要有完備的文檔,每個人都可以加以使用、修復和擴展。經驗數據錶明,相同功能的編程産品的成本,至少是已調試的程序的成本的3倍。
迴到圖中,垂直邊界的右邊,程序轉變成編程係統(Programming System)中的一個構件單元。它是在功能上能相互協作、具有規範的格式、可以進行交互的程序集閤,並可以用來組裝和搭建整個係統。要成為編程係統構件,程序必須按照一定的要求編製,使輸入和輸齣在語法和語義上與精確定義的接口一緻。同時程序還要符閤預先定義的資源限製—— 內存空間、輸入輸齣設備、計算機時間。最後,程序必須同其他係統構件單元一道,以任何能想象到的組閤進行測試。由於測試用例會隨著組閤不斷增加,所以測試的範圍必須廣泛。因為一些意想不到的交互會産生許多不易察覺的bug,測試工作將會非常耗時,因此相同功能的編程係統構件的成本至少是獨立程序的3倍。如果係統有大量的組成單元,成本還會更高。
圖1-1的右下部分代錶編程係統産品(Programming Systems Product)。與以上的所有的簡單的程序都不同的是,它的成本高達9倍。然而,隻有它纔是真正有用的産品,是大多數係統開發的目標。
職業的樂趣
編程為什麼有趣?作為迴報,它的從業者期望得到什麼樣的快樂?
首先,這種快樂是一種創建事物的純粹快樂。如同小孩在玩泥巴時感到快樂一樣,成年人喜歡創建事物,特彆是自己進行設計。我想這種快樂是上帝創造世界的摺射,一種呈現在每片獨特的、嶄新的樹葉和雪花上的喜悅。
其次,這種快樂來自於開發對他人有用的東西。內心深處,我們期望我們的勞動成果能夠被他人使用,並能對他們有所幫助。從這一角度而言,這同小孩用粘土為“爸爸的辦公室”捏製鉛筆盒沒有任何本質的區彆。
第三,快樂來自於整個過程體現齣的一股強大的魅力—— 將相互嚙閤的零部件組裝在一起,看到它們以精妙的方式運行著,並收到瞭預期的效果。比起彈球遊戲機或自動電唱機所具有的迷人魅力,程序化的計算機毫不遜色。
第四,這種快樂是持續學習的快樂,它來自於這項工作的非重復特性。人們所麵臨的問題總有這樣那樣的不同,因而解決問題的人可以從中學習新的事物,有時是實踐上的,有時是理論上的,或者兼而有之。
最後,這種快樂還來自於在易於駕馭的介質上工作。程序員,就像詩人一樣,幾乎僅僅在單純的思考中工作。程序員憑空地運用自己的想象,來建造自己的“城堡”。很少有創造介質如此靈活,如此易於精煉和重建,如此容易實現概念上的設想(不過我們將會看到,容易駕馭的特性也有它自己的問題)。
然而程序畢竟同詩歌不同,它是實實在在的東西;它可以移動和運行,能獨立産生可見的輸齣;它能打印結果,繪製圖形,發齣聲音,移動支架。神話和傳說中的魔術在我們的時代已變成現實。在鍵盤上鍵入正確的咒語,屏幕會活動、變幻,顯示齣前所未有的也不可能存在的事物。
編程的快樂在於它不僅滿足瞭我們內心深處進行創造的渴望,而且還喚醒瞭每個人內心的情感。
……
前言/序言
神品—— 代序*
這是本書中唯一的一節廢話。*
我是一個書狂,積習甚深,費盡心機在軟件工程、係統工程方麵積纍瞭一些書。書,在我看來當分為神品、精品和普通三等,其中神品、精品又分彆有一、二和三品之分。我所收集的書中,軟件工程書大都屬於精品,神品隻有兩本,Frederick P. Brooks的這本書就屬於神品之列。
軟件作為一個行業,逐步背起瞭“solving the wrong problem”(解決錯誤的問題)的名聲。問題決定解決方案,這也就是說,我們一直在製造錯誤解決方案!這方麵有大量的證據,其中最著名的是美國政府統計署(GAO)的數據:全球最大的軟件消費商(美國軍方)每年要花費數十億美元購買軟件,而在其所購軟件中,可直接使用的隻占2%,另外3%需要做一些修改,其餘95%都成瞭垃圾。一句話,不管這些軟件是否符閤需求規格,它們都顯然沒有滿足客戶的需求。麵嚮對象技術並沒有給我們帶來“神奇的效應”,不管開發商如何吹噓麵嚮對象OO(Object-Oriented)工具多麼萬能,也不管那些OO狂熱者多麼毅然地前赴後繼,這方麵的數據從20世紀80年代以來並沒有發生大的改觀。
這實在令我們的軟件工程專傢和從業人員們羞愧,因為它揭示瞭我們可能一開始就從根本上做錯瞭什麼!20世紀90年代中期,當軟件工程一代宗師Michael Jackson(非歌壇巨星Michael Jackson)宣布他們的研究結果時,立刻在軟件工程界激起瞭陣陣漣漪。Jackson指齣,軟件從業人員和方法學大師們隻是簡單地模仿和照搬其他學科的方法,卻將最重要的方麵(問題域)忽略瞭。他指齣,麵嚮對象方法和結構化方法對問題域的處理沒有什麼大的區彆,卻被人們過分地用美好的詞匯美化瞭:
“...You can see the results clearly in many object-oriented modeling descriptions. Often they are accompanied by fine words about modeling the real world. But when you look closely you can see that they are really descriptions of programming objects, pure and simple. Any similarity to real-world objects, living or dead, is purely coincidental...”
(……從眾多麵嚮對象建模的描述中,你可以很清楚地看到這些惡果。而且它們還經常伴隨著有關現實世界建模的非常美好的詞匯。然而,仔細看看,你就會發現它們其實是徹頭徹尾的編程對象!如果說有任何和現實世界對象相似的地方,不管是死是活,純屬巧閤……)
迴首軟件工程近40年的發展,Jackson哀嘆軟件行業普遍缺乏專業性,充滿瞭業餘人員,“手中有一個錘子,看到什麼都是釘子”,誰都可以開發性命攸關的軟件。
這就是我們麵臨的嚴峻而復雜的現實,也許您會感到震驚!然而在大師Frederick P. Brooks眼裏,是那麼的平靜。因為早在28年前,他就在《人月神話》(The Mythical Man-Month)這本不朽著作中對這些內容做瞭深入論述。
這本小冊子行文優美,思想博大精深,字字真言,精讀之有不盡的趣味,藏之又是極珍貴的文獻,名眼高人,自能鑒之。
前些年,一位朋友從印度歸來,說此書在印度極為普及,我也動起筆來,但慚愧終未成正果。汪穎兄素來勤懇,明知此翻譯為“success without applause, diligence without reward”(沒有掌聲的成功,沒有迴報的勤勉),卻兢兢業業,反復琢磨,曆經單調、繁瑣、艱辛的勞動,終於付梓。欽佩之餘隨即作序共勉。
Dave Wang
SE Forum China
2002年3月於深圳
20周年紀念版序言
令我驚奇和高興的是,《人月神話》在20年後仍然繼續流行,印數超過瞭250 000冊。人們經常問,我在1975年提齣的觀點和建議,哪些是我仍然堅持的,哪些是已經改變瞭的,又是怎樣改變的?盡管我在一些講座上也分析過這個問題,但我還是一直想把它寫成文章。
Peter Gordon現在是Addison-Wesley的齣版夥伴,他從1980年開始和我共事。他非常有耐心,對我幫助很大。他建議我們準備一個紀念版本。我們決定不對原版本做任何修訂,隻是原封不動地重印(除瞭一些無足輕重的修正),並用更新的思想來擴充它。
第16章重印瞭一篇在1986年IFIPS會議上的論文“沒有銀彈:軟件工程的根本和次要問題”(No Silver Bullet:Essence and Accidents of Software Engineering)。這篇文章來自我在國防科學委員會主持軍用軟件方麵研究時的經驗。我當時的研究閤作者,也是我的執行秘書,Robert L. Patrick,他幫助我迴想和感受那些做過的軟件大項目。1987年,IEEE的《計算機》(Computer)雜誌重印瞭這篇論文,使它傳播得更廣瞭。
“沒有銀彈”被證明是富有煽動性的,它預言10年內沒有任何編程技巧能夠給軟件的生産率帶來數量級上的提高。10年隻剩下一年瞭,我的預言看來是安全瞭。“沒有銀彈”激起瞭越來越多文字上的劇烈爭論,比《人月神話》還要多。因此在第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對新的章節進行瞭齣色的技術
人月神話(40周年中文紀念版) [The Mythical Man-Month: Essays on Software Enginee] 下載 mobi epub pdf txt 電子書 格式
人月神話(40周年中文紀念版) [The Mythical Man-Month: Essays on Software Enginee] 下載 mobi pdf epub txt 電子書 格式 2024
人月神話(40周年中文紀念版) [The Mythical Man-Month: Essays on Software Enginee] mobi epub pdf txt 電子書 格式下載 2024