《人月神話》這本書是我們老師推薦給我們的，同時老師還推薦給我們另一本書《夢斷**》。由於時間的原因，我只能先選一本書來讀。
這本書裡面的好多觀點，對於今天的軟體工程依然適用。如「沒有銀彈」這個觀點，說明了作者對於軟體工程獨到的見解。身為一名軟體工程的學生，我應當仔細讀完關於
軟體工程的任何一本書。並將觀點與想法運用到實際之中。
作者在第一章中說到，過去幾十年大型系統的開發就像焦油坑一樣，雖然各種各樣的團隊通過努力開發出可執行的系統，但是只有少數的專案可以開發出滿足目標、時間
進度和預算的要求。作者還談到程式設計的樂趣和煩惱。程式設計的樂趣主要是能夠自己創造自己想要的專案。而煩惱是總是難以達到完美。
我在讀到這本書的第二章的時候，就感到作者的見解獨到。brooks先生對人月轉換的觀點進行了詳細的分析，他還指出高層次、尖端的人才和低水平、平庸的工作人員的
工作效率比會是十倍不止，所以說乙個小規模的精銳的團隊往往要比大規模的但是有很多平庸的程式設計師的團隊要好得多。前蘋果公司ceo賈伯斯先生也提出過類似的觀
進而縮短工期。我感覺這道理說的十分正確。
人月神話這一章表達的是對用人月這個單位來計量專案的價值本身是非常不正確的。它看上去好像是人力和時間是可以交換的，就好比遠古時期的部落交換東西時的想法
一樣，這種價值觀 是不正確的。有時候我覺得盲目的增加人員數量只會讓專案落後。所以我們不要相信人月神話，而是通過合理的分析來制定整個專案的進度。
人月神話讀後感（三）
軟體產品易於掌握的特性和不可見性，導致了它的構建人員 特別容易 面臨著永恆的需求變更 正如書中所說，做開發的人員必須要有面對任何變化的心理準備，要隨時有未雨綢繆的準備。提前預想到可能發生的變化才能在變化發生時更加從容的應對。做一些事總比期盼這件事是完美的不變化的要好得多。而且開發人員在後期的系統維護...
《人月神話》讀後感三
使用者的實際需要和使用者的感覺會隨著程式的構建 測試和使用發生變化。維護成本受使用者數目的嚴重影響，使用者越多，發現的錯誤也越多。使專案進度拖後的最大原因不是重要的事件，如新技術 重組等，而是一些瑣碎的小事，每件小事只耽誤半天或一天時間，但這種小事多以後，將使專案的進度嚴重拖後。專案對於公司就如程式...
《人月神話》讀後感（三）
一讀這一章，就讓我感觸頗深，特別是這句話 bell實驗室監控系統專案的提出，關鍵的工作是產品定義。許許多多的失敗完全源於那些產品未精確定義的地方 細緻的功能定義，詳細的規格說明，規範話的功能描述說明以及這些方法的實施，大大減少了系統中必須查詢的bug數量 雖然這句話的意思只是說明精確定義產品將減少b...