老師推薦了這本書人月神話，剛開始以為是一本小說，后來閱讀之后才發現自己想錯了，人月是指在估計和進度安排中使用的工作量單位。
作者在書中介紹了焦油坑的概念，提出在過去幾十年的大型系統開發就猶如一個焦油坑。各種團隊，大型的、小型的，龐雜的和精干的，一個接一個淹沒在焦油坑中。表面上看起來好像沒有任何一個單獨的問題會導致困難，每個都能被解決，但是當它們相互糾纏和累計在一起的時候，團隊的行動就會變得越來越慢。
作者從編程系統產品、職業的樂趣和職業的苦惱方面讓我們認識了軟件開發這個職業以及充滿在這個職業中的樂趣與 苦惱。簡單的程序已經不能稱作系統，編程系統和編程產品稱為編程系統產品。它的成本高達九倍。只有編程系統產品才是真正有用的產品，是大多數系統開發的目標。樂趣是任何職業都不能缺少的，只有有了樂趣才會有動力，才會有創造力。雖然現在我們對於軟件開發沒有很清楚的概念，但是我們也應該充滿一種好奇心和一種樂趣，體會其中魔術般的力量。苦惱是必不可少的，我們應正確看待這些煩惱。
作為一名軟件工程的學生，我們雖然編的軟件不多，但是也有一些自己的理解，我們享受編程的樂趣，享受成功的喜悅，但同時也有苦惱，查不出bug,想不到方法，都是我們的苦惱。
Brooks法則：向進度落后的項目中增加人手，只會使進度更加落后。
進度問題是項目管理最為關注的問題。項目的時間依賴於順序上的限制，人員的數量依賴於單個子任務的數量。
在眾多軟件項目中，缺乏合理的時間進度是造成項目滯后的最主要的原因。文章分析了幾個原因。樂觀主義：所有的編程人員都是樂觀主義。人月：用人月作為衡量一項工作的規模是一個危險和帶有欺騙性的神話。系統測試：在早期進度策划時，允許充分的系統測試時間是非常重要的。空泛的估算。重復產生的災難。
通過此部分，我看到了在軟件開發中會出現的一系列問題。這些問題發現了，我們就應該時刻注意，及時解決。而不應該拖拖拉拉。
在軟件開發過程中，小組之間要有明確的分工。由一個人來進行問題的分解，其他人給予他所需要的支持，以提高效率和生產力。小組成員之間要進行及時的溝通。
作者認為概念完整性應該是最重要的考慮因素。概念的完整性要求設計必須由一個人，或者非常少數互有默契的人員來實現。不能與系統基本概念進行整合的良好想法和特色，最好放到一邊，不予考慮。在外部說明完成之前，設計實現人員有很多事情可以做。只要有一些最終將並入外部說明的系統功能雛形，他就可以開始了。文中簡要說明了設計實現人員的工作流程，給我們以后學習工作提供了一個向導。
開發第二個系統所引起的后果。項目經理必須堅持至少擁有兩個系統以上開發經驗結構師的決定。同時，保持對特殊誘惑的警覺，他可以不斷提出正確的問題，確保原則上的概念和目標在詳細設計中得到完整的體現，以避免畫蛇添足。
假設一個項目經理已經擁有行事規范的結構師和許多編程實現人員，那么他如何確保每個人聽從、理解並實現結構師的決策？對於一個由1000人開發的系統，一個10個結構師的小組如何保持系統概念上的完整性？要有文檔化的規格說明—手冊，形式化定義，直接整合，會議和大會，多重實現，電話日志，產品測試，這些內容在《軟件工程概論》中也有相關的介紹。
交流的至關重要。團隊之間要通過所有可能的途徑進行相互之間的交流溝通。交流和交流的結果—組織，是成功的關鍵。交流和組織的技能需呀管理者仔細考慮，相關經驗的積累和能力的提高同軟件技術本身一樣重要。
實踐是最好的老師，但是，如果不能從中學習，再多的實踐也沒有用。系統編程需要花費多長的時間？需要多少的工作量？如何進行估計？作者對幾個數據進行了分析，我們應從數據中學習，在實踐中總結，做到胸有成竹，這樣才會提高效率和生產力。
作為成本的程序空間：由於規模是軟件系統產品用戶成本中如此大的一個組成部分，開發人員必須設置規模的目標，控制規模，考慮減小規模的方法。規模控制。空間技能。數據的表現形式是編程的根本。在軟件開發中，我們要盡量減小規模，減少成本，擴大空間。
文檔是很好的工具。書面計划是精確和可以溝通的。平時學習中，我們並不重視文檔的書寫，看完這張，意識到了文檔的重要性，以后要加強文檔的規范化。
文檔。雖然太多的書籍都強調文檔的重要性，但是在實際操作中它又發揮了多大的作用呢！書中提到流程圖，流程圖的使用本來應該在開發前畫，但是很多流程圖都是在開發結束后需要文檔才畫上的。這樣做也許會對維護人員有幫助，但是維護人員真的會看嗎？我覺得有少部分關鍵文檔的確非常重要，大部分文檔只是為寫文檔而寫。
人月神話為什么能暢銷30年。的確如書中所說，其實他只是以某個項目為起點來展開軟件工程的實際開發中的原理。大學的教科書：軟件工程，計算機原理，編譯原理等書籍都至少采用了10年，而其他的java語言等只是這2年才開課的。計算機技術的確變化很快，某些原理卻並沒有發生大的變化。
總之，一句話，這本書讓我對軟件工程有了全新的認識。