在眾多軟體專案中，缺乏合理的時間進度是造成專案滯後的最主要原因，它比其他所有因素加起來的影響還大。」
原因：「我們對估算技術缺乏有效的研究，更加嚴肅地說，它反映了一種悄無聲息，但並不真實的假設--一切都將運作良好。」
「第二，我們採用的估算技術隱含地假設人和月可以互換，錯誤地將進度與工作量相互混淆
「第三，由於對自己的估算缺乏信心，軟體經理通常不會有耐心持續地進行估算這項工作。
第四，對進度缺少跟蹤和監督。其他工程領域中，經過驗證的跟蹤技術和常規監督程式，在軟體工程中常常被認為是無謂的舉動。
第五，當意識到進度的偏移時，下意識（以及傳統）的反應是增加人力。這就像使用汽油滅火一樣，只會使事情更糟。越來越大的火勢需要更多的汽油，從而進入了一場注定會導致災難的迴圈。」
「對於創造者，只有在實現的過程中，才能發現我們構思的不完整性和不一致性。因此，對於理論家而言，書寫、試「驗以及"工作實現"是非常基本和必要的。」
「成本的確隨開發產品的人數和時間的不同，有著很大的變化，進度卻不是如此。因此我認為用人月作為衡量一項工作的規模是乙個危險和帶有欺騙性的神話。它暗示著人員數量和時間是可以相互替換的。」
「人數和時間的互換僅僅適用於以下情況：某個任務可以分解給參與人員，並且他們之間不需要相互的交流。這在割小麥或收穫棉花的工作中是可行的；而在系統程式設計中近乎不可能。」
「因為軟體開發本質上是一項系統工作--錯綜複雜關係下的一種實踐--溝通、交流的工作量非常大，它很快會消耗任務分解所節省下來的個人時間。從而，新增更多的人手，實際上是延長了，而不是縮短了時間進度。」
「通過對傳統專案進度安排的研究，我發現很少專案允許為測試分配一半的時間，但大多數專案的測試實際上是花費了進度中一半的時間。」
「觀察一下程式設計人員，你可能會發現，同廚師一樣，某項任務的計畫進度，可能受限於顧客要求的緊迫程度，但緊迫程度無法控制實際的完成情況。就像約好在兩分鐘內完成乙個煎蛋，看上去可能進行得非常好。但當它無法在兩分鐘內完成時，顧客只能選擇等待或者生吃煎蛋。軟體顧客的情況類似。」
「向進度落後的專案中增加人手，只會使進度更加落後。」
「絕大多數大型程式設計系統的經驗顯示出，一擁而上的開發方法是高成本的、速度緩慢的、不充分的，開發出的是無法在概念上進行整合的產品。」
產品負責人的角色是什麼？他組建團隊，劃分工作及制訂進度表。他要求，並一直要求必要的資源。這意味著他主要的工作是與團隊外部，向上和水平地溝通。他建立團隊內部的溝通和報告方式。最後，他確保進度目標的實現，根據環境的變化調整資源和團隊的構架。
at the skunk works.)。
他的溝通交流在團隊中是首要的。他的工作幾乎完全是技術性的。
首先，書面記錄決策是必要的。只有記錄下來，分歧才會明朗，矛盾才會突出。書寫這項活動需要上百次的細小決定，正是由於它們的存在，人們才能從令人迷惑的現象中得到清晰、確定的策略。
第二，文件能夠作為同其他人的溝通渠道。專案經理常常會不斷發現，許多理應被普遍認同的策略，完全不為團隊的一些成員所知。正因為專案經理的基本職責是使每個人都向著相同的方向前進，所以他的主要工作是溝通，而不是做出決定。這些文件能極大地減輕他的負擔。
最後，專案經理的文件可以作為資料基礎和檢查列表。通過週期性的回顧，他能清楚專案所處的狀態，以及哪些需要重點進行更改和調整。
專案經理的任務是制訂計畫，並根據計畫實現。但是只有書面計畫是精確和可以溝通的。計畫中包括了時間、地點、人物、做什麼、資金。這些少量的關鍵文件封裝了一些專案經理的工作。如果一開始就認識到它們的普遍性和重要性，那麼就可以將文件作為工具友好地利用起來，而不會讓它成為令人厭煩的繁重任務。通過遵循文件開展工作，專案經理能更清晰和快速地設定自己的方向
不變只是願望，變化才是永恆
普遍的做法是，選擇一種方法，試試看，如果失敗了，沒關係，再試試別的。不管怎麼樣，重要的是先去嘗試。
從技術角度而言，整個團隊可以靈活地安排。在大型的專案中，專案經理需要有兩個和三個頂級程式設計師作為技術輕騎兵，當工作繁忙最密集的時候，他們能急馳飛奔，解決各種問題。
里程碑有明顯邊界和沒有歧義，比它容易被老闆核實更為重要。如果里程碑定義得非常明確，以致於無法自欺欺人時，很少有人會就里程碑的進展弄虛作假
當里程碑沒有正確反映損失的時間，並對人們形成誤導，以致事態無法挽回的時候，它會徹底碾碎小組的士氣。慢性進度偏離同樣
也是士氣殺手。
個人感受：
在這次的專案開發裡我們都沒有做到合理的估算，本以為團隊四個人開發要比兩個人開發要快，但是在開發過程中，出現各種各樣的情況，導致估算的時間安排都沒有實現
如書中所講：「人數和時間的互換僅僅適用於以下情況：某個任務可以分解給參與人員，並且他們之間不需要相互的交流。這在割小麥或收穫棉花的工作中是可行的；而在系統程式設計中近乎不可能。」，我們在某種程度上講忽視了這一點，然後做了很多無用功，尤其是我自己，由於交流的缺少導致做了許多無用功
解決：在以後的開發中，對於估算我們要考慮團隊成員之間交流，這段時間有可能還要多於實際開發時間
人月神話閱讀筆記01
本週讀了 人月神話 中的 焦油坑 和 人月神話 兩個章節，現來看看我的認識與理解。我們做專案應該滿足目標 時間進度 和預算的要求，這樣才能夠最大程度上避免陷入焦油坑中。新聞中有多兩個人在車庫中完成了大量的重要程式，其實我們應全面的看待這樣的神話。編寫陳偉乙個變成產品和程式設計系統需要編寫乙個程式的三...
人月神話閱讀筆記01
本篇閱讀筆記是我對於 人月神話 一書中中關於團隊擴建的感悟。開發團隊在很多方面滿足了迫切性的需要。十個人，其中七個專業人士在解決問題，而系統是一乙個人或者最多兩個人思考的產物，因此客觀上達到了概念的一致性。要特別注意傳統的兩人隊伍與外科醫生副手隊伍架構之間的區別。首先，傳統的團隊將工作進行劃分，每人...
人月神話閱讀筆記01
第一章 焦油坑 程式設計行業 滿足我們內心深處的創造渴望和愉悅所有人的共有情感 提供了五種 樂趣 建立事物的快樂 本書第一章就明確的講述了程式設計職業的樂趣，無論是建立事物的樂趣，還是簡單學習的樂趣，還是駕馭介質之上的樂趣，還是開發了對人類有用的產品的樂趣等等。這些是每乙個程式設計人或多或少都會體會...