「史前史中，沒有別的場景比巨獸門在焦油坑中垂死掙扎的場面更令人震撼。上帝見證著恐龍、猛獁象、劍齒虎在焦油中掙扎。它們掙扎得越猛烈，焦油糾纏得就越緊，沒有哪種猛獸足夠強壯或具有足夠的技巧，能夠掙脫束縛，它們最後都沉到了坑底。」------《人月神話》
在軟體開發中，人月是個工作量的單位，在大多數人的眼中，增加人，那麼月數就會減少。確實，在某些繁重的體力勞動中，人數越多，意味著完工時間越短。可是，軟體開發是個腦力勞動，而且軟體開發是連續性的、互動性的，每個階段、每個部分都是要溝通、要互動的。人數越多，意味著溝通的過程是原來的很多倍，這會導致專案延期，協調是個大問題。這時候就有人說，我只需要乙個小型團隊，裡面的都是精英人才，這樣就行了。這樣真的可以嗎？也許開發小型的專案是可以的，但是對於開發像系統那樣的大型專案，即使你1個人能頂7個人，那麼也需要至少10年的時間才能夠開發出來。乙個產品在提出來之後10年才真正上市，這還不算維護，在現在這種資訊快速發展的時代，這款產品還有人要嗎？是不是過時了呢？
《人月神話》中提到了外科手術團隊，即乙個團隊擁有一名外科醫生（首席程式設計師），一名副手（能完成一部分工作，但經驗少），乙個管理員（boss），乙個編輯(負責對文件進行分析和重新組織並提供資訊)，兩個文秘（管理員和編輯各乙個），程式職員，工具維護人員，測試人員，語言專家（尋求一種簡潔的語言來解決複雜的問題）。這就是10人的乙個團隊。如果要完成更大的專案，那麼就需要擴建，擴建成功依賴這樣乙個事實。決定設計的人員是原來的1/7甚至更少。據書本所說，在實際操作中，這樣的分工具有非常高的效率。
《人月神話》讀後感
不同的社會經驗，不同的思想狀態，對讀本書的心得也不一樣，我在此說說我的讀後感，書中有許多非常好的觀點，但我只把我感觸最深的寫下來。這確實是一本很值得多次閱讀的好書，每次閱讀可能都能從中得到一些提示。1.外科手術隊伍the surgical team 專案經理在專案的初期必須清楚的估計專案的人月運作模...
人月神話讀後感
人月神話 這本書風行已經很久了，寫成於1975年，經歷這麼久的時間，在當前又重新流行，讓我很驚訝,但是一直沒有時間讀。今天突然想起自己的機器上有本拷貝別人的電子書，決定讀讀。我今天只看了兩章，即焦油坑和人月神話。人月神話看上去這麼浪漫的名字，原來並不是真的說神話故事，作者闡述的主要觀點是在軟體開發專...
《人月神話 》讀後感
之前一直聽老師講 人月神話 彷彿這就是乙個傳奇。百聞不如一見，在這本300多頁 中文新版 的神書，在經過了20多年的歷史之後，仍然暢銷不衰，究竟是什麼讓它有如此的魅力？過去的乙個月，一點一滴的閱讀之中算是初步的了解到了它的一部分吧。人月神話的核心觀點 概念完整性和架構師 brooks認為，乙個整潔 ...