今天讀完人月筆記，但是也只是粗略的閱讀過一遍，好書要細品，可能是我還沒有參與過一次真正的專案吧，書中其實很多東西我沒有太深的理解，很多都是僅限於我知道了，以後盡量注意，還沒有有著深刻的認知。
**下我理解的一部分，首先便是交流，書中也說「交流與交流的結果--組織，是成功的關鍵」，交流是團隊必不可少，甚至可以說是貫徹到底的一件事，團隊沒有交流的話，那麼專案是百分百做不出來的，
而對於團隊交流這件事來說，我真挺不熟悉的，因為目前還沒有過團隊的交流，最近所做的結對作業，也是沒有任何交流的，就只是自己在做而已，完全不去關心結對的一位隊友，其實也挺想交流，但一想確實沒什麼可交流的，一是感覺已經脫軌一段時間了，在交流就有些費勁了，但是在看完人月神話之後，感受還是需要交流的，要一點點養成這樣的習慣。
還有時間與人數數量大多時候是不能相互轉換的，在我看來確實如此，對於完全需要分解的任務，可能會有人數增加減少時間，但是對於軟體開發是不同的，軟體開發之間有著溝通交流，所以人數與時間之間便不會出現替換的情況，甚至於有時候會延長時間。
總之，從焦油坑到最後的二十年的《人月神話》，作者在書中講述了很多經驗，只是目前的我所能夠理解並不多，目前的感受都是自己之前有過經歷的。我相信在之後接觸過真正的團隊合作和實戰專案後，對於書中講到的內容，我會有更深的理解。
人月神話讀後感03
專案開發團隊要足夠簡潔。絕大多數大型程式設計系統的經驗顯示出，一擁而上的開發方法是高成本的 速度緩慢的 不充分的，開發出的是無法在概念上進行整合的產品。對於效率和概念的完整性來說，最好由少數幹練的人員來設計和開發，而對於大型系統，則需要大量的人手，以使產品能在時間上滿足要求。這兩方面的矛盾如何調節？...
《人月神話》讀後感03 人月神話
本書第一章提到，過去幾十年的大型系統開發猶如乙個焦油坑，很多大型和強壯的動物在其中劇烈掙扎。各種問題糾結在一起，團隊的行動越來越慢。他們大多開發出了可執行的系統，但只有極少數的專案滿足了目標。究其原因，首先，我們對估算技術缺乏有效的研究，總是假設 一切都將運作良好 但事實往往不是這樣，在我們程式設計...
《人月神話》讀後感
不同的社會經驗，不同的思想狀態，對讀本書的心得也不一樣，我在此說說我的讀後感，書中有許多非常好的觀點，但我只把我感觸最深的寫下來。這確實是一本很值得多次閱讀的好書，每次閱讀可能都能從中得到一些提示。1.外科手術隊伍the surgical team 專案經理在專案的初期必須清楚的估計專案的人月運作模...