第一次看到《人月神話》這本書，若不是老師推薦，還以為是本神話**呢！由於對軟體工程了解的不多，對這本書的解讀不深刻。不過，從很多方面可以了解到這是一本暢銷的、具有深遠意義的書。
這本書講述了幾十年前軟體專案管理問題與經驗，作者將大型系統開發比作乙個焦油坑，我原本以為軟體開發還是比較容易的，有了新想法，就會有新的軟體產品出現，但是卻不知道專案不能滿足目標、進度、預算的要求，就不能成為乙個好專案。
程式，通過不同的途徑轉變成不同的產物，使之變得更有用，成本更高。但是只有變成系統產品才成為真正有用的產品。
程式設計不是人越多越好，人與時間不成正比。人越多，所需的時間不一定越少；人少，專案完成時間不一定越長。在外科手術這一章節中提到，在接受相同的訓練、同樣都是兩年資歷的情況下，優秀專業程式設計師的生產力要比差勁的程式設計師好上十倍。使用少數優秀的人員的團隊是最棒的——盡可能用最少的人。兩人團隊，其中一人當領導者，這通常是最佳的用人方式。以少數優秀人員的團隊開發真正大的系統就太慢了。絕大多數大型軟體系統的經驗顯示，使用一堆人蠻幹的方式最耗成本、最慢、最沒有效率，做出來的系統在概念上也最不完整。
作者主張概念完整性在系統設計中是最重要的考慮因素，他以os/360系統的開發證明了自己的觀點。完整的概念使得系統設計過程更加有條理，分工更加明確，對系統的各部分設計更加明確，再出現錯誤時更加容易的去改正。
書中講到了開發第二個系統所帶來的後果，在開發第乙個系統時結構師傾向於精煉和簡潔，他會仔細謹慎地工作。第二個系統是設計師們所設計最危險的系統。曾在第一次系統中被小心謹慎地放在次要位置的向系統中新增很多修飾功能和想法將會氾濫。os/360的設計小組成員來自1410-7010磁碟作業系統、stretch作業系統、mercury實時系統專案和7090的ibsys，幾乎沒有人有兩次以上的作業系統經驗，os/360是典型的開發第二次所引起的後果。結構師無法跳過第二次系統，但他可以有意識的關注這個系統的特殊危險，運用自我約束規則避免功能上的過於修飾，根據系統基本理念及目的變更，捨棄一些功能。這些對於每乙個軟體學習者都是很受用的。
「經驗是最好的老師」、」經驗是最好的老師，但智者還能從其他的地方有所收穫「，經驗固然最好，但是除了經驗，我們還要學還從其他方面獲取知識。
在這本書中，雖然講述了很多案例，但都離不開團隊、人和溝通。無論任何事情，人的重要性，人之間的溝通都是不可缺少的。在軟體開發中，對於大型的軟體工程專案仍然強調了人的重要性。作者在開篇就在講開發人員的職業樂趣（自己選擇軟體工程的原因也是喜歡編出程式的樂趣），後面又通過巴比倫塔講溝通的重要性，又在外科手術隊伍中講團隊的組建和分工。這些都涉及到了團隊中的人和互動，只有乙個有了積極心態和熱情的溝通團隊，才可能成就乙個偉大的團隊。最後的沒有銀彈再次肯定了開發工作是一種高智力的腦力工作。
我認為《人月神話》這本書十分適合軟體程式設計者，雖然他簡述了許多幾十年前的事，但對於現在，仍具有教育意義，它使我們提前意識到軟體開發過程中的一些弊端。
《人月神話》讀後感
不同的社會經驗，不同的思想狀態，對讀本書的心得也不一樣，我在此說說我的讀後感，書中有許多非常好的觀點，但我只把我感觸最深的寫下來。這確實是一本很值得多次閱讀的好書，每次閱讀可能都能從中得到一些提示。1.外科手術隊伍the surgical team 專案經理在專案的初期必須清楚的估計專案的人月運作模...
人月神話讀後感
人月神話 這本書風行已經很久了，寫成於1975年，經歷這麼久的時間，在當前又重新流行，讓我很驚訝,但是一直沒有時間讀。今天突然想起自己的機器上有本拷貝別人的電子書，決定讀讀。我今天只看了兩章，即焦油坑和人月神話。人月神話看上去這麼浪漫的名字，原來並不是真的說神話故事，作者闡述的主要觀點是在軟體開發專...
《人月神話 》讀後感
之前一直聽老師講 人月神話 彷彿這就是乙個傳奇。百聞不如一見，在這本300多頁 中文新版 的神書，在經過了20多年的歷史之後，仍然暢銷不衰，究竟是什麼讓它有如此的魅力？過去的乙個月，一點一滴的閱讀之中算是初步的了解到了它的一部分吧。人月神話的核心觀點 概念完整性和架構師 brooks認為，乙個整潔 ...