人月神話這本書大致講述的是在程式專案過程中的管理及安排等。作者認為，在很多方面，管理乙個大型的計算機程式設計專案和其它行業的大型工程很相似——比大多數程式設計師所認為的還要相似；在很多另外的方面，它又有差別——比大多數職業經理所認為的差別還要大。《人月神話》這本書就是圍繞此展開的。
其實感覺這幾部老師讓看的書都大同小異。每個書又有每個書的特點。
從有程式專案伊始，大多數團隊都開發出了可執行的系統。不過，其中只有非常少數的專案滿足了目標、時間進度和預算的要求。軟體開發這個職業就是這樣，大型專案必須要有多人參與。當出現了一些錯誤，每個人的看法不同。這就導致了問題解決的的比較緩慢。這就與下面的「外科醫生」板塊相呼應。外科手術就是說，大型專案的每乙個部分由乙個團隊解決，但是該隊伍以類似外科手術的方式組建，而並非一擁而上。也就是說，同每個成員擷取問題某個部分的做法相反，由乙個人來進行問題的分解，其他給予他所需要的支援，以提高效率和生產力。這樣就解決了問題的解決問題。只有乙個人才可以決定大局，這樣事情就變得簡單起來。乙個人下達命令，其他人跟從指令工作，工作層層遞進的安排下去，每個人管自己的區域，這樣專案才可以有序的執行。
在眾多軟體專案中，缺乏合理的時間進度是造成專案滯後的最主要原因，它比其他所有因素加起來的影響還大。而導致這種普遍性災難的原因有五點：
首先，我們對估算技術缺乏有效的研究，更加嚴肅地說，它反映了一種悄無聲息，但並不真實的假設——一切都將運作良好。
第二，我們採用的估算技術隱含地假設人和月可以互換，錯誤地將進度與工作量相互混淆。
第三，由於對自己的估算缺乏信心，軟體經理通常不會有耐心持續地進行估算這項工作。
第四，對進度缺少跟蹤和監督。其他工程領域中，經過驗證的跟蹤技術和常規監督程式，在軟體工程中常常被認為是無謂的舉動。
第五，當意識到進度的偏移時，下意識（以及傳統）的反應是增加人力。這就像使用汽油滅火一樣，只會使事情更糟。越來越大的火勢需要更多的汽油，從而進入了一場注定會導致災難的迴圈。
當專案告急，增加人手並不是乙個好的選擇，新安排的人還需要了解專案，進行培訓，這個時間投入是沒有必要的。因為軟體開發本質上是一項系統工作——錯綜複雜關係下的一種實踐——溝通、交流的工作量非常大，它很快會消耗任務分解所節省下來的個人時間。從而，新增更多的人手，實際上是延長了，而不是縮短了時間進度。應該在專案之前就對專案的安排時間作出規劃。書中作者建議1/3 計畫，1/6 編碼，1/4 構件測試和早期系統測試，1/4 系統測試，所有的構件已完成。這樣能更好的進行專案的實踐。
專案的怎麼才能完整？乙個人乙個想法也不行。概念的完整性要求設計必須由乙個人，或者非常少數互有默契的人員來實現。概念的完整性的確要求系統只反映唯一的設計理念，使用者所見的技術說明來自少數人
的思想。實際工作被劃分成體系結構、設計實現和物理實現，但這並不意味著該開發模式下的系統需要更長的時間來建立。經驗顯示恰恰相反，整個系統將會開發得更快，所需要的測試時間將更少。同工作的水平分割相比，垂直劃分從根本上大大減少了勞動量，結果是使交流徹底地簡化，概念完整性得到大幅提高。
《人月神話》讀後感
不同的社會經驗，不同的思想狀態，對讀本書的心得也不一樣，我在此說說我的讀後感，書中有許多非常好的觀點，但我只把我感觸最深的寫下來。這確實是一本很值得多次閱讀的好書，每次閱讀可能都能從中得到一些提示。1.外科手術隊伍the surgical team 專案經理在專案的初期必須清楚的估計專案的人月運作模...
人月神話讀後感
人月神話 這本書風行已經很久了，寫成於1975年，經歷這麼久的時間，在當前又重新流行，讓我很驚訝,但是一直沒有時間讀。今天突然想起自己的機器上有本拷貝別人的電子書，決定讀讀。我今天只看了兩章，即焦油坑和人月神話。人月神話看上去這麼浪漫的名字，原來並不是真的說神話故事，作者闡述的主要觀點是在軟體開發專...
《人月神話 》讀後感
之前一直聽老師講 人月神話 彷彿這就是乙個傳奇。百聞不如一見，在這本300多頁 中文新版 的神書，在經過了20多年的歷史之後，仍然暢銷不衰，究竟是什麼讓它有如此的魅力？過去的乙個月，一點一滴的閱讀之中算是初步的了解到了它的一部分吧。人月神話的核心觀點 概念完整性和架構師 brooks認為，乙個整潔 ...