《人月神話》是大學剛開始就很熟悉的一本書，當時被奉為軟體工程的聖書，似乎都要在書架上擺上它才能表明軟體工程學生的身份。時至今日我再讀它，因為有了之前參與系統的開發的經驗，很多的內容都通過記憶得到了驗證，讀來與大一時的「雖然不懂你在講什麼但好像很有道理」 的體會有了明顯的不同。這裡選擇一些感觸較深的章節寫一些自己的理解。
焦油坑入坑前，都會覺得自己戰無不勝，就像陷入焦油坑的巨獸，自以為有著龐大的身軀就能在各種的地形中安然度過。在填寫志願的時候，對未來充滿希望的孩子們還不知道自己將面臨什麼，只覺得**的世界奇妙酷炫，然而**對於軟體系統的開發來說只是水面上的冰山。前人的智慧型告訴我們如果沒有認真地進行分析、設計、進度計畫，真正開始開發後總會讓自己陷入令人痛苦的麻煩。事實上，這種麻煩在我前期做過的絕大多數專案中都出現了，但是當你咬著牙從中脫身，還是會體驗到創造與實現的快樂，通過這些經歷和課程學習，我也慢慢能總結歸納經驗教訓，讓自己今後能盡量少地陷入這樣的「焦油坑」中。
人月神話
軟體開發中最難掌握的莫過於過程管理，最開始的課程專案規模都很小，自己小作坊式的開發方式似乎也能很好完成要求，然而越到後來，專案規模越大，參與的人越多，開發進度的估計似乎成了一門玄學，每個人的能力不同，擅長的方面不同，開發中可能遇到的問題也不可**，往往都是快到截止日期時集體趕工。我實習期間最深刻的印象正是來自於開發團隊在每乙個迭代開始前的計畫方式。我們做完上一迭代的回顧後會討論上一次的任務劃分是否合理，時間分配是否過少或過多，然後根據產品經理對這一迭代的模組劃分每個人獨立進行開發測試的消耗估計。通過團隊成員的集體商議確定模組需要的花費後，去除與上一迭代相比過多消耗的模組，結束後會寫下來貼在白板上由每個人自由領取任務。這個過程是開發團隊結合了長時間的經驗積累和研究人員的研究成果所確定的方式，但是在執行的過程中仍然在不斷探索改進以適應團隊現階段的開發能力。書中說「人月」是乙個神話，是因為時間精力的消耗與獨立投入的人力、時間不成線性相關，所以每一次的專案估算和調整都需要謹慎為之，落後太多的專案往往會滑向失敗的深淵。
人月神話讀書筆記（一）
在人月神話裡有句話，令我頗有感悟 向進度落後的專案中增加人手，只會使進度更加落後。用人月這一觀念來衡量專案進度帶有欺騙性。因為他使得專案看上去好像人力和時間是可交換的。如果時間不夠，那麼增加人手就可以加快進度。這個衡量的方式嚴重的忽略了新增加的人手的培訓時間以及隊員之間的互相溝通等因素。比如我生活中...
《人月神話》讀書筆記一
實際的權威來自於每次任務的 出色 完成。進度監督，對進度進行跟蹤和監督。評估進度，跟蹤進度。人員和時間之間，需要溝通實現任務的分解。溝通很重要，溝通可以實現任務的分解，提高工作的效率。溝通所增加的負擔由兩個部分組成，培訓和交流。能分解任務的前提是每個成員都懂得那項技術。1 3計畫，1 6編碼，1 4...
《人月神話》讀書筆記（一）
作為乙個初學軟體工程，並沒有真正程式設計經驗可言的的人，開始先是通讀了一遍 人月神話 只知道了 人月神話 的真正含義。人月是在估計和進度安排中使用的工作量單位，但因為它具有的危險性和欺騙性導致了它像神話一樣地存在。而作者闡述的主要思想是軟體程式設計的專案進度與增加人員之間是不能互換的。之後再仔細地閱...