在眾多的專案中，缺乏合理的進度安排是造成專案延期最主要的原因，這比其他所有因素加起來影響還要大。這個災難是怎麼發生的呢？
所有系統的進度安排背後第乙個錯誤的假設是：一切都將運作良好，每項任務僅需要花費它「應該」花費的時間。對於創造者，只有在實現的過程中，才能發現我們構思的不完整和不一致性。
程式設計人員通過非常純粹的思維活動構思程式，所以很容易自信的認為實現過程中不會遇到困難。然而我們的思維是有缺陷的，專案越大，能夠按照計畫順利進行的概率就越小。
在估計和進度安排的過程中使用「人月」作為工作量單位是十分荒謬的，是乙個帶有危險和欺詐性的神話，他暗示著人員數量和時間可以相互替換。然而人數和時間的互換僅僅適用於，某個任務可以分解給參與人員，並且他們之間不需要相互交流的情況。
當不能分解時，人手的新增對進度沒有任何幫助，大多數程式設計工作都具有這種特徵。就像你無論找幾個媽媽，孕育乙個生命總是需要10個月的時間。
對於可以分解的情況，增加人手可以加快進度，但是會提高成本，2個人的效率可能僅等於1.5個人。原因在於溝通、培訓、交流等事物增加了工作量，而且所增加的工作量可能會完全抵消任務分解所產生的作用。
軟體開發作為一項系統工作，溝通、交流的工作量非常大，它會快速消耗任務分解所節約下來的時間。
系統測試進度的安排往往是程式設計中最不合理的部分，都過於短了。很少專案允許為為測試分配一半的時間，然而大多數專案的測試實際上是花費了進度中一半的時間。
不安排足夠的測試時間將會是一場災難，由此造成的專案延期成本高昂，在早期規劃時，保留充分的測試時間非常重要。
1/3 計畫
1/6 編碼
1/4 構建測試和早期系統測試
1/4 系統測試，所有的構建已完成
管理人員很容易會認為專案功能完成就意味著開發完成了，沒有為測試階段安排較長時間的意識，往往測試的時間只能佔到專案週期的1/8甚至更少。這明顯是犯了樂觀主義的錯誤，專案管理人員甚至比開發人員更加樂觀。
如果不是站在專業的角度上，似乎很難理解測試階段所花的時間，更難理解的是為什麼增加人手不能讓專案進度加快。
《人月神話》2
人月神話 讀後感 開啟 人月神話 進入眼簾的是作者1975 年版獻辭，我很詫異老師這麼推崇這書，居然有這麼悠久的歷史 在日新月異的軟體界，還真有30多年經久不衰的 神話 抑或是一本 預言 對於沒有大型軟體編寫經驗的人來說，讀這本 人月神話 書更多的不是感受而是學習，由於時間緊張，對這本書之前只是囫圇...
人月神話閱讀筆記2
人月神話閱讀筆記之二 之前寫程式注重的只是個人，和團隊的合作機會也很少，及時合作機會但是自己注重的也是自己的進步和發展，和團隊之間的交流和溝通很少，是團隊的專案進行的並不是很好 看完這本書明白了很多，和團隊進行合作就要進行交流和分工 兩個方面 交流，以及交流的結果 組織。他們無法相互交談，從而無法合...
《人月神話》閱讀筆記（2）
在很多方面，管理乙個大型的計算機程式設計專案和其它行業的大型工程很相似 比大 多數程式設計師所認為的還要相似 在很多另外的方面，它又有差別 比大多數職業經理 所認為的差別還要大。這是 人月神話 第一版序言的第一段話，這段話可以說是對軟 件專案的 管理特徵進行了乙個總體的概括。過去幾十年的大型系統開發...