人月到底有多少神話色彩？很多年來，人們對軟體生產率和影響他的因素進行了大量的量化研究，特別是在專案人員配備和進度之間的平衡方面。
結果：第一次發布的成本最優進度時間，t=2.5（mm）^1/3。即，月單位的最優時間是估計工作量（人月）的立方根，估計工作量則有規模估計和模型中的其他因子匯出。最有人員配備曲線是由推導得出的。當計畫進度比最優進度長時，成本曲線會緩慢攀公升。時間越充裕，花的時間越長。當計畫進度比最優進度短時，成本曲線急劇公升高。無論安排多少人手，幾乎沒有任何專案能夠在少於3/4的最有時間內獲得成功！當高階經理向專案經理要求不可能的進度擔保時，這段結論可以充分地作為專案經理的理論依據。
放棄權力的力量，如果認同創造力來自於人的觀點，而不是組織架構或者開發過程，那麼專案管理面對的中心問題是如何設計架構和流程，來提高而不是壓制主動性和創造力。幸運的是，這個問題並不是軟體組織所特有，一些傑出的思想家正努力地致力於這項工作。向大型組織指派小型或者附屬機構能夠完成的職責是不公平的，同時也是正常次序的不幸和對它的干擾。對於每項社會活動，就其本質而言，應該配備對社會個體成員的幫助，而不是去破壞和吸取他們。
微型計算機革命改變了每個人開發軟體的方式。70年代的軟體過程本身被微處理器革命和它所帶來的科學技術進步所改變。很多軟體開發過程中的次要困難被消除。快速的個人計算機處理現在是軟體開發者的常規工具從而周轉時間的概念幾乎成為了歷史。如今的個人計算機不僅僅比2023年的超級計算機要快，而且比2023年的unix工作站還要快。所有這些意味著即使在最差的計算機上，編譯也是快速的，而且大記憶體消除了基於磁碟鏈結所需要的等待時間。另外，符號表和目標**可以在記憶體中儲存，從而高階別的除錯無需重新編譯。
軟體工程的狀態及其未來：
parans對比了電氣工程和軟體領域，覺得把我們所做的稱為「工程」十分冒昧。他可能是正確的，這個領域可能永遠不會發展成像電氣工程那樣的工程化領域，擁有精確的數學基礎。畢竟，軟體工程就像化學工程一樣，與如何擴充套件到工業級別處理過程的非線性問題有關。而且，和工業工程類似，他總是被人類行為的複雜性所困擾。
人月神話閱讀筆記三
專案交流 巴比倫塔工程失敗的原因就是缺乏交流，導致了無法交談合作 爭辯 沮喪和群體猜忌。團隊組織的目標是減少必要的交流和協作。為了減少交流，組織結構包括了人力劃分和限定職責範圍。銀彈 古代狼人傳說中，只有用銀質子彈才能 這些怪獸。作者採用 銀彈 一詞來比喻人們渴望找到可以使軟體成本像硬體成本一樣迅速...
《人月神話》閱讀筆記（三）
這次讀完了 人月神話 這本書，然後總結回想總結一下。讀這本書的第一感受，感覺看這本書不像是在看一本和我們的相關的書，書中用了很多形象的比喻，來闡述專案管理中的一些問題。看完這本書後，我發現人月神話無處不在，尤其是在我們軟體工程這個專業。乙個軟體的好壞不是說由乙個程式設計師決定的，往往乙個很小的功能，...
人月神話閱讀筆記之三
03人月神話閱讀筆記之三 1.開發乙個專案，我們錯誤的認為用人月這個工作量單位來估計和進行進度安排。成本的確隨開發產品的人數和時間的不同，有著很大的變化，進度卻不是如此。因此我認為用人月作為衡量一項工作的規模是乙個危險和帶有欺騙性的神話。它暗示著人員數量和時間是可以相互替換的。人數和時間的互換僅僅適...