人月神話讀後感03

2022-10-11 14:15:10 字數 607 閱讀 2388

今天讀完人月筆記,但是也只是粗略的閱讀過一遍,好書要細品,可能是我還沒有參與過一次真正的專案吧,書中其實很多東西我沒有太深的理解,很多都是僅限於我知道了,以後盡量注意,還沒有有著深刻的認知。

**下我理解的一部分,首先便是交流,書中也說「交流與交流的結果--組織,是成功的關鍵」,交流是團隊必不可少,甚至可以說是貫徹到底的一件事,團隊沒有交流的話,那麼專案是百分百做不出來的,

而對於團隊交流這件事來說,我真挺不熟悉的,因為目前還沒有過團隊的交流,最近所做的結對作業,也是沒有任何交流的,就只是自己在做而已,完全不去關心結對的一位隊友,其實也挺想交流,但一想確實沒什麼可交流的,一是感覺已經脫軌一段時間了,在交流就有些費勁了,但是在看完人月神話之後,感受還是需要交流的,要一點點養成這樣的習慣。

還有時間與人數數量大多時候是不能相互轉換的,在我看來確實如此,對於完全需要分解的任務,可能會有人數增加減少時間,但是對於軟體開發是不同的,軟體開發之間有著溝通交流,所以人數與時間之間便不會出現替換的情況,甚至於有時候會延長時間。

總之,從焦油坑到最後的二十年的《人月神話》,作者在書中講述了很多經驗,只是目前的我所能夠理解並不多,目前的感受都是自己之前有過經歷的。我相信在之後接觸過真正的團隊合作和實戰專案後,對於書中講到的內容,我會有更深的理解。

人月神話讀後感03

專案開發團隊要足夠簡潔。絕大多數大型程式設計系統的經驗顯示出,一擁而上的開發方法是高成本的 速度緩慢的 不充分的,開發出的是無法在概念上進行整合的產品。對於效率和概念的完整性來說,最好由少數幹練的人員來設計和開發,而對於大型系統,則需要大量的人手,以使產品能在時間上滿足要求。這兩方面的矛盾如何調節?...

《人月神話》讀後感03 人月神話

本書第一章提到,過去幾十年的大型系統開發猶如乙個焦油坑,很多大型和強壯的動物在其中劇烈掙扎。各種問題糾結在一起,團隊的行動越來越慢。他們大多開發出了可執行的系統,但只有極少數的專案滿足了目標。究其原因,首先,我們對估算技術缺乏有效的研究,總是假設 一切都將運作良好 但事實往往不是這樣,在我們程式設計...

《人月神話》讀後感

不同的社會經驗,不同的思想狀態,對讀本書的心得也不一樣,我在此說說我的讀後感,書中有許多非常好的觀點,但我只把我感觸最深的寫下來。這確實是一本很值得多次閱讀的好書,每次閱讀可能都能從中得到一些提示。1.外科手術隊伍the surgical team 專案經理在專案的初期必須清楚的估計專案的人月運作模...