本書作者作為乙個經驗豐富的軟體專案管理者提供給我們很多發人深省的觀點。先從書名「人月神話」開始**，人月即早期用來度量軟體開發工作量的乙個單位。具體為將每個人每月的工作量作為乙個基本單位。用人月的量來衡量整個專案的規模與工作量。並且早期認為人月的模式簡單符合線性關係。即：10人*月的專案等價於5人*2月等價於1人*10月。但是這種看似簡單完美的模型卻是乙個美麗的神話,人員和時間是不能簡單替代的。
軟體專案的進展並不能用簡單的線性關係抽象。軟體開發不是一項簡單重複的體力勞動。設想如果乙個人要掃雪，假設他乙個人需要乙個小時掃完，但是如果他再找來5個人一起掃，可能只需要十分鐘。軟體開發比這要複雜的多；如果乙個人用十天能做完的乙個專案，他做到第五天後想找人來一起做，這就不是找五個人一天就能做完的事情。也許完成專案花費的時間比十天還要多。他要花時間為新加入的隊員介紹專案，為他們合理分工，如果有一人沒按時完成，所有人都要停下等待……由此引出一系列不可預估的問題。複雜度大大提高。總之：從專案的人數和時間兩個維度考慮，都不能以人月作為軟體開發度量：1.人數的增加對軟體開發的貢獻不是線性增長的（隊友之間有協作交流的問題）。2.每個人在專案開發中的工作量也不是線性遞增的（開發的過程中複雜度提高）。他們可能會是log（o）或更複雜的情況。總之，在軟體開發中，合理評估參與人數和時間是一項很有挑戰並且需要經驗性的工作。同時，應該儘量減少或避免人員的改動。
此外，文中乙個核心的觀點就是保持軟體產品的概念完整性，概念完整性是產品質量的核心。「乙個整潔、優雅的程式設計產品必須向它的每個使用者提供乙個條理分明的概念模型，這個模型描述了應用、實現應用的方法以及用來指明操作的各種引數的使用者介面使用策略。」對於大型的軟體產品，較好的實現概念完整性並不是一件簡單的事情。
寒假閱讀人月神話1
平邊界以下，程式變成測試 修復和擴充套件的程式。它可以執行在多種作業系統平台上，供多套資料使用。要成為通用的程式設計產品，程式必須按照普遍認可的風格來編寫，特別是輸入的範圍和形式必須擴充套件，以適用於所有可以合理使用的基本演算法。接著，對程式進行徹底測試，確保它的穩定性和可靠性，使其值得信賴。這就意...
人月神話3
在程式設計時，即程式設計人員將腦中的構思轉換為程式的過程中，錯誤往往是無法避免的，因為人的思路中會隱藏著一些不完善的地方，這些不完善的地方只有在具體實現過程中才暴露出來，與此同時，由於程式設計人員都是樂觀主義者，對於自己的思路的期待超出了其本身的完善度，程式設計人員通常以為 一切可以很好的執行 造成...
人月神話 人月
缺乏合理的進度安排是造成專案滯後的最主要的原因，它比其他所有因素加起來的影響還大 引起的原因 a.估算技術不嚴謹科學，缺乏有效研究，建立在不真實的假設 一切會執行良好 b.對進度缺少跟蹤和監督 c.認為人月可以互換，進度與工作量不等同 程式設計人員的樂觀主義 人月關係 a.人員和時間的關係 完全可以...