利用平時坐公交和火車的碎片時間，把這本書看完了，記得剛學編程時，有很多搞IT的朋友都推薦我看看這本書，這也是我讀這本書的動機，讀完了后也學到了很多軟件開發和項目管理的知識，但是沒有感受到醍醐灌頂的感覺，有些內容還不是很理解，可能是我相關的項目經驗太少的緣故吧，不過既然讀完了，就做一下總結吧，也許等若干年后當我再次讀這本書時，感覺就完全不一樣了。
焦油坑
- 編程系統產品的工作量是獨立開發的程序構件的9倍，構件的產品化是原來開發構件的3倍，構件產品整合到系統中又3倍
人月神話
- 時間進度安排的不合理是項目滯后的最主要原因
- 保質保量開發一個軟件是需要一定的時間的
- 程序員都是樂觀主義者，軟件總會有Bug
- 人員數量和時間無法替換，一個項目滯后以后更多的人來“幫忙”只會更加滯后，軟件開發過程中培訓和溝通交流的時間成本是很高的
- 項目進度安排比例：策劃1/3 1/6編碼 1/4構件測試 1/4系統測試
外科手術隊伍
- 優秀程序員的生產率是一般程序員的10倍
- 小型精干的團隊是最好的
- 對于大型的系統，小型精干的團隊速度太慢了
- 類似外科手術的團隊能很好解決大型系統開發的問題
貴族專制 民主政治和系統設計
- 概念完整性是系統設計中最重要的因素
- 為了保證概念完整性，設計必須由一個人或一個小型的團隊
- 軟件開發要實現設計和具體實現的分離
- 限制和規則能激發創造性
- 概念統一的系統能更快的開發和測試
畫蛇添足
- 不要過分設計
貫徹執行
- 設計必須由一個或兩個人負責，確保設計的一致性
- 具體精確的定義系統和功能
為什么巴比倫塔會失敗
- 失敗的原因：交流
- 團隊應該盡可能多的交流
- 制定良好的工作手冊
- 每一個團隊成員都應該能看到所有材料
- 每個團隊兩個領導，技術負責人和產品負責人
胸有成竹
- 僅僅靠編碼時間乘以系數是無法得到完成時間的
- 小項目的數據不適用于大項目，開發時間隨項目大小呈指數增長
- 使用高級語言的效率是使用匯編語言5倍
削足適履
- 控制規模，精簡系統功能
- 從系統出發，面向用戶
提綱挈領
- 文檔的關鍵，目標，用戶手冊，內部文檔，進度，預算，組織結構圖和工作空間分配
- 為每個關鍵文檔提供狀態監督和語境機制
- 項目經理的職責是使每個人都朝著同一個方向前進
- 項目經理的日常工作是溝通而不是做決定
未雨綢繆
- 開發人員交付的是用戶滿意度而不是實際的產品
- 用戶的實際需要會不斷變化
- 前進兩步，后退一步，維護會增加系統的復雜性和引入新的Bug
干將莫邪
- 項目成員要使用通用開發工具
整體部分
- 有時必須推翻頂層，重新開始
禍起蕭墻
- 項目進度的落后是潛移默化的，因此必須設置階段目標
另外一面
- 文檔很重要，不論程序員還是用戶
- 自文檔化技術，文檔編寫要和源代碼結合起來，文檔以注釋的形式存在
人月神話.png
