在寫這篇部落格之前，結合這章的內容，我回顧了一下我的第乙個團隊專案：網頁版二手**「轉賺」，現在還在構建的過程中，這是第一次團隊的專案，老師讓我們像乙個真正企業中的做專案一樣，也會製作任務板、進行站立會議。
在書上講到了關於這方面的知識：
1.在眾多軟體專案中，
缺乏合理的時間進度是造成專案滯後的最主要原因，
它比其他
所有因素加起來的影響還大。導致災難的原因是：
首先，我們對估算技術缺乏有效的研究。
第二，我們採用的估算技術隱含地假設人和月可以互換，錯誤地將進度與工作量相混
淆第三，由於對自己的估算缺乏信心，軟體經理通常不會有耐心持續地進行估算這工作。
第四，對進度缺少跟蹤和監督。
第五，當意識到進度的偏移時，下意識（以及傳統的反應是增加人力）。
系統開發過程中，樂觀主義並不應該是理所應當的
。在單個任務中，「一切都將運轉正常」的假設在時間進度上具有可實現性。因為所遇的延遲是乙個概率分布曲線，「不會延遲」僅具有有限的概率，所以現實情況可能會像計畫安排的那樣順利。
然而大型的程式設計工作，或多或少包含了很多任務，
某些任務間還具有前後的
次序，從而一切正常的概率變得非常小，甚至接近於無。
3.
成本的確隨開發產品的人數和時間的不同，
有著很大的變化，
進度卻不是如此。
因此我認為用人月作為衡量一項工作的規模是乙個危險和帶有欺騙性的神話。
它暗示著人員數
量和時間是可以相互替換的。因為軟體開發本質上是一項系統的工作
錯綜複雜關係下的一種實踐
溝通交流的工
作量非常大，它很快會消耗任務分解所節省下來的個人時間。
從而，新增更多的人手，
實際上是延長了，而不是縮短了時間進度。
4.
在時間進度中，
順序限制所造成的影響，
沒有哪個部分比單元測試和系統測試所受
到的牽涉更徹底。對於任務的進度安排，以下是作者使用了很多年的經驗法則：1/3
計畫，1/6編碼
，1/4構件測試和早期系統測試（單元測試）
，1/4系統測試
5.
如果發現專案的實際進度滯後於預計的進度，專案經理最好的辦法是重新安排進
度，而不是增加專案人手。
6.
專案的時間依賴於順序上的限制，人員的數量依賴於單個子任務的數量。
從這兩個
數值可以推算出進度時間表，
該錶安排的人員較少，
花費的時間較長
（唯一的風險是產品可
能過時）
。相反，分派較多的人手，計畫較短的時間，將無法得到可行的進度表。總之，在
眾多軟體專案中，
缺乏合理的時間進度是造成專案滯後的最主要原因，
它比其他所有因素加起來的影響還要大。
從這些內容中我明白了
：團隊之前要多溝通交流，而且要互相換一下彼此的角色，而且要對自己的能力有一定的準確估算，作為乙個專案經理，乙個專案的靈魂人物，專案經理要隨時調整進度，就比如我們組長李同學，他雖然不善溝通，但是對於這一點他做的就非常好，時刻根據專案的進度調整進度的安排，這一點不得不讚揚，但是溝通交流的問題也需要重視，只有加強溝通交流，才能使學術交流的最大化。
閱讀筆記 人月神話02
人月神話 主要討論的便是人和月之間的關係。並且怎樣處理系統開發的預估，正如作者所說 在眾多軟體專案中，缺乏合理時間進度是造成專案滯後的最重要原因。首先，我們對估算技術缺乏有效的研究。過於樂觀 第二，我們採用的估算技術隱含的假設人和月可以互換，錯誤的將進度與工作量相互混淆 第三，由於對自己的估算缺乏信...
《人月神話》閱讀筆記02
在專案完成過程中，一定要準確書寫專案工作手冊，這便利於日後的管理和維護，若工作人員對硬體或軟體的某一部分存在疑問，通過檢視工作手冊，即可快速解決問題。在講到工程專案中的管理問題時，文中提到三點建議，第一，小型專案中產品負責人和技術主管最好是同一人 第二，產品負責人作為總指揮，技術主管充當左右手的管理...
人月神話閱讀筆記02
繼續人月神話的閱讀。在書中，作者提到了關於外科手術式的隊伍。這點是我剛開始稍微有點不理解的。我們都知道，在現代的開發中，一般不會有個人開發的情況，畢竟乙個人不會將事情做得那麼全面，無論他是多麼的強大，個人能力是多麼的突出，他仍然會在一些情況下出現各種各樣的問題，所以，我們一般的都是採用的多人參與開發...