《人月神話》主要討論的便是人和月之間的關係。並且怎樣處理系統開發的預估，正如作者所說「在眾多軟體專案中，缺乏合理時間進度是造成專案滯後的最重要原因。」
首先，我們對估算技術缺乏有效的研究。過於樂觀
第二，我們採用的估算技術隱含的假設人和月可以互換，錯誤的將進度與工作量相互混淆
第三，由於對自己的估算缺乏信心，軟體經理不會持續估算工作。
第四，對進度缺少跟蹤，監督
第五，當意識到進度的偏移時，下意識的反應是增加人力。
我們程式設計師，在創造軟體時需要創造性，創造性活動分為三個階段：構思，實現，交流。1，其作為乙個構思，模型，出現在作者的腦海中和時間空間無關。2，在現實的時間和空間中實現他們。3，其餘作者的思想相互溝通，從而創作過程得以結束。但由於物理介質和思路中隱含的不完善性，實際實現起來需要花費大量的時間和汗水。
在很大程度上我們的構思是由缺陷的，因此總有bug。因此bug是不可避免的。
成本的確隨開發產品的人數和時間不同，有著很大的變化，進度卻不是如此。人月作為衡量一項工作的規模是乙個危險和帶有欺騙性的神話，他暗示者人員數量和時間是可以相互替換的。
某個任務分給參與人員。並且他們之間不需要任何的交流。這在割小麥中是可行的，但在系統編輯中近乎不可能。
當任務由於次序上的限制不能分解時，人手的新增對進度沒有幫助。
其中這裡在用人來彌補時間的時候存在巨大的問題，溝通所增加的負擔由兩個部分組成，培訓和相互的交流。培訓不能分解，主要是相互交流。
軟體開發的溝通，交流的工作量非常大，他很快會消耗任務分解所省下來的個人時間，從而，新增更多的人手，實際上是延長了，而不是縮短了時間進度。
不為系統測試安排足夠的時間是一場災難，因為延遲發生在專案快完成的時候，直到專案的發布日期，才有人發現進度上的問題。因此，壞訊息沒有任何預兆，很晚才出現在客戶和專案經理面前。
我們有兩種解決方案：
1， 開發並推行生產率圖表，缺陷表，估算規則等等，而整個組織最終會從這些資料的共享上獲益。
2， 在基於可靠的基礎估算之前，專案經理堅持他們的估計，確信自己的經驗和直覺總比從期望派生出的結果要強很多。
mills建議大型專案的每乙個部分由乙個團隊解決，但是該隊伍以類似外科手術的方式組建，而並非一擁而上。有乙個人來進行問題的分解，其他人給予她所需要的支援，以提高效率和生產力。
做重要的是首席程式設計師，副手。
首席程式設計師：需要極高的天分，十年的經驗和應用數學，業務資料處理或其他方面的大量系統和應用知識。
副手：能完成任何一部分工作，但是相對具有較少的經驗，只要作用是作為設計的思考者，討論者，評估人員。
mills概念的真正關鍵是「從個人藝術到公共實踐」的程式設計觀念轉換。她所有的團隊成員，展現了所有計算機的運作和產物，並將所有的程式，資料看作是團隊的所有物，而非私人財產。
《人月神話》閱讀筆記02
在專案完成過程中，一定要準確書寫專案工作手冊，這便利於日後的管理和維護，若工作人員對硬體或軟體的某一部分存在疑問，通過檢視工作手冊，即可快速解決問題。在講到工程專案中的管理問題時，文中提到三點建議，第一，小型專案中產品負責人和技術主管最好是同一人 第二，產品負責人作為總指揮，技術主管充當左右手的管理...
人月神話閱讀筆記02
繼續人月神話的閱讀。在書中，作者提到了關於外科手術式的隊伍。這點是我剛開始稍微有點不理解的。我們都知道，在現代的開發中，一般不會有個人開發的情況，畢竟乙個人不會將事情做得那麼全面，無論他是多麼的強大，個人能力是多麼的突出，他仍然會在一些情況下出現各種各樣的問題，所以，我們一般的都是採用的多人參與開發...
人月神話閱讀筆記02
在軟體工程學習過程中，老師會時不時向我們提起一些關於軟體工程的著作。在軟體領域，很少能有像 人月神話 一樣具有深遠的影響力。本書作者布魯克斯為人們管理複雜專案提供了頗具洞察力的和獨到的見解，意味深遠。我選擇了一本 人月神話 40周年紀念版 來閱讀，希望能有所收穫。巴比倫在希伯來語中意思是 變亂 如果...