03人月神話閱讀筆記之三
1.開發乙個專案，我們錯誤的認為用人月這個工作量單位來估計和進行進度安排。成本的確隨開發產品的人數和時間的不同，有著很大的變化，進度卻不是如此。因此我認為用人月作為衡量一項工作的規模是乙個危險和帶有欺騙性的神話。 它暗示著人員數量和時間是可以相互替換的。人數和時間的互換僅僅適用於以下情況：某個任務可以分解給參與人員，並且他們之間不需要相互的交流，而在系統程式設計中近乎不可能。當任務由於次序上的限制不能分解時，人手的新增對進度沒有幫助。除錯、測試的次序特性，許多軟體都具有這種特徵。因為軟體開發本質上是一項系統工作——錯綜複雜關係下的一種實踐——溝通、交流的工作量非常大，它很快會消耗任務分解所節省下來的個人時間。從而，新增更多的人手，實際上是延長了，而不是縮短了時間進度。
2. 對於程式設計，有其樂趣和苦惱。建立事物的快樂 ，開發對其他人有用的東西的樂趣 ，將可以活動、相互嚙合的零部件組裝成類似迷宮的東西，這個過程所體現出令人神魂顛倒的魅力 ，面對不重複的任務，不間斷學習的樂趣 ，工作在如此易於駕馭的介質上的樂趣——純粹的思維活動，其存在、移動和運轉方式完全不同於實際物體。將做事方式調整到追求完美，是學習程式設計的最困難部分；由其他人來設定目標，並且必須依靠自己無法控制的事物（特別是程式）。
3.變成也好設計軟體也好都需要持之以恆並且有耐心的去完成，需要很大的自制力。
人月神話閱讀筆記三
專案交流 巴比倫塔工程失敗的原因就是缺乏交流，導致了無法交談合作 爭辯 沮喪和群體猜忌。團隊組織的目標是減少必要的交流和協作。為了減少交流，組織結構包括了人力劃分和限定職責範圍。銀彈 古代狼人傳說中，只有用銀質子彈才能 這些怪獸。作者採用 銀彈 一詞來比喻人們渴望找到可以使軟體成本像硬體成本一樣迅速...
《人月神話》閱讀筆記（三）
這次讀完了 人月神話 這本書，然後總結回想總結一下。讀這本書的第一感受，感覺看這本書不像是在看一本和我們的相關的書，書中用了很多形象的比喻，來闡述專案管理中的一些問題。看完這本書後，我發現人月神話無處不在，尤其是在我們軟體工程這個專業。乙個軟體的好壞不是說由乙個程式設計師決定的，往往乙個很小的功能，...
人月神話之閱讀筆記三
人月到底有多少神話色彩？很多年來，人們對軟體生產率和影響他的因素進行了大量的量化研究，特別是在專案人員配備和進度之間的平衡方面。結果 第一次發布的成本最優進度時間，t 2.5 mm 1 3。即，月單位的最優時間是估計工作量 人月 的立方根，估計工作量則有規模估計和模型中的其他因子匯出。最有人員配備曲...