人月神話讀后感（通用5篇）
當閱讀完一本名著后，相信大家一定領會了不少東西，何不靜下心來寫寫讀后感呢？為了讓您不再為寫讀后感頭疼，以下是小編為大家收集的人月神話讀后感，僅供參考，希望能夠幫助到大家。
人月神話讀后感 篇1
最近讀了一本書《人月神話》，這本書是軟件工程類的一本經典著作。閱讀這本書的第一感受就是感覺這本書不像是一種和學習相關的書，更像是用很多形象的比喻，闡述項目管理當中的一些問題，讓讀者能夠很輕松，明白的去閱讀。
一般在大學學習計算機行業的時候，都會學習一門叫做軟件工程的課程，老師也會跟我們講一些關于“軟件項目開發的完成與增加人員的問題”，在讀這本書的時候，這個問題給了我很大的感觸。很多人認為，當任務在規定期限內還完成不了的時候，適當的加一些人員進去，可以加快任務的進度，從而能夠在規定的時間完成任務。但是這個觀點在軟件工程當中是不適用的。這也是我在閱讀完《人月神話》這本書時最大的感受。
這本書的第二章就講述了人月神話的關系，完成工作的人數和時間是不能進行簡單的互換的。因為新加入的人對原有的項目不了解，需要花時間培訓，讀后感交流，同時新人也有可能對原有的設計有不同的意見，這些都會導致任務的進度大打折扣。“向進度落后的項目中增加人手，只會使進度更加落后”，是這本書作者布魯克斯得到的結論。
我覺得開發一個軟件，要有合理的時間進度安排，項目開發的人員少而精，團隊開發之前要提前交流，開發的時候要持續的溝通，合理的分配任務工作。所有只有在一個團隊溝通了解，通力協作和努力下，才能更好的完善項目。
人月神話讀后感 篇2
《人月神話》這本書風行已經很久了，寫成于1975年，經歷這么久的時間，在當前又重新流行，讓我很驚訝,但是一直沒有時間讀。今天突然想起自己的機器上有本拷貝別人的電子書，決定讀讀。我今天只看了兩章，即焦油坑和人月神話。
人月神話看上去這么浪漫的名字，原來并不是真的說神話故事，作者闡述的主要觀點是在軟件開發項目上項目進度和增加人員這兩個概念是不能互換。雖然已經時隔20多年了，這本書依然給我震撼，一是讓我驚訝的是，美國20年前軟件項目所面臨的問題，在我們現在依然如此，糟糕的情況沒有改變，大家仍舊在焦油坑里掙扎，而且看上去沒有解決辦法。二是作者對軟件項目失敗的總結，每一個問題我們依舊再犯，特別讀到“是當意識到進度的偏移時，下意識（以及傳統）的反應是增加人力。
這就像使用汽油滅火一樣，只會使事情更糟。越來越大的火勢需要更多的汽油，從而進入了一場注定會導致災難的循環。“，我對這句話簡直是太有感觸了，因為我身邊這樣的悲劇整天都在上演，公司對所有的項目搞得都是人海戰術，進度沒有提前，還整天加班，最后用戶不滿意，開發人員整天郁悶，結果是用戶對公司失去了信任，成了一槌子買賣，開發人員就像割韭菜，舊人一一辭職，新人天天引進，公司何談發展和積累，做了n年，濤聲依舊，做法沒有改變，情況沒有改觀，公司沒有發展，好在中國人多地大，呼悠完一個行業，再呼悠另一個行業。三是作者在那個時候，就根據自己的經驗提出了對于軟件任務的進度安排，以下是作者使用了很多年的經驗法則：1/3計劃1/6編碼1/4構件測試和早期系統測試1/4系統測試，所有的構件已完成我們公司是通過cmm3認證的，理論不用我說，大家好像都明白，實際情況呢，有誰真的拿出那么多時間作計劃，又有誰拿出那么多時間作測試，不過令人欣慰的是，大家確實在向這方面改變，比如我們公司測試部現在就是一個很大很關鍵的部門，所有的程序發布都需要測試人員的簽字。
當然，也許可以找點客觀原因，比如現在國內多數客戶不成熟，簽單子靠關系，一旦簽了又恨不得明天就正式運行，但是本著“沒有任何借口”的觀點，我們該怎樣改進呢，我決定讀下去，看看能否找到作者所說的銀彈呢。
人月神話讀后感 篇3
當我捧起《人月神話》，馬上就被深深的吸引了。書中很多細微之處都對我的思維造成了沖擊。已經很久沒有看到這么好的書了，鄭重推薦。
把感觸比較深的幾點記下來，順便整理一下自己的思路，與大家分享。
1，保持設計的概念完整。無論對小軟件還是大軟件，都必須由一個設計師主導，最多兩個人討論來共同完成軟件的整體設計。作為一個軟件，一個系統，必須有一個清晰明確的概念模型，大家都在這個框架下工作，所有的創新發展都必須與基本的概念相吻合。具體的實現人員可以細化概念，但只有總設計者才有否定與發展基本概念的權力。需要注意的一點是，即使是總設計師一直是同一個人，他腦海中所認為理所當然的規則或者概念，很可能由于沒有明確的文檔化，而沒有成為所有開發者共同的概念。在其他開發者編碼的時候，就可能會生成與概念相抵觸的東東（模塊，功能，算法），導致整體結構的惡化。這個時候總設計師一定要即時發現，做出更正。
概念的完整性，對于很多小規模軟件，由于開發人員不多，開發經理一般都能控制住所有的代碼，概念完整性在組織層面就維持住了。但要注意以后的Bug修改，功能擴展的時候，也要時刻留意與最初的設計是否概念上相容。對于大規模的軟件系統，則必須通過樹狀組織結構，層層控制，總設計師還是一到兩人，每一層都有對下層的絕對把握能力。我以前參加過一個15人左右的項目組，就是分為兩層。感覺整體概念完整性的控制效果還不錯。我沒有更多人數項目的具體實踐經驗，希望以后能有機會參與比較大的項目。
2，“一個拿2倍工資的人，生產率可能是其他人的10倍。”我和我的同學，一個小公司的技術總監聊起這個，他也是十分的認同。不知道其他公司的程序員們如何看。我的同事中有一個牛人，做出的貢獻特別大，應該相當于我們公司普通的十個程序員，不過工資最多也就是普通程序員的二倍。是不是有些不公平呢？我也說不清楚。因為那些普通程序員也十分的努力。不過，我覺得，作為公司，應該給最好的人最好的待遇，或者說給比目前更高的待遇。
組建一個團隊，最好的就是那種精英團隊，大家都是牛人，效率會特別高。微軟就是這種思路吧，把最聰明的人集中在一起，想不都難亞。
3，進度落后與增加人力。記得當年看《C＋＋編程思想》，Bruce說“十個婦女不能在一個月內生下小孩”（大意），于我心有戚戚焉。而本書作者Brooks得出的結論是對我是震撼性的：“向進度落后的項目中增加人手，只會使進度更加落后”。
以前，增加人手基本是挽救進度落后項目的主要辦法。這個辦法行不通的話，難道只有“加班”一條路了？但長期加班是對個人的摧殘，我更愿意利用業余時間去看書，例如看這本“人月神話”。）
如果不想加班，不想削減功能，不想推遲發布日期，那么……唯一的`方法還是只有…加人。加足夠的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能對原來的組織造成沖擊，或者對原來的設計有不同意見（特別是加入的人中有比較強大的設計者）。那么，就當作，新組建了一個團隊吧。交流，培訓新人，就設計達成一致，繼續向者目標前進。
感觸還有很多，以后如果有機會再寫。不過，我決定去買本英文版回來，收藏，以后再多看幾次。
人月神話讀后感 篇4
人月神話這本書幾年前就聽別人說是本很經典的軟件開發方面的書，這本書的成功之處在于他思想的前衛性，以至于不只是軟件行業的人在讀。現在終于找到讀他的理由了，可以感受一下大師的杰作。在讀之前我已經讀過了軟件工藝和極限編程，為什么留到最后讀人月神話呢？主要是因為我覺得一本能夠流傳30年還被人們津津樂道的書，肯定是本學要好好細讀的書，所以留到了最后。按照前兩篇讀書筆記的慣例，前面幾段是一些我讀書時的感受和收獲，還有一些對內容的評價。
從這本書的內容來看，對于一個項目經理來說肯定會有更大的收獲，這本書主要是針對軟件開發管理方面的內容，這主要原因可能是因為作者以前就是項目的管理者，他是站在管理者的角度寫的。即便這樣，對于一個從來沒有參與過真實項目開發，更沒有領導過團隊的我還是有一定的吸引力，這本書中我最喜歡的就是前四章（焦油坑、人月神話、外科手術隊伍、貴族專制、民主政治和系統設計）和沒有銀彈這章。這本書里面為了論證某一觀點，會舉出許多實際的項目作為證據，這一點非常好，事實勝于雄辯嘛！這些例子也許對于作者那個年代的人來說很好理解，但是放在30年后來看這些例子又有些陳舊和難懂了。另外，從文中我發現作者非常注重文檔，一個優質的文檔就是項目成功的保證，這一點與傳統的軟件工程很相似，但是卻與極限編程的觀點相悖。
人月神話讀后感 篇5
《人月神話》是預言了未來還是扼制了未來?
事實是：我們目前的許多工程知識，——無論是從書上看到的，還是從實踐中經驗到的——大多未曾脫離《人月神話》之所言，人月神話讀后感。
我在開篇中說《人月神話》“是一本可怕的書”。然而我感受懇摯的可怕之處在于：現今凡是論及工程(且不要讓人感受是離經叛道)，那么所解說的定然是Brooks的這么的經驗以及由此推出的見解，可能在不違拗這些經驗和見解上的一些翔實的實作措施!我們全然不顧書中所言是假象，還是性質的推論，可能只是假象歸納的一個(未必準確的)答案。盡管這些答案大多數時候都好像預期地展目前你的切實工程中：
原文中還有眾多相仿的見解、假象和答案，都成為了切實工程中的既存假象。先民們所說的圣人以及通神者，皆因他們多數時候在準確地預言自己的切實。只有當這個“多數時候”變成半點的時候，先民們才會置疑圣人和通神者的力氣。其實我們懂得并未曾預言未來的人，大多數時候是兩種情形導致的假象。
【人月神話讀后感（通用5篇）】相關文章：
《中外神話故事》讀后感11-19
《希臘神話故事》讀后感07-25
《中國神話故事》讀后感范文11-05
中國古代神話讀后感15篇03-18
少兒神話故事06-16
考試“神話”_650字01-25
神話高二作文08-20
希臘神話作文03-01
中國神話故事08-29
新人月度工作計劃03-21