《人月神話》是軟體工程管理的一本奇書，他用深入淺出的文字闡明了在軟體工程開發的過程中，我們可能會遇到的陷阱，以及如何避免它們。
系統程式設計的進度安排背後的第乙個錯誤的假設是：一切都將運作良好，每一項任務僅花費它所"應該"花費的時間。
在單個的任務中，「一切將運轉正常」的假設在進度上具有可實現性。因為所遇到的延遲是乙個概率分布曲線，「不會延遲」具有限定的概率，所以現實情況可能會像計畫安排的那樣順利，然而大型的程式設計工作，或多或少包含了許多子任務，某些任務間還具有前後的次序，從而一切正常的概率變得非常的小，甚至接近於零。
用人月作為衡量一項工作的規模是乙個危險和帶有欺騙性質的神話。它暗示著人員數量和時間是可以相互替換的。
相互之間交流的情況更糟一些。如果任務的每個部分必須分別與其他部分單獨協作，則工作量按照n(n-1)/2遞增。在一對一交流的情況下，3個人的工作量是2個人的3倍，4個人的工作量是2個人的6倍。
向進度落後的專案增加人手，只會使進度更加落後。
效率高和效率低的實施者之間個體差異非常大，經常能達到數量級的水平。
概念的完整性要求設計必須由乙個人，或者非常少數互有默契的人員來實現。
而進度壓力卻要求很多人員來開發系統。有兩種方法可以解放這種矛盾，第一種是仔細地對設計方法和具體實現進行分工。第二種前一章節所討論的，一種嶄新的組建開發團隊的方法。
在開發第乙個系統時，結構師傾向於精煉和簡潔，他知道自己對正在進行的任務不夠了解，所以會謹慎、仔細的工作。
第二個系統設計師們所設計的最危險的系統。而當他著手設計第三個或第四個系統時，先前的經驗會相互驗證，得到對此類系統通用特性的判斷，而且系統之間的差異會幫助他識別出經驗中不夠通用的部分。
對於軟體開發團隊來說，進取同樣是非常必要的。進取提供了緩衝和儲備，使開發團隊能夠處理常規的災禍，可以預計和防止小的災禍。
人月神話閱讀筆記01
本週讀了 人月神話 中的 焦油坑 和 人月神話 兩個章節，現來看看我的認識與理解。我們做專案應該滿足目標 時間進度 和預算的要求，這樣才能夠最大程度上避免陷入焦油坑中。新聞中有多兩個人在車庫中完成了大量的重要程式，其實我們應全面的看待這樣的神話。編寫陳偉乙個變成產品和程式設計系統需要編寫乙個程式的三...
人月神話閱讀筆記01
本篇閱讀筆記是我對於 人月神話 一書中中關於團隊擴建的感悟。開發團隊在很多方面滿足了迫切性的需要。十個人，其中七個專業人士在解決問題，而系統是一乙個人或者最多兩個人思考的產物，因此客觀上達到了概念的一致性。要特別注意傳統的兩人隊伍與外科醫生副手隊伍架構之間的區別。首先，傳統的團隊將工作進行劃分，每人...
人月神話閱讀筆記01
在眾多軟體專案中，缺乏合理的時間進度是造成專案滯後的最主要原因，它比其他所有因素加起來的影響還大。原因 我們對估算技術缺乏有效的研究，更加嚴肅地說，它反映了一種悄無聲息，但並不真實的假設 一切都將運作良好。第二，我們採用的估算技術隱含地假設人和月可以互換，錯誤地將進度與工作量相互混淆 第三，由於對自...