brooks法則：向進度落後的專案中增加人手，只會使進度更加落後。
我們剛剛接觸軟體程式設計，對於在軟體功能的實現、程式設計人員面臨的困難我也能略微理解了。專案的時間依賴於順序上的限制，人員的最大數量依賴於獨立子任務的數量。對於乙個或多個專案說，有這樣乙個運作規律：以前公司大多會採取人海戰術，但進度沒有提前，反而整天加班，最後使用者不滿意，開發人員整天鬱悶，結果是使用者對公司失去了信任。開發人員呢，舊人一一辭職，新人幾乎天天引進，但做法並沒有改變，情況也沒有好轉，公司自然沒有發展。
人月之所以不能成為神話，正是因為增加人手的同時也增加了人與人之間的交流，即培訓和相互溝通。我們所有的進度都是以「人月」**產量來衡量的. 而增加"人"並不能縮短"月"的量。同時，缺乏正確的進度安排是造成專案滯後的最主要原因，它比其他所有因素加起來的影響還要大。
「開發並推行生產率圖表、缺陷率圖表、估算規則等等，而整個組織最終會從這些資料的共享上獲益。」這與我們團隊的周活動總結表、時間記錄日誌、缺陷記錄日誌、學習進度條有一定的相似之處，可見建立並記錄這些資料是乙個明智之舉。其中的乙個原因我認為是由於我們的樂觀主義，通常實際出現的缺陷數量比預想的多得多。
之前的團隊合作中也出現過類似的問題，通常在討論時會忽略一些功能在具體實現上所需的難度有多大，導致遇到問題時壓力變大。
我們團隊的人數自然是不變的，所以，在今後的團隊合作中更要注重分工和進度的安排，高效地完成我們的專案。
人月神話閱讀筆記01
本週讀了 人月神話 中的 焦油坑 和 人月神話 兩個章節，現來看看我的認識與理解。我們做專案應該滿足目標 時間進度 和預算的要求，這樣才能夠最大程度上避免陷入焦油坑中。新聞中有多兩個人在車庫中完成了大量的重要程式，其實我們應全面的看待這樣的神話。編寫陳偉乙個變成產品和程式設計系統需要編寫乙個程式的三...
人月神話閱讀筆記01
本篇閱讀筆記是我對於 人月神話 一書中中關於團隊擴建的感悟。開發團隊在很多方面滿足了迫切性的需要。十個人，其中七個專業人士在解決問題，而系統是一乙個人或者最多兩個人思考的產物，因此客觀上達到了概念的一致性。要特別注意傳統的兩人隊伍與外科醫生副手隊伍架構之間的區別。首先，傳統的團隊將工作進行劃分，每人...
人月神話閱讀筆記01
在眾多軟體專案中，缺乏合理的時間進度是造成專案滯後的最主要原因，它比其他所有因素加起來的影響還大。原因 我們對估算技術缺乏有效的研究，更加嚴肅地說，它反映了一種悄無聲息，但並不真實的假設 一切都將運作良好。第二，我們採用的估算技術隱含地假設人和月可以互換，錯誤地將進度與工作量相互混淆 第三，由於對自...