人月神話

用戶評論 (總計10條)

•   　　《人月神話》乍看之下以為是一本神話小說，這就大錯特錯了。這是一本軟件工程的古老經典，是軟件工程的必讀書籍。其中涉及項目管理、團隊、人員、文檔等軟件工程必須的東西。作者用一個個生動的實例來闡述觀點，而不是無聊透頂的理論，這讓讀者更易于接受其中道理，可讀性很高。翻譯組翻譯到尾，將文章翻譯的很好，沒有生搬硬套。三十多年經久不衰就說明了這本書的影響力還在增加，軟件行業(yè)是一個急速發(fā)展的行業(yè)，但是這本書中很多理論還能夠跟上行業(yè)發(fā)展的腳步，說明這本書具有極強的前瞻性和理論性。建議所有想要進入軟件工程，特別是項目管理的相關人員閱讀。
  　　
•   　　 每個隊伍擁有自己的任務、進度、甚至如何定義、構建、發(fā)布的過程。團隊有4到5個專家組成，包括開發(fā)、測試、書寫文檔。有團隊而不是老板對討論進行仲裁。我無法形容授權和由團隊自行負責項目的成功與否的重要性
•   　　一、對于編程，喜歡的理由（寫的很好）
  　　編程為什么有趣？作為回報，它的從業(yè)者期望得到什么樣的快樂？
  　　首先是一種創(chuàng)建事物的純粹快樂。如同小孩在玩泥巴時感到愉快一樣，成年人喜歡創(chuàng)建事物，特別是自己進行設計。我想這種快樂是上帝創(chuàng)造世界的折射，一種呈現在每片獨特、嶄新的樹葉和雪花上的喜悅.其次，快樂來自于開發(fā)對其他人有用的東西。內心深處，我們期望其他人使用我們的勞動成果，并能對他們有所幫助。從這個方面，這同小孩用粘土為“爸爸辦公室”捏制鉛筆盒沒有本質的區(qū)別。
  　　第三是整個過程體現出魔術般的力量——將相互嚙合的零部件組裝在一起，看到它們精妙地運行，得到預先所希望的結果。比起彈珠游戲或點唱機所具有的迷人魅力，程序化的計算機毫不遜色。
  　　第四是學習的樂趣，來自于這項工作的非重復特性。人們所面臨的問題，在某個或其它方面總有些不同。因而解決問題的人可以從中學習新的事物：有時是實踐上的，有時是理論上的，或者兼而有之。
  　　最后，樂趣還來自于工作在如此易于駕馭的介質上。程序員，就像詩人一樣，幾乎僅僅工作在單純的思考中。程序員憑空地運用自己的想象，來建造自己的“城堡”。很少有這樣的介質——創(chuàng)造的方式如此得靈活，如此得易于精煉和重建，如此得容易實現概念上的設
  　　想。（不過我們將會看到，容易駕馭的特性也有它自己的問題）
  　　二、關于開發(fā)語言很真實
  　　當意識到進度的偏移時，下意識（以及傳統(tǒng)）的反應是增加人力。這就像使用汽油滅火一樣，只會使事情更糟。越來越大的火勢需要更多的汽油，從而進入了一場注定會導致災難的循環(huán)。
  　　無論多少個母親，孕育一個生命都需要十個月。
  　　1/3 計劃
  　　1/6 編碼
  　　1/4 構件測試和早期系統(tǒng)測試
  　　1/4 系統(tǒng)測試，所有的構件已完成
  　　人數和時間的互換僅僅適用于以下情況：某個任務可以分解給參與人員，并且他們之間不需要相互的交流（圖2.1 ）。這在割小麥或收獲棉花的工作中是可行的；而在系統(tǒng)編程中近乎不可能。
  　　四個圖印象非常深刻啊?。?br /> 　　向進度落后的項目中增加人手，只會使進度更加落后。（Addin g man po we r to a l ate software project makes it later ）
  　　絕大多數大型編程系統(tǒng)的經驗顯示出，一擁而上的開發(fā)方法是高成本的、速度緩慢的、不充分的。
  　　概念的完整性要求設計必須由一個人，或者非常少數互有默契的人員來實現。
  　　而進度壓力卻要求很多人員來開發(fā)系統(tǒng)。有兩種方法可以解決這種矛盾。第一種是仔細地區(qū)分設計方法和具體實現。第二種是前一章節(jié)中所討論的、一種嶄新的組建編程開發(fā)團隊的方法。
  　　
  　　不能與系統(tǒng)基本概念進行整合的良好想法和特色，最好放到一邊，不予考慮。
  　　
  　　三、關于分工
  　　產品負責人和技術主管是同一個人。這種方式非常容易應用在很小型的隊伍中，可能是三個或六個開發(fā)人員。在大型的項目中則不容易得到應用。原因有兩個：第一，同時具有管理技能和技術技能的人很難找到。思考者很少，實干家更少，思考者－實干家太少了。 第二，大型項目中，每個角色都必須全職工作，甚至還要加班。對負責人來，很難在承擔全部管理責任的同時，還能抽出時間進行技術工作。對技術主管來說，很難在保證設計的概念完整性，沒有任何妥協(xié)的前提下，擔任管理工作。
  　　
  　　實踐是最好的老師，但是，如果不能從中學習，再多的實踐也沒有用。
  　　
  　　普遍的做法是，選擇一種方法，試試看；如果失敗了，沒關系，再試試別的。不管怎么樣，重要的是先去嘗試。
  　　
  　　大多數有豐富經驗的程序員擁有自己的私人開發(fā)庫，可以使他們使用大約30％的重用代碼來開發(fā)軟件。
  　　
  　　四、最后
  　　最后的《人月神話》的觀點就是全書的綱！
•   　　很久以前就聽到過這本書，但是一直沒有時間去看完它，而當終于拜讀完之后，也確實明確了這本書在軟件工程中的重要，有些問題至今可以當做規(guī)范來使用
  　　
  　　學習編程最困難的部分，是講故事的方式向最求完美的方向調整
  　　
  　　軟件進度安排
  　　1/3 計劃
  　　1/6 編碼
  　　1/4 構建測試和早起的系統(tǒng)測試
  　　1/4 系統(tǒng)測試，所有的構建已完成
  　　
  　　概念的完整性需求設計必須由一個人活著少數有默契的人員來實現
  　　
  　　項目先決條件
  　　1、明確的目標
  　　2、人力
  　　3、材料
  　　4、時間
  　　5、技術
•   　　很多智力型工作，比如寫作、繪畫、表演，一直以來都沒有太大進步，軟件開發(fā)也是。《沒有銀彈》在未來十年應該依然存在。
  　　很多程序員崇拜技術大牛，因為他們相信大牛能夠帶來其他人走出焦油坑！這種人是很稀缺的，除了技術過硬，在眼界、人際關系等方面都要過硬。我覺得這種大牛才知道佩服！
•   　　作為一個純粹的文科生，有點吃力~不過還是能夠學習一些東西，互聯網不是我想象中的那么簡單，是個系統(tǒng)性很強大的內容，繼續(xù)學習，加油！我的心得，1、團隊建設，強調核心領導力的重要性以保證概念設計的完整性；2、溝通交流，強調組織的系統(tǒng)性以促進項目管理的實現；3、手冊文檔，強調手冊結構的精確完整以控制信息的發(fā)布。
  　　完全是個菜鳥，還是總結一些自己內容，希望對以后能有幫助。
  　　
•   　　讓我感到失望的地方如下：
  　　1.翻譯得太差，好多句子讀起來都特別別扭；尤其是章節(jié)標題，非要賣弄文字；
  　　2.書中舉例太過陳舊；
  　　不過這本書也有幾點不錯：
  　　1.作者對編程工作觀察得很仔細；
  　　2.本書非常實事求是；
  　　基于以上兩點，才沒有給予最差！
•   　　摘抄整理《人月神話》中的一些方法論。
  　　
  　　
  　　一、需求：required document 中要寫空間預算、測試用例
  　　
  　　二、開發(fā)：關注質量，生產力自然會提高
  　　
  　　三、測試：每修復一個bug，就有有20%-50%引入新bug
  　　
  　　四、組織/管理：
  　　
  　　1.排期：
  　　
  　　準確時間 ~ 估算的時間*2
  　　
  　　2. 項目必備要素
  　　- 任務需求細分
  　　- 產品負責人（主管左右手）
  　　- 技術負責人（主管）
  　　- 進度表
  　　- 分工
  　　- 接口定義
  　　
  　　3. 組織結構與交流結構：
  　　
  　　組織是樹狀的，但交流是網狀的
  　　
  　　4. 培養(yǎng)優(yōu)秀人才的方法
  　　- 指派職業(yè)導師，負責技術成長和職業(yè)生涯規(guī)劃
  　　- 安排學習計劃
  　　- 提供交流和激勵機會
  　　
  　　5. 建議草案要在會議之前就有，并且發(fā)放
  　　
  　　
  　　6. 大型項目排期
  　　
  　　每兩周進行一次計劃日期的修訂
  　　
  　　http://hi.baidu.com/xizhicat/blog/item/3f15b6321f8495f515cecb8c.html
•   　　現在我們對軟件工程的了解比1975年要多得多。那么在1975年版本的人月神話中，哪些觀點得到了數據和經驗的支持？哪些觀點被證明是不正確的？又有哪些觀點隨著世界的變化，顯得陳舊過時呢？為了幫助判斷，我將1975年書籍中的論斷毫無更改地抽取出來，以摘要的形式列舉在下面--它們是當年我認為將會是正確的：客觀事實和經驗中推廣的法則。（你也許會問，"如果這些就是那本書講的所有東西，為什么要花177頁的篇幅來論述？"）
  　　方括號中的評論是新增內容。
  　　所有這些觀點都是可操作驗證的，我將它們表達成刻板的形式是希望能引起讀者的思考、判斷和討論。
  　　第1章 焦油坑
  　　1.1 編程系統(tǒng)產品（Programming Systems Product）開發(fā)的工作量是供個人使用的、獨立開發(fā)的構件程序的九倍。我估計軟件構件產品化引起了3倍工作量，將軟件構件整合成完整系統(tǒng)所需要的設計、集成和測試又強加了3倍的工作量，這些高成本的構件在根本上是相互獨立的。
  　　1.2 編程行業(yè)"滿足我們內心深處的創(chuàng)造渴望和愉悅所有人的共有情感"，提供了五種樂趣：
  　　.. 創(chuàng)建事物的快樂
  　　.. 開發(fā)對其他人有用的東西的樂趣
  　　.. 將可以活動、相互嚙合的零部件組裝成類似迷宮的東西，這個過程所體現出令人神魂顛倒的魅力
  　　.. 面對不重復的任務，不間斷學習的樂趣
  　　.. 工作在如此易于駕馭的介質上的樂趣--純粹的思維活動，其存在、移動和運轉方式完全不同于實際物體
  　　1.3 同樣，這個行業(yè)具有一些內在固有的苦惱：
  　　.. 將做事方式調整到追求完美，是學習編程的最困難部分
  　　.. 由其他人來設定目標，并且必須依靠自己無法控制的事物（特別是程序）；權威不等同于責任
  　　.. 實際情況看起來要比這一點好一些：真正的權威來自于每次任務的完成
  　　.. 任何創(chuàng)造性活動都伴隨著枯燥艱苦的勞動，編程也不例外
  　　.. 人們通常期望項目在接近結束時，（bug、工作時間）能收斂得快一些，然而軟件項目的情況卻是越接近完成，收斂得越慢
  　　.. 產品在即將完成時總面臨著陳舊過時的威脅
  　　第2章 人月神話
  　　2.1 缺乏合理的時間進度是造成項目滯后的最主要原因，它比其他所有因素加起來影響還大。
  　　2.2 良好的烹飪需要時間，某些任務無法在不損害結果的情況下加快速度。
  　　2.3 所有的編程人員都是樂觀主義者："一切都將運作良好"。
  　　2.4 由于編程人員通過純粹的思維活動來開發(fā)，所以我們期待在實現過程中不會碰到困難。
  　　2.5 但是，我們的構思是有缺陷的，因此總會有bug。
  　　2.6 我們圍繞成本核算的估計技術，混淆了工作量和項目進展。人月是危險和帶有欺騙性的神話，因為它暗示人員數量和時間是可以相互替換的。
  　　2.7 在若干人員中分解任務會引發(fā)額外的溝通工作量--培訓和相互溝通。
  　　2.8 關于進度安排，我的經驗是為1/3計劃、1/6編碼、1/4構件測試以及1/4系統(tǒng)測試。
  　　2.9 作為一個學科，我們缺乏數據估計。
  　　2.10 因為我們對自己的估計技術不確定，所以在管理和客戶的壓力下，我們常常缺乏堅持的勇氣。
  　　2.11 Brook法則：向進度落后的項目中增加人手，只會使進度更加落后。
  　　2.12 向軟件項目中增派人手從三個方面增加了項目必要的總體工作量：任務重新分配本身和所造成的工作中斷；培訓新人員；額外的相互溝通。
  　　第3章 外科手術隊伍
  　　3.1 同樣有兩年經驗而且在受到同樣的培訓的情況下，優(yōu)秀的專業(yè)程序員的工作效率是較差程序員的十倍。（Sackman、Erikson和Grand）
  　　3.2 Sackman、Erikson和Grand的數據顯示經驗和實際表現之間沒有相互聯系。我懷疑這種現象是否普遍成立。
  　　3.3 小型、精干隊伍是最好的--盡可能的少。
  　　3.4 兩個人的團隊，其中一個項目經理，常常是最佳的人員使用方法。[留意一下上帝對婚姻的設計。]
  　　3.5 對于真正意義上的大型系統(tǒng)，小型精干的隊伍太慢了。
  　　3.6 實際上，絕大多數大型編程系統(tǒng)的經驗顯示出，一擁而上的開發(fā)方法是高成本、速度緩慢、不充分的，開發(fā)出的產品無法進行概念上的集成。
  　　3.7 一位首席程序員、類似于外科手術隊伍的團隊架構提供了一種方法--既能獲得由少數頭腦產生的產品完整性，又能得到多位協(xié)助人員的總體生產率，還徹底地減少了溝通的工作量。
  　　第4章 貴族專制、民主政治和系統(tǒng)設計
  　　4.1 "概念完整性是系統(tǒng)設計中最重要的考慮因素"。
  　　4.2 "功能與理解上的復雜程度的比值才是系統(tǒng)設計的最終測試標準"，而不僅僅是豐富的功能。[該比值是對易用性的一種測量，由簡單和復雜應用共同驗證。]
  　　4.3 為了獲得概念完整性，設計必須由一個人或者具有共識的小型團隊來完成。
  　　4.4 "對于非常大型的項目，將設計方法、體系結構方面的工作與具體實現相分離是獲得概念完整性的強有力方法。"[同樣適用于小型項目。]
  　　4.5 "如果要得到系統(tǒng)概念上的完整性，那么必須控制這些概念。這實際上是一種無需任何歉意的貴族專制統(tǒng)治。"
  　　4.6 紀律、規(guī)則對行業(yè)是有益的。外部的體系結構規(guī)定實際上是增強，而不是限制實現小組的創(chuàng)造性。
  　　4.7 概念上統(tǒng)一的系統(tǒng)能更快地開發(fā)和測試。
  　　4.8 體系結構（architecture）、設計實現（implementation）、物理實現（realization）的許多工作可以并發(fā)進行。[軟件和硬件設計同樣可以并行。]
  　　第5章 畫蛇添足
  　　5.1 盡早交流和持續(xù)溝通能使結構師有較好的成本意識，以及使開發(fā)人員獲得對設計的信心，并且不會混淆各自的責任分工。
  　　5.2 結構師如何成功地影響實現：
  　　.. 牢記是開發(fā)人員承擔創(chuàng)造性的實現責任；結構師只能提出建議。
  　　.. 時刻準備著為所指定的說明建議一種實現的方法，準備接受任何其他可行的方法。
  　　.. 對上述的建議保持低調和平靜。
  　　.. 準備對所建議的改進放棄堅持。
  　　.. 聽取開發(fā)人員在體系結構上改進的建議。
  　　5.3 第二個系統(tǒng)是人們所設計的最危險的系統(tǒng)，通常的傾向是過分地進行設計。
  　　5.4 OS/360是典型的畫蛇添足（second-system effect）的例子。[Windows NT似乎是90年代的例子。]
  　　5.5 為功能分配一個字節(jié)和微秒的優(yōu)先權值是一個很有價值的規(guī)范化方法。
  　　第6章 貫徹執(zhí)行
  　　6.1 即使是大型的設計團隊，設計結果也必須由一個或兩個人來完成，以確保這些決定是一致的。
  　　6.2 必須明確定義體系結構中與先前定義不同的地方，重新定義的詳細程度應該與原先的說明一致。
  　　6.3 出于精確性的考慮，我們需要形式化的設計定義，同樣，我們需要記敘性定義來加深理解。
  　　6.4 必須采用形式化定義和記敘性定義中的一種作為標準，另一種作為輔助措施；它們都可以作為表達的標準。
  　　6.5 設計實現，包括模擬仿真，可以充當一種形式化定義的方法；這種方法有一些嚴重的缺點。
  　　6.6 直接整合是一種強制推行軟件的結構性標準的方法。[硬件上也是如此--考慮內建在ROM中的Mac WIMP接口。]
  　　6.7 "如果起初至少有兩種以上的實現，那么（體系結構）定義會更加整潔，會更加規(guī)范。"
  　　6.8 允許體系結構師對實現人員的詢問做出電話應答解釋是非常重要的，并且必須進行日志記錄和整理發(fā)布。[電子郵件是一種可選的介質。]
  　　6.9 "項目經理最好的朋友就是他每天要面對的敵人--獨立的產品測試機構/小組。"
  　　第7章 為什么巴比倫塔會失敗？
  　　7.1 巴比倫塔項目的失敗是因為缺乏交流，以及交流的結果--組織。 交流
  　　7.2 "因為左手不知道右手在做什么，從而進度災難、功能的不合理和系統(tǒng)缺陷紛紛出現。"由于對其他人的各種假設，團隊成員之間的理解開始出現偏差。
  　　7.3 團隊應該以盡可能多的方式進行相互之間的交流：非正式、常規(guī)項目會議，會上進行簡要的技術陳述、共享的正式項目工作手冊。[以及電子郵件。]
  　　項目工作手冊
  　　7.4 項目工作手冊"不是獨立的一篇文檔，它是對項目必須產生的一系列文檔進行組織的一種結構。"
  　　7.5 "項目所有的文檔都必須是該（工作手冊）結構的一部分。"
  　　7.6 需要盡早和仔細地設計工作手冊結構。
  　　7.7 事先制訂了良好結構的工作手冊"可以將后來書寫的文字放置在合適的章節(jié)中"，并且可以提高產品手冊的質量。
  　　7.8 "每一個團隊成員應該了解所有的材料（工作手冊）。"[我想說的是，每個團隊成員應該能夠看到所有材料，網頁即可滿足要求。]
  　　7.9 實時更新是至關重要的。
  　　7.10 工作手冊的使用者應該將注意力集中在上次閱讀后的變更，以及關于這些變更重要性的評述。
  　　7.11 OS/360項目工作手冊開始采用的是紙介質，后來換成了微縮膠片。
  　　7.12 今天[即使在1975年]，共享的電子手冊是能更好達到所有這些目標、更加低廉、更加簡單的機制。
  　　7.13 仍然需要用變更條和修訂日期[或具備同等功能的方法]來標記文字；仍然需要后進先出（LIFO）的電子化變更小結。
  　　7.14 Parnas強烈地認為使每個人看到每件事的目標是完全錯誤的；各個部分應該被封裝，從而沒有人需要或者允許看到其他部分的內部結構，只需要了解接口。
  　　7.15 Parnas的建議的確是災難的處方。
  　　組織架構
  　　7.16 團隊組織的目標是為了減少必要的交流和協(xié)作量。
  　　7.17 為了減少交流，組織結構包括了人力劃分（division of labor）和限定職責范圍（specialization of function）。
  　　7.18 傳統(tǒng)的樹狀組織結構反映了權力的結構原理--不允許雙重領導。
  　　7.19 組織中的交流是網狀，而不是樹狀結構，因而所有的特殊組織機制（往往體現成組織結構圖中的虛線部分）都是為了進行調整，以克服樹狀組織結構中交流缺乏的困難。
  　　7.20 每個子項目具有兩個領導角色--產品負責人、技術主管或結構師。這兩個角色的職能有著很大的區(qū)別，需要不同的技能。
  　　7.21 兩種角色中的任意組合可以是非常有效的：
  　　.. 產品負責人和技術主管是同一個人。
  　　.. 產品負責人作為總指揮，技術主管充當其左右手。
  　　.. 技術主管作為總指揮，產品負責人充當其左右手。
  　　第8章 胸有成竹
  　　8.1 僅僅通過對編碼部分的估計，然后乘以任務其他部分的相對系數，是無法得出對整項工作的精確估計的。
  　　8.2 構建獨立小型程序的數據不適用于編程系統(tǒng)項目。
  　　8.3 程序開發(fā)呈程序規(guī)模的指數增長。
  　　8.4 一些發(fā)表的研究報告顯示指數約為1.5。[Boehm的數據并不完全一致，在1.05和1.2之間變化。1]
  　　8.5 Portman的ICL數據顯示相對于其他活動開銷，全職程序員僅將50％的時間用于編程和調試。
  　　8.6 IBM的Aron數據顯示，生產率是系統(tǒng)各個部分交互的函數，在1.5K千代碼行/人年至10K千代碼行/人年的范圍內變化。
  　　8.7 Harr的Bell實驗室數據顯示對于已完成的產品，操作系統(tǒng)類的生產率大約是0.6KLOC/人年，編譯類工作的生產率大約為2.2KLOC/人年。
  　　8.8 Brooks的OS/360S數據與Harr的數據一致：操作系統(tǒng)0.6～0.8KLOC/人年，編譯器2～3 KLOC/人年。
  　　8.9 Corbato的MIT項目MULTICS數據顯示，在操作系統(tǒng)和編譯器混合類型上的生產率是1.2KLOC/人年，但這些是PL/I的代碼行，而其他所有的數據是匯編代碼行。
  　　8.10 在基本語句級別，生產率看上去是個常數。
  　　8.11 當使用適當的高級語言時，程序編制的生產率可以提高5倍。
  　　第9章 削足適履
  　　9.1 除了運行時間以外，所占據的內存空間也是主要開銷。特別是對于操作系統(tǒng)，它的很多程序是永久駐留在內存中。
  　　9.2 即便如此，花費在駐留程序所占據內存上的金錢仍是物有所值的，比其他任何在配置上投資的效果要好。規(guī)模本身不是壞事，但不必要的規(guī)模是不可取的。
  　　9.3 軟件開發(fā)人員必須設立規(guī)模目標，控制規(guī)模，發(fā)明一些減少規(guī)模的方法--就如同硬件開發(fā)人員為減少元器件所做的一樣。
  　　9.4 規(guī)模預算不僅僅在占據內存方面是明確的，同時還應該指明程序對磁盤的訪問次數。
  　　9.5 規(guī)模預算必須與分配的功能相關聯；在指明模塊大小的同時，確切定義模塊的功能。
  　　9.6 在大型的團隊中，各個小組傾向于不斷地局部優(yōu)化，以滿足自己的目標，而較少考慮隊用戶的整體影響。這種方向性的問題是大型項目的主要危險。
  　　9.7 在整個實現的過程期間，系統(tǒng)結構師必須保持持續(xù)的警覺，確保連貫的系統(tǒng)完整性。
  　　9.8 培養(yǎng)開發(fā)人員從系統(tǒng)整體出發(fā)、面向用戶的態(tài)度是軟件編程管理人員最重要的職能。
  　　9.9 在早期應該制訂策略，以決定用戶可選項目的粗細程度，因為將它們作為整體大包能夠節(jié)省內存空間。[常常還可以節(jié)約市場成本。]
  　　9.10 臨時空間的尺寸，以及每次磁盤訪問的程序數量是很關鍵的決策，因為性能是規(guī)模的非線性函數。[這個整體決策已顯得過時--起初是由于虛擬內存，后來則是成本低廉的內存?，F在的用戶通常會購買能容納主要應用程序所有代碼的內存。]
  　　9.11 為了取得良好的空間－時間折衷，開發(fā)隊伍需要得到特定與某種語言或者機型的編程技能培訓，特別是在使用新語言或者新機器時。
  　　9.12 編程需要技術積累，每個項目需要自己的標準組件庫。
  　　9.13 庫中的每個組件需要有兩個版本，運行速度較快和短小精煉的。[現在看來有些過時。]
  　　9.14 精煉、充分和快速的程序。往往是戰(zhàn)略性突破的結果，而不僅僅技巧上的提高。
  　　9.15 這種突破常常是一種新型算法。
  　　9.16 更普遍的是，戰(zhàn)略上突破常來自于數據或表的重新表達。數據的表現形式是編程的根本。
  　　第10章 提綱挈領
  　　10.1 "前提：在一片文件的汪洋中，少數文檔形成了關鍵的樞紐，每個項目管理的工作都圍繞著它們運轉。它們是經理們的主要個人工具。"
  　　10.2 對于計算機硬件開發(fā)項目，關鍵文檔是目標、手冊、進度、預算、組織機構圖、空間分配、以及機器本身的報價、預測和價格。
  　　10.3 對于大學科系，關鍵文檔類似：目標、課程描述、學位要求、研究報告、課程表和課程的安排、預算、教室分配、教師和研究生助手的分配。
  　　10.4 對于軟件項目，要求是相同的：目標、用戶手冊、內部文檔、進度、預算、組織機構圖和工作空間分配。
  　　10.5 因此，即使是小型項目，項目經理也應該在項目早期規(guī)范化上述的一系列文檔。
  　　10.6 以上集合中每一個文檔的準備工作都將注意力集中在對討論的思索和提煉，而書寫這項活動需要上百次的細小決定，正是由于它們的存在，人們才能從令人迷惑的現象中得到清晰、確定的策略。
  　　10.7 對每個關鍵文檔的維護提供了狀態(tài)監(jiān)督和預警機制。
  　　10.8 每個文檔本身就可以作為檢查列表或者數據庫。
  　　10.9 項目經理的基本職責是使每個人都向著相同的方向前進。
  　　10.10 項目經理的主要日常工作是溝通，而不是做出決定；文檔使各項計劃和決策在整個團隊范圍內得到交流。
  　　10.11 只有一小部分管理人員的時間--可能只有20%--用來從自己頭腦外部獲取信息。
  　　10.12 出于這個原因，廣受吹捧的市場概念--支持管理人員的"完備信息管理系統(tǒng)"并不基于反映管理人員行為的有效模型。
  　　第11章 未雨綢繆
  　　11.1 化學工程師已經認識到無法一步將實驗室工作臺上的反應過程移到工廠中，需要一個實驗性工廠（pilot planet）來為提高產量和在缺乏保護的環(huán)境下運作提供寶貴經驗。
  　　11.2 對于編程產品而言，這樣的中間步驟是同樣必要的，但是軟件工程師在著手發(fā)布產品之前，卻并不會常規(guī)地進行試驗性系統(tǒng)的現場測試。[現在，這已經成為了一項普遍的實踐，beta版本。它不同于有限功能的原型，alpha版本，后者同樣是我所倡導的實踐。]
  　　11.3 對于大多數項目，第一個開發(fā)的系統(tǒng)并不合用。它可能太慢、太大，而且難以使用，或者三者兼而有之。
  　　11.4 系統(tǒng)的丟棄和重新設計可以一步完成，也可以一塊塊地實現。這是個必須完成的步驟。
  　　11.5 將開發(fā)的第一個系統(tǒng)--丟棄原型--發(fā)布給用戶，可以獲得時間，但是它的代價高昂--對于用戶，使用極度痛苦；對于重新開發(fā)的人員，分散了精力；對于產品，影響了聲譽，即使最好的再設計也難以挽回名聲。
  　　11.6 因此，為舍棄而計劃，無論如何，你一定要這樣做。
  　　11.7 "開發(fā)人員交付的是用戶滿意程度，而不僅僅是實際的產品。"（Cosgrove）
  　　11.8 用戶的實際需要和用戶感覺會隨著程序的構建、測試和使用而變化。
  　　11.9 軟件產品易于掌握的特性和不可見性，導致了它的構建人員（特別容易）面臨著永恒的需求變更。
  　　11.10 目標上（和開發(fā)策略上）的一些正常變化無可避免，事先為它們做準備總比假設它們不會出現要好得多。
  　　11.11 為變更計劃軟件產品的技術，特別是細致的模塊接口文檔--非常地廣為人知，但并沒有相同規(guī)模的實踐。盡可能地使用表驅動技術同樣是有所幫助的。[現在內存的成本和規(guī)模使這項技術越來越出眾。]
  　　11.12 高級語言的使用、編譯時操作、通過引用的聲明整合和自文檔技術能減少變更引起的錯誤。
  　　11.13 采用定義良好的數字化版本將變更量子（階段）化。[當今的標準實踐。]
  　　為變更計劃組織架構
  　　11.14 程序員不愿意為設計書寫文檔的原因，不僅僅是由于惰性。更多的是源于設計人員的躊躇--要為自己嘗試性的設計決策進行辯解。（Cosgrove）
  　　11.15 為變更組建團隊比為變更進行設計更加困難。
  　　11.16 只要管理人員和技術人才的天賦允許，老板必須對他們的能力培養(yǎng)給予極大的關注，使管理人員和技術人才具有互換性；特別是希望能在技術和管理角色之間自由地分配人手的時候。
  　　11.17 具有兩條晉升線的高效組織機構，存在著一些社會性的障礙，人們必須警惕和積極地同它做持續(xù)的斗爭。
  　　11.18 很容易為不同的晉升線建立相互一致的薪水級別，但要同等威信的建立需要一些強烈的心理措施：相同的辦公室、一樣的支持和技術調動的優(yōu)先補償。
  　　11.19 組建外科手術隊伍式的軟件開發(fā)團隊是對上述問題所有方面的徹底沖擊。對于靈活組織架構問題，這的確是一個長期行之有效的解決方案。
  　　前進兩步，后退一步--程序維護
  　　11.20 程序維護基本上不同于硬件的維護；它主要由各種變更組成，如修復設計缺陷、新增功能、或者是使用環(huán)境或者配置變換引起的調整。
  　　11.21 對于一個廣泛使用的程序，其維護總成本通常是開發(fā)成本的40％或更多。
  　　11.22 維護成本受用戶數目的嚴重影響。用戶越多，所發(fā)現的錯誤也越多。
  　　11.23 Campbell指出了一個顯示產品生命期中每月bug數的有趣曲線，它先是下降，然后攀升。
  　　11.24 缺陷修復總會以（20－50）%的機率引入新的bug。
  　　11.25 在每次修復之后，必須重新運行先前所有的測試用例，從而確保系統(tǒng)不會以更隱蔽的方式被破壞。
  　　11.26 能消除、至少是能指明副作用的程序設計方法，對維護成本有很大的影響。
  　　11.27 同樣，設計實現的人員越少、接口越少，產生的錯誤也就越少。
  　　前進一步，后退一步--系統(tǒng)熵隨時間增加
  　　11.28 Lehman和Belady發(fā)現模塊數量隨大型操作系統(tǒng)（OS/360）版本號的增加呈線性增長，但是受到影響的模塊以版本號指數的級別增長。
  　　11.29 所有修改都傾向于破壞系統(tǒng)的架構，增加了系統(tǒng)的混亂程度。即使是最熟練的軟件維護工作，也只是放緩了系統(tǒng)退化到不可修復混亂的進程，從中必須要重新進行設計。
  　　[許多程序升級的真正需要，如性能等，尤其會沖擊它的內部結構邊界。原有邊界引發(fā)的不足常常在日后才會出現。]
  　　第12章 干將莫邪
  　　12.1 項目經理應該制訂一套策略，以及為通用工具的開發(fā)分配資源，與此同時，他還必須意識到專業(yè)工具的需求。
  　　12.2 開發(fā)操作系統(tǒng)的隊伍需要自己的目標機器，進行調試開發(fā)工作。相對于最快的速度而言，它更需要最大限度的內存，還需要安排一名系統(tǒng)程序員，以保證機器上的標準軟件是即時更新和實時可用的。
  　　12.3 同時還需要配備調試機器或者軟件，以便在調試過程中，所有類型的程序參數可以被自動計數和測量。
  　　12.4 目標機器的使用需求量是一種特殊曲線：剛開始使用率非常低，突然出現爆發(fā)性的增長，接著趨于平緩。
  　　12.5 同天文工作者一樣，系統(tǒng)調試總是大部分在夜間完成。
  　　12.6 拋開理論不談，一次分配給某個小組連續(xù)的目標時間塊被證明是最好的安排方法，比不同小組的穿插使用更為有效。
  　　12.7 盡管技術不斷變化，這種采用時間塊來安排匱乏計算機資源的方式仍得以延續(xù)20年[在1975年]，是因為它的生產率最高。[在1995年依然如此]
  　　12.8 如果目標機器是新產品，則需要一個目標機器的邏輯仿真裝置。這樣，可以更快地得到輔助調試平臺。即使在真正機器出現之后，仿真裝置仍可提供可靠的調試平臺。
  　　12.9 主程序庫應該被劃分成（1）一系列獨立的私有開發(fā)庫；（2）正處在系統(tǒng)測試下的系統(tǒng)集成子庫；（3）發(fā)布版本。正式的分離和進度提供了控制。
  　　12.10 在編制程序的項目中，節(jié)省最大工作量的工具可能是文本編輯系統(tǒng)。
  　　12.11 系統(tǒng)文檔中的巨大容量帶來了新的不理解問題[例如，看看Unix]，但是它比大多數未能詳細描述編程系統(tǒng)特性的短小文章更加可取。
  　　12.12 自頂向下、徹底地開發(fā)一個性能仿真裝置。盡可能早地開始這項工作，仔細地聽取 "它們表達的意見"。
  　　高級語言
  　　12.13 只有懶散和惰性會妨礙高級語言和交互式編程的廣泛應用。[如今它們已經在全世界使用。]
  　　12.14 高級語言不僅僅提升了生產率，而且還改進了調試：bug更少，以及更容易尋找。
  　　12.15 傳統(tǒng)的反對意見--功能、目標代碼的尺寸、目標代碼的速度，隨著語言和編譯器技術的進步已不再成為問題。
  　　12.16 現在可供合理選擇的語言是PL/I。[不再正確。]
  　　交互式編程
  　　12.17 某些應用上，批處理系統(tǒng)決不會被交互式系統(tǒng)所替代。[依然成立。]
  　　12.18 調試是系統(tǒng)編程中很慢和較困難的部分，而漫長的調試周轉時間是調試的禍根。
  　　12.19 有限的數據表明了系統(tǒng)軟件開發(fā)中，交互式編程的生產率至少是原來的兩倍。
  　　第13章 整體部分
  　　13.1 第4、5、6章所意味的煞費苦心、詳盡體系結構工作不但使產品更加易于使用，而且使開發(fā)更容易進行以及bug更不容易產生。
  　　13.2 V.A.Vyssotsky提出，"許許多多的失敗完全源于那些產品未精確定義的地方。"
  　　13.3 在編寫任何代碼之前，規(guī)格說明必須提交給測試小組，以詳細地檢查說明的完整性和明確性。開發(fā)人員自己不會完成這項工作。（Vyssotsky）
  　　13.4 "十年內[1965～1975]，Wirth的自頂向下進行設計[逐步細化]將會是最重要的新型形式化軟件開發(fā)方法。"
  　　13.5 Wirth主張在每個步驟中，盡可能使用級別較高的表達方法。
  　　13.6 好的自頂向下設計從四個方面避免了bug。
  　　13.7 有時必須回退，推翻頂層設計，重新開始。
  　　13.8 結構化編程中，程序的控制結構僅由支配代碼塊（相對于任意的跳轉）的給定集合所組成。這種方法出色地避免了bug，是一種正確的思考方式。
  　　13.9 Gold結果顯示了，在交互式調試過程中，第一次交互取得的工作進展是后續(xù)交互的三倍。這實際上獲益于在調試開始之前仔細地調試計劃。[我認為在1995年依然如此。]
  　　13.10 我發(fā)現對良好終端系統(tǒng)的正確使用，往往要求每兩小時的終端會話對應于兩小時的桌面工作：1小時會話后的清理和文檔工作；1小時為下一次計劃變更和測試。
  　　13.11 系統(tǒng)調試（相對于單元測試）花費的時間會比預料的更長。
  　　13.12 系統(tǒng)調試的困難程度證明了需要一種完備系統(tǒng)化和可計劃的方法。
  　　13.13 系統(tǒng)調試僅僅應該在所有部件能夠運作之后開始。（這既不同于為了查出接口bug所采取 "合在一起嘗試" 的方法；也不同于在所有構件單元的bug已知，但未修復的情況下，即開始系統(tǒng)調試的做法。）[對于多個團隊尤其如此。]
  　　13.14 開發(fā)大量的輔助調試平臺（scaffolding 腳手架）和測試代碼是很值得的，代碼量甚至可能會有測試對象的一半。
  　　13.15 必須有人對變更進行控制和文檔化，團隊成員應使用開發(fā)庫的各種受控拷貝來工作。
  　　13.16 系統(tǒng)測試期間，一次只添加一個構件。
  　　13.17 Lehman和Belady出示了證據，變更的階段（量子）要么很大，間隔很寬；要么小和頻繁。后者很容易變得不穩(wěn)定。[Microsoft的一個團隊使用了非常小的階段（量子）。結果是每天晚上需要重新編譯生成增長中的系統(tǒng)。]
  　　第14章 禍起蕭墻
  　　14.1 "項目是怎樣延遲了整整一年的時間？.一次一天。"
  　　14.2 一天一天的進度落后比起重大災難，更難以識別、更不容易防范和更加難以彌補。
  　　14.3 根據一個嚴格的進度表來控制項目的第一個步驟是制訂進度表，進度表由里程碑和日期組成。
  　　14.4 里程碑必須是具體的、特定的、可度量的事件，能進行清晰能定義。
  　　14.5 如果里程碑定義得非常明確，以致于無法自欺欺人時，程序員很少會就里程碑的進展弄虛作假。
  　　14.6 對于大型開發(fā)項目中的估計行為，政府的承包商所做的研究顯示：每兩周進行仔細修訂的活動時間估計，隨著開始時間的臨近不會有太大的變化；期間內對時間長短的過高估計，會隨著活動的進行持續(xù)下降；過低估計直到計劃的結束日期之前大約三周左右，才有所變化。
  　　14.7 慢性進度偏離是士氣殺手。[Microsoft的Jim McCarthy說："如果你錯過了一個最終期限（deadline），確保制訂下一條deadline。2">
  　　14.8 進取對于杰出的軟件開發(fā)團隊，同優(yōu)秀的棒球隊伍一樣，是不可缺少的必要品德。
  　　14.9 不存在關鍵路徑進度的替代品，使人們能夠辨別計劃偏移的情況。
  　　14.10 PERT的準備工作是PERT圖使用中最有價值的部分。它包括了整個網狀結構的展開、任務之間依賴關系的識別、各個任務鏈的估計。這些都要求在項目早期進行非常專業(yè)的計劃。
  　　14.11 第一份PERT圖總是很恐怖的，不過人們總是不斷進行努力，運用才智制訂下一份PERT圖。
  　　14.12 PERT圖為前面那個泄氣的借口，"其他的部分反正會落后"，提供了答案。
  　　14.13 每個老板同時需要采取行動的異常信息以及用來進行分析和早期預警的狀態(tài)數據。
  　　14.14 狀態(tài)的獲取是困難的，因為下屬經理有充分的理由不提供信息共享。
  　　14.15 老板的不良反應肯定會對信息的完全公開造成壓制；相反，仔細區(qū)分狀態(tài)報告、毫無驚慌地接收報告、決不越俎代庖，將能鼓勵誠實的匯報。
  　　14.16 必須有評審的機制，從而所有成員可以通過它了解真正的狀態(tài)。出于這個目的，里程碑的計劃和完成文檔是關鍵。
  　　14.17 Vyssotsky：我發(fā)現在里程碑報告中很容易記錄"計劃（老板的日期）"和"估計（最基層經理的日期）"的日期。項目經理必須停止對這些日期的懷疑。"
  　　14.18 對于大型項目，一個對里程碑報告進行維護的計劃和控制（Plan and Control）小組是非?？少F的。
  　　第15章 另外一面
  　　15.1 對于軟件編程產品來說，程序向用戶所呈現的面貌與提供給機器識別的內容同樣重要。
  　　15.2 即使對于完全開發(fā)給自己使用的程序，描述性文字也是必須的，因為它們會被用戶－作者所遺忘。
  　　15.3 培訓和管理人員基本上沒有能向編程人員成功地灌輸對待文檔的積極態(tài)度--文檔能在整個生命周期對克服懶惰和進度的壓力起促進激勵作用。
  　　15.4 這樣的失敗并不都是因為缺乏熱情或者說服力，而是沒能正確地展示如何有效和經濟地編制文檔。
  　　15.5 大多數文檔只提供了很少的總結性內容。必須放慢腳步，穩(wěn)妥地進行。
  　　15.6 由于關鍵的用戶文檔包含了跟軟件相關的基本決策，所以它的絕大部分需要在程序編制之前書寫，它包括了9項內容（參見相應章節(jié)）。
  　　15.7 每一份發(fā)布的程序拷貝應該包括一些測試用例，其中一部分用于校驗輸入數據，一部分用于邊界輸入數據，另一部分用于無效的輸入數據。
  　　15.8 對于必須修改程序的人而言，他們所需要程序內部結構文檔，同樣要求一份清晰明了的概述，它包括了5項內容（參見相應章節(jié)）。
  　　15.9 流程圖是被吹捧得最過分的一種程序文檔。詳細逐一記錄的流程圖是一件令人生厭的事情，而且高級語言的出現使它顯得陳舊過時。（流程圖是圖形化的高級語言。）
  　　15.10 如果這樣，很少有程序需要一頁紙以上的流程圖。[在這一點上，MILSPEC軍用標準實在錯得很厲害。]
  　　15.11 即使的確需要一張程序結構圖，也并不需要遵照ANSI的流程圖標準。
  　　15.12 為了使文檔易于維護，將它們合并至源程序是至關重要的，而不是作為獨立文檔進行保存。
  　　15.13 最小化文檔負擔的3個關鍵思路：
  　　.. 借助那些必須存在的語句，如名稱和聲明等，來附加盡可能多的"文檔"信息。
  　　.. 使用空格和格式來表現從屬和嵌套關系，提高程序的可讀性。
  　　.. 以段落注釋，特別是模塊標題的形式，向程序中插入必要的記敘性文字。
  　　15.14 程序修改人員所使用的文檔中，除了描述事情如何以外，還應闡述它為什么那樣。對于加深理解，目的是非常關鍵的，但即使是高級語言的語法，也不能表達目的。
  　　15.15 在線系統(tǒng)的高級語言（應該使用的工具）中，自文檔化技術發(fā)現了它的絕佳應用和強大功能。
  　　原著結束語
  　　E.1 軟件系統(tǒng)可能是人類創(chuàng)造中最錯綜復雜的事物（從不同類型組成部分數量的角度出發(fā)）。
  　　E.2 軟件工程的焦油坑在將來很長一段時間內會繼續(xù)地使人們舉步維艱，無法自拔。
•   　　如果你自稱是IT從業(yè)人員，卻沒有聽說過《人月神話》，那可就丟臉了。而30多年前的軟件工程書籍，在發(fā)展神速的IT行業(yè)，也稱得上是“古書”了。
  　　
  　　Brooks博士30多年前寫的軟件工程的書，到今天依然有些幫助，可見在有些問題上的認識是非常深刻的。
  　　
  　　通過少量核心設計人員（Arch）來保證軟件/產品的概念一致性。
  　　
  　　提倡外科手術式的團隊。（事實上agile方法上的人員配備，應該或多或少的借鑒了這個建議）
  　　
  　　文檔的適度。
  　　
  　　以及IBM在大型軟件開發(fā)中的先驅地位。
  　　
  　　如果熟知項目管理的流程，理解傳統(tǒng)的瀑布開發(fā)流程，或者了解流行的敏捷開發(fā)，Brooks博士的這本書，其實并不會有任何實質性的幫助。但是把自己置身于當年，依然會感嘆他的睿智。
  　　
  　　與其說從《人與神話》中學到什么，不如說去感受點什么。否則，從實用主義的角度看，《人月神話》其實被過度神話了。
  　　
  　　《人月神話》 作者： Frederick P. Brooks, Jr
  　　
  　　總體評價：謹慎推薦
  　　

相關圖書

• 兒童國畫入門（四）
• 中學生人格理念精美短文導讀
• 雅思強化聽力
• 疼痛.疾病與治療
• 中國十大社會熱點批判
• 生物數學
• 心理衛(wèi)生/部隊衛(wèi)生防疫叢書
• 甲亢防治ＡＢＣ——常見病防治ＡＢＣ系列叢書
• 守法的故事——美德故事叢書
• 現代外科學(上.下)
• 希臘神話與傳說（一）
• 超越零點--學Excel
• 西洋美術家畫廊(63)--提埃波羅
• 數學猜想：數學篇——不知道的世界
• 鄭誦先章草《毛澤東詩詞》
• 肝纖維化的基礎研究及臨床（第二版）
• 大衛(wèi) 安格爾
• 藥劑學(第三版)
• 全國計算機等級考試考試要點、題解與模擬試卷（三級PC技術）（含光盤）
• 金魚
• 健美技巧圖解
• 中文版FLASH MX實例與操作(附光盤)
• 創(chuàng)新思維法(第二版)
• 消化系統(tǒng)常見病防治260問
• 奧運競賽項目英漢知識手冊