人月神話的讀后感
人月神話這本書幾年前就聽別人說是本很經典的軟件開發方面的書，這本書的成功之處在于他思想的前衛性，以至于不只是軟件行業的人在讀�，F在終于找到讀他的理由了，可以感受一下大師的杰作。在讀之前我已經讀過了軟件工藝和極限編程，為什么留到最后讀人月神話呢？主要是因為我覺得一本能夠流傳30年還被人們津津樂道的書，肯定是本學要好好細讀的書，所以留到了最后。按照前兩篇讀書筆記的慣例，前面幾段是一些我讀書時的感受和收獲，還有一些對內容的評價。
從這本書的內容來看，對于一個項目經理來說肯定會有更大的收獲，這本書主要是針對軟件開發管理方面的內容，這主要原因可能是因為作者以前就是項目的管理者，他是站在管理者的角度寫的。即便這樣，對于一個從來沒有參與過真實項目開發，更沒有領導過團隊的我還是有一定的吸引力，這本書中我最喜歡的就是前四章（焦油坑、人月神話、外科手術隊伍、貴族專制、民主政治和系統設計）和沒有銀彈這章。這本書里面為了論證某一觀點，會舉出許多實際的項目作為證據，這一點非常好，事實勝于雄辯嘛！這些例子也許對于作者那個年代的人來說很好理解，但是放在30年后來看這些例子又有些陳舊和難懂了。另外，從文中我發現作者非常注重文檔，一個優質的文檔就是項目成功的保證，這一點與傳統的軟件工程很相似，但是卻與極限編程的觀點相悖。下面就是一些讀書的總結了。
焦油坑
1。 編程系統產品開發的工作量是供個人使用的、獨立開發的構件程序的九倍。
2。 編程行業的一些內在固有苦惱：
l 將做事方式調整到追求完美，是學習編程的最困難部分。
l 由其他人來設定目標，并且必須依靠自己無法控制的事物。
l 真正的權威來自于每次任務的完成。
l 任何創造性活動都伴隨著枯燥艱苦的勞動，編程也不例外
l 人們通常期望項目在接近結束時（bug、工作時間）能收斂得快一些，然而軟件項目的情況卻是越接近完成，收斂得越慢。
l 產品在即將完成時總面臨著陳舊過時的威脅。 人月神話 1。 缺乏合理的時間進度是造成項目滯后的最主要原因，它比其他所有因素加起來影響還大。
2。 良好的烹飪需要時間，某些任務無法在不損害結果的情況下加快速度。
3。 我們的構思是有缺陷的，因此總會有bug。
4。 我們圍繞成本核算的估計技術，混淆了工作量和項目進展。人月是危險和帶有欺騙性的神話，因為它暗示人員數量和時間是可以相互替換的`。
5。 在若干人員中分解任務會引發額外的溝通工作量--培訓和相互溝通。
6。 關于進度安排，作者的經驗是為1/3計劃、1/6編碼、1/4構件測試以及1/4系統測試。
7。 因為我們對自己的估計技術不確定，所以在管理和客戶的壓力下，我們常常缺乏堅持的勇氣。
8。 brook法則：向進度落后的項目中增加人手，只會使進度更加落后。
9。 向軟件項目中增派人手從三個方面增加了項目必要的總體工作量：任務重新分配本身和所造成的工作中斷；培訓新人員；額外的相互溝通。 外科手術隊伍 1。 同樣有兩年經驗而且在受到同樣的培訓的情況下，優秀的專業程序員的工作效率是較差程序員的十倍。關于這一條我在極限編程里看到，sackman和humphrey分別做了實驗發現優秀程序員工作效率比較差程序員的工作效率最高要高達28倍。
2。 小型、精干隊伍是最好的。這一點在軟件工藝和極限編程里都得到了充分的體現。
3。 兩個人的團隊，其中一個項目經理，常常是最佳的人員使用方法。
4。 對于真正意義上的大型系統，小型精干的隊伍太慢了。
5。 實際上，絕大多數大型編程系統的經驗顯示出，一擁而上的開發方法是高成本、速度緩慢、不充分的，開發出的產品無法進行概念上的集成。
6。 一位首席程序員、類似于外科手術隊伍的團隊架構提供了一種方法，既能獲得由少數頭腦產生的產品完整性，又能得到多位協助人員的總體生產率，還徹底地減少了溝通的工作量。圖1是10人的程序開發隊伍溝通模式。 圖1 10人程序開發隊伍溝通模式
貴族專制、民主政治和系統設計 1。 概念完整性是系統設計中最重要的考慮因素。
2。 為了獲得概念完整性，設計必須由一個人或者具有共識的小型團隊來完成。
3。 對于非常大型的項目，將設計方法、體系結構方面的工作與具體實現相分離是獲得概念完整性的強有力方法。
4。 紀律、規則對行業是有益的。外部的體系結構規定實際上是增強，而不是限制實現小組的創造性。
5。 體系結構、設計實現、物理實現的許多工作可以并發進行。 畫蛇添足 1。 盡早交流和持續溝通能使結構師有較好的成本意識，以及使開發人員獲得對設計的信心，并且不會混淆各自的責任分工。
2。 結構師如何成功地影響實現：
i。 牢記是開發人員承擔創造性的實現責任；結構師只能提出建議。
ii。 聽取開發人員在體系結構上改進的建議。
3。 第二個系統是人們所設計的最危險的系統，通常的傾向是過分地進行設計。關于這一點也許是正確的，但是這是一個回避不了的問題，如果沒有開發第二個系統經驗的人，就不可能有開發第三個系統經驗的人了。 貫徹執行 1。 即使是大型的設計團隊，設計結果也必須由一個或兩個人來完成，以確保這些決定是一致的。
【人月神話的讀后感】相關文章：
人月神話讀后感參考04-12
希臘神話讀后感04-10
《希臘神話》讀后感04-10
蘇菲的世界神話讀后感05-14
西西弗神話讀后感05-08
西西弗的神話讀后感11-23
《神話少年》讀后感作文08-30
締造蘋果神話讀后感03-28
希臘羅馬神話讀后感06-15