人月神話摘要

利用平時坐公交和火車的碎片時間，把這本書看完了，記得剛學編程時，有不少搞IT的朋友都推薦我看看這本書，這也是我讀這本書的動機，讀完了後也學到了不少軟件開發和項目管理的知識，可是沒有感覺到醍醐灌頂的感受，有些內容還不是很理解，多是我相關的項目經驗太少的緣故吧，不過既然讀完了，就作一下總結吧，也許等若干年後當我再次讀這本書時，感受就徹底不同了。

焦油坑

• 編程系統產品的工做量是獨立開發的程序構件的9倍，構件的產品化是原來開發構件的3倍，構件產品整合到系統中又3倍

人月神話

• 時間進度安排的不合理是項目滯後的最主要緣由
• 保質保量開發一個軟件是須要必定的時間的
• 程序員都是樂觀主義者，軟件總會有Bug
  
• 人員數量和時間沒法替換，一個項目滯後之後更多的人來「幫忙」只會更加滯後，軟件開發過程當中培訓和溝通交流的時間成本是很高的
• 項目進度安排比例：策劃1/3 1/6編碼 1/4構件測試 1/4系統測試

外科手術隊伍

• 優秀程序員的生產率是通常程序員的10倍
• 小型精幹的團隊是最好的
• 對於大型的系統，小型精幹的團隊速度太慢了
• 相似外科手術的團隊能很好解決大型系統開發的問題

貴族專制 民主政治和系統設計

• 概念完整性是系統設計中最重要的因素
• 爲了保證概念完整性，設計必須由一我的或一個小型的團隊
• 軟件開發要實現設計和具體實現的分離
• 限制和規則能激發創造性
• 概念統一的系統能更快的開發和測試

多此一舉

• 不要過度設計

貫徹執行

• 設計必須由一個或兩我的負責，確保設計的一致性
• 具體精確的定義系統和功能

爲何巴比倫塔會失敗

• 失敗的緣由：交流
• 團隊應該儘量多的交流
• 制定良好的工做手冊
• 每個團隊成員都應該能看到全部材料
• 每一個團隊兩個領導，技術負責人和產品負責人

成竹在胸

• 僅僅靠編碼時間乘以係數是沒法獲得完成時間的
• 小項目的數據不適用於大項目，開發時間隨項目大小呈指數增加
• 使用高級語言的效率是使用匯編語言5倍

削足適履

• 控制規模，精簡系統功能
• 從系統出發，面向用戶

提綱挈領

• 文檔的關鍵，目標，用戶手冊，內部文檔，進度，預算，組織結構圖和工做空間分配
• 爲每一個關鍵文檔提供狀態監督和語境機制
• 項目經理的職責是使每一個人都朝着同一個方向前進
• 項目經理的平常工做是溝通而不是作決定

未雨綢繆

• 開發人員交付的是用戶滿意度而不是實際的產品
• 用戶的實際須要會不斷變化
• 前進兩步，後退一步，維護會增長系統的複雜性和引入新的Bug

干將莫邪

• 項目成員要使用通用開發工具

總體部分

• 有時必須推翻頂層，從新開始

禍起蕭牆

• 項目進度的落後是潛移默化的，所以必須設置階段目標

另一面

• 文檔很重要，不論程序員仍是用戶
• 自文檔化技術，文檔編寫要和源代碼結合起來，文檔以註釋的形式存在

附上電子書連接：連接：http://pan.baidu.com/s/1bBfHk6 密碼：cowm