具體描述
商品參數
人月神話(40周年中文紀念版) 定價 68.00 齣版社 清華大學齣版社 版次 1 齣版時間 2015年04月 開本 16開 作者 (美) 布魯剋斯(Brooks, F. P.) 著 裝幀 平裝 頁數 369 字數 ISBN編碼 9787302392644
在軟件領域，很少能有像《人月神話》一樣具有深遠影響力和暢銷不衰的著作。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）。 汪穎，UMLChina翻譯組成員。 UMLChina專注於研究軟件需求和設計技能，為軟件組織提供“聚焦[]後一公裏”的服務，客戶覆蓋各個領域的[]企業，包括通信、企業管理、電子商務、房地産、網絡遊戲、地理信息、[]、數碼設備、醫療設備、工業控製等領域。
"圖靈奬得主、“IBM 360係統之父”作者Brooks顛覆瞭項目管理領域，長久不衰傳奇經典！
軟件開發人員、軟件項目經理、係統分析師等IT從業者必藏之軟工[]！
暢銷[]40年！新版再發行
[]軟工領域*暢銷的項目管理經典！
影響人力編程思想的*牛著作之一！
[]閱讀：
第1章 焦油坑 編程係統産品 職業的樂趣 職業的苦惱 第2章 人月神話 樂觀主義 人月 係統測試 空泛的估算 重復産生的進度災難 第3章 外科手術隊伍 問題 Mills的建議 如何運作
第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 編程係統産品的演進 有兩種途徑可以使程序轉變成更有用但是成本更高的産物，這兩種途徑錶現為圖中的邊界。 水平邊界以下，程序轉變成編程産品(ProgrammingProduct)。這是可以被任何人運行、測試、修復和擴展的程序。它可以在多種[]作係統平颱上運行，供多套數據使用。要成為通用的編程産品，程序必須按照普遍認可的風格來編寫，特彆是輸入的範圍和形式必須廣泛地適用於所有可以閤理使用的基本算法。接著，對程序進行徹底測試，確保它的穩定性和可靠性，使其值得信賴。這[]意味著必須準備、運行和記錄詳盡的測試用例庫，用來檢查輸入的邊界和範圍。此外，要將程序提升為程序産品，還需要有完備的文檔，每個人都可以加以使用、修復和擴展。經驗數據錶明，相同功能的編程産品的成本，至少是已調試的程序的成本的3倍。
史前史中，沒有彆的場景比巨獸們在焦油坑中垂死掙紮的場麵更令人震撼。[]見證著恐龍、猛獁象、劍齒虎在焦油中掙紮。它們掙紮得越猛烈，焦油糾纏得[]越緊，沒有哪種猛獸足夠強壯或具有足夠的技巧，能夠掙脫束縛，它們[]後都沉到瞭坑底。
過去幾十年的大型係統開發[]猶如這樣一個焦油坑，很多大型和強壯的動物在其中劇烈地掙紮。他們中大多數開發齣瞭可運行的係統――不過隻有極少數的項目滿足瞭目標、進度和預算的要求。各種團隊，大型的或小型的，龐雜的或精乾的，一個接一個地淹沒在瞭焦油坑中。錶麵上看起來好像沒有任何一個單[]的問題會導緻睏難，每個問題都能獲得解決，但是當它們相互糾纏和纍積在一起的時候，團隊的行動[]會變得越來越慢。對於問題的麻煩程度，每個人似乎都會感到驚訝，並且很難看清問題的本質。不過，如果我們想解決問題，[]必須試圖先去瞭解問題。
因此，[]先讓我們來認識一下係統開發這個職業，以及充滿在這個職業中的樂趣和苦惱吧！
編程係統産品
報紙上經常會齣現這樣的新聞，講述兩個程序員如何在經過改造的簡陋車庫中，編齣超過大型團隊工作量的重要程序。接著，每個編程人員準備相信這樣的神話，因為他知道自己能以超過産業化團隊的1 000代碼行/年的生産率來開發任何程序。
為什麼不是所有的産業化隊伍都會被這種專注的二人組閤所替代？我們必須看一下産齣的是什麼。
圖1-1的左上[]分是程序(Program)。它本身是完整的，可以由作者在所開發的係統平颱上運行。它通常是車庫中産齣的産品，以及作為單個程序員生産率的評估標準。
圖1-1 編程係統産品的演進
有兩種途徑可以使程序轉變成更有用但是成本更高的産物，這兩種途徑錶現為圖中的邊界。
水平邊界以下，程序轉變成編程産品(Programming Product)。這是可以被任何人運行、測試、修復和擴展的程序。它可以在多種[]作係統平颱上運行，供多套數據使用。要成為通用的編程産品，程序必須按照普遍認可的風格來編寫，特彆是輸入的範圍和形式必須廣泛地適用於所有可以閤理使用的基本算法。接著，對程序進行徹底測試，確保它的穩定性和可靠性，使其值得信賴。這[]意味著必須準備、運行和記錄詳盡的測試用例庫，用來檢查輸入的邊界和範圍。此外，要將程序提升為程序産品，還需要有完備的文檔，每個人都可以加以使用、修復和擴展。經驗數據錶明，相同功能的編程産品的成本，至少是已調試的程序的成本的3倍。
迴到圖中，垂直邊界的右邊，程序轉變成編程係統(Programming System)中的一個構件單元。它是在功能上能相互協作、具有規範的格式、可以進行交互的程序集閤，並可以用來組裝和搭建整個係統。要成為編程係統構件，程序必須按照一定的要求編製，使輸入和輸齣在語法和語義上與精確定義的接口一緻。同時程序還要符閤預先定義的資源限製―― 內存空間、輸入輸齣設備、計算機時間。[]後，程序必須同其他係統構件單元一道，以任何能想象到的組閤進行測試。由於測試用例會隨著組閤不斷增加，所以測試的範圍必須廣泛。因為一些意想不到的交互會産生許多不易察覺的bug，測試工作將會非常耗時，因此相同功能的編程係統構件的成本至少是[]立程序的3倍。如果係統有大量的組成單元，成本還會更高。
圖1-1的右下[]分代錶編程係統産品(Programming Syst[] Product)。與以上的所有的簡單的程序都不同的是，它的成本高達9倍。然而，隻有它纔是真正有用的産品，是大多數係統開發的目標。
職業的樂趣
編程為什麼有趣？作為迴報，它的從業者期望得到什麼樣的快樂？
[]先，這種快樂是一種創建事物的純粹快樂。如同小孩在玩泥巴時感到快樂一樣，成年人喜歡創建事物，特彆是自己進行設計。我想這種快樂是[]創造世界的[]射，一種呈現在每片[]特的、嶄新的樹葉和雪花上的喜悅。
其次，這種快樂來自於開發對他人有用的東西。內心深處，我們期望我們的勞動成果能夠被他人使用，並能對他們有所幫助。從這一角度而言，這同小孩用粘土為“爸爸的辦公室”捏製鉛筆盒沒有任何本質的區彆。
第三，快樂來自於整個過程體現齣的一股強大的魅力―― 將相互嚙閤的零[]件組裝在一起，看到它們以精妙的方式運行著，並收到瞭預期的效果。比起彈球遊戲機或自動電唱機所具有的迷人魅力，程序化的計算機毫不遜色。
第四，這種快樂是持續學習的快樂，它來自於這項工作的非重復特性。人們所麵臨的問題總有這樣那樣的不同，因而解決問題的人可以從中學習新的事物，有時是實踐上的，有時是理論上的，或者兼而有之。
[]後，這種快樂還來自於在易於駕馭的介質上工作。程序員，[]像詩人一樣，幾乎僅僅在單純的思考中工作。程序員憑空地運用自己的想象，來建造自己的“城堡”。很少有創造介質如此靈活，如此易於精煉和重建，如此容易實現概念上的設想(不過我們將會看到，容易駕馭的特性也有它自己的問題)。
然而程序畢竟同詩歌不同，它是實實在在的東西；它可以移動和運行，能[]立産生可見的輸齣；它能打印結果，繪製圖形，發齣聲音，移動支架。神話和傳說中的魔術在我們的時代已變成現實。在鍵盤上鍵入正確的咒語，屏幕會活動、變幻，的也不可能存在的事物。
編程的快樂在於它不僅滿足瞭我們內心深處進行創造的渴望，而且還喚醒瞭每個人內心的情感。
顯示全[]信息
用戶評價
從我接觸到的第一批技術書籍開始，我就對那些能夠跨越時間、依然能在當下引發共鳴的著作有著特彆的偏愛。而“人月神話”這個名字，在我這個行業裏，簡直就是如雷貫耳的傳說。我聽說過它無數次被提及，無數次被視為入門的聖經，卻一直沒有機會真正捧讀。這次看到有40周年的紀念版，而且還是中文的，我感覺像是遇到瞭一個絕佳的機會，可以彌補我一直以來的遺憾。這種感覺，就像是終於要見到一位期待已久的老友，迫不及待地想要聽他講述那些深刻的道理。我對布魯剋斯先生的洞見充滿瞭好奇，也對中文翻譯的質量充滿瞭信心。總而言之，這本書的齣現，對我來說，不僅僅是一次購書行為，更像是一次與軟件工程史上的巨人對話的邀約，一次對自身職業生涯進行深刻反思和提升的契機。
評分對於許多在軟件開發領域摸爬滾打多年的從業者來說，“人月神話”這個名字，已經不僅僅是一本書，它更像是一個符號，一個關於如何理解和管理復雜軟件項目的精神圖騰。我身邊就有不少前輩，在談論項目管理、團隊協作，甚至是軟件工程哲學時，都會不自覺地引用其中的觀點。雖然我還沒有正式翻開這本書，但光是聽到的這些溢美之詞，以及它長盛不衰的生命力，就足以讓我産生一種“不得不讀”的衝動。我期待這本書能帶給我一種“撥雲見日”的頓悟，讓我能夠以一種更宏觀、更深刻的視角來看待我們日常的開發工作，從中汲取經驗，避免重蹈覆轍。這不僅僅是知識的獲取，更是一種思維模式的迭代升級。
評分這本紀念版的外包裝，真的是讓我印象深刻。那沉甸甸的質感，不是虛浮的輕飄，而是實實在在的分量，暗示著內在內容的厚重。從拆開包裹的那一刻起，就能感受到一種對經典的尊重和對讀者的誠意。書的腰封設計，也很有講究，沒有那種花裏鬍哨的宣傳，而是簡潔有力地強調瞭紀念版的意義。我個人不太喜歡那種封麵上堆砌各種“必讀”、“經典”標簽的書，總覺得有點喧賓奪主。但這本的包裝，恰到好處地傳遞瞭一種“值得擁有”的氣息，沒有過度營銷，卻充滿瞭內在的價值感。這種“少即是多”的設計理念，讓我覺得齣版方在選書和推廣上，是真正用心在做一件有意義的事情。
評分這本書的封麵設計就帶著一種曆久彌新的沉靜感，那種復古的色調和字體的選擇，仿佛在訴說著時間的重量。拿到手裏，紙張的質感也是極好的，不是那種廉價的光麵紙，而是帶有微微的肌理感，翻閱時能感受到一種踏實。雖然我還沒開始深入閱讀，但僅僅是撫摸書頁、感受裝幀，就有一種對經典緻敬的情懷油然而生。我想，這本“40周年中文紀念版”不僅僅是一本書，更像是一個時代的印記，一個關於軟件工程思想沉澱的見證。包裝的嚴實程度也說明瞭齣版方的用心，無論是自留還是送禮，都能感受到這份丁寧。光是這份外在的呈現，就已經足以讓我對內容充滿期待瞭，仿佛書中蘊藏的智慧，也如同這封麵一樣，經得起時間的打磨，散發齣獨特的光芒。
評分說實話，在決定購買之前，我稍微做瞭一些功課，看瞭看一些關於這本書的討論。雖然沒有深入劇透，但聽到的零星評價都指嚮瞭這本書的核心價值——它對軟件開發中一些普遍存在的、看似簡單卻極其難以解決的問題進行瞭深入的剖析。我常常在工作中遇到一些項目延期、溝通不暢、團隊協作睏難的情況，而我總覺得這些問題背後有著更深層次的原因。很多時候，我們忙於解決眼前的技術難題，卻忽略瞭那些影響項目成敗的“人性”和“組織”層麵的因素。我猜測，“人月神話”這本書，或許就能夠為我揭示這些隱藏在復雜係統背後的本質規律，提供一些解決問題的新視角。這種對未知領域的探索欲，正是促使我毫不猶豫下單的原因。
相關圖書
本站所有內容均為互聯網搜尋引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2025 book.coffeedeals.club All Rights Reserved. 靜流書站 版權所有