今天對人月神話的正文部分進行了閱讀，從人月神話這一部分中了解到缺乏合理的時間進度控制是造成滯后的主要原因，比其他任何事情影響的和還大，書中也對造成這種這種普遍災難的原因進行了并進行了詳細列舉。
??首先，我們對估算技術缺乏有效的研究。也就是文章中所介紹的對于與每一個編程人員來說都是樂觀主義者，在編程人員的心中，認為一切都將運作良好，每一項任務僅花費它所“應該”花費的時間。然而事實并不是這么簡單的，在創作工程中總會遇到不同的苦難的，你的程序并不一定就按照這你的思路進行，總會遇到一定的bug等著你去處理。第二，我們采用的估算技術隱含地假設人和月可以互換，錯誤地將進度與工作量相互混淆。按照常規思維，人多力量大，然而實際在編程過程中卻不一定是這樣的當任務由于次序上的限制不能分解時，人手的添加對進度沒有幫助，因為程序的次序性不同每一步都必須經過一點時間的孕育的。第三，由于對自己的估算缺乏信心，軟件經理通常不會有耐心持續地進行估算這項工作。由于沒有認真的估算好時間就會導致對于系統測試的安排時間較短，如果沒有經過這些基本的測試就直接交付就會導致重新的維護，這樣相應的成本也會上漲，最終造成的費事費力，所以一個良好的時間規劃是程序編寫的關鍵。正確的時間規劃應該是：1/3 計劃1/6 編碼1/4 構件測試和早期系統測試1/4 系統測試，所有的構件已完成。第四，對進度缺少跟蹤和監督。其他工程領域中，經過驗證的跟蹤技術和常規監督程序，在軟件工程中常常被認為是無謂的舉動。就如同書中所介紹的那樣，編程人員，同廚師一樣，某項任務的計劃進度，可能受限于顧客要求的緊迫程度，但緊迫程度無法控制實際的完成情況。
第五，當意識到進度的偏移時，下意識（以及傳統）的反應是增加人力。然而這并必須要考慮到不同的情況，有時盲目的增加人手只會是畫蛇添足，導致越幫越忙。
???另外，根據對于外科手術隊伍的也頗有感想。在這一章的內容中闡述的就是在工程管理過程的經驗。同樣本章中也對人員問題進行了另一番闡述，書中所說，一個優秀的隊伍并并不在于人數的多少，相反在于人員的精煉，就如同一個優秀的外科隊伍一樣，有時10個人就可以構成一個優秀的團隊。.一個首席程序員（后來叫做架構師），可以采用一個外科手術式的隊伍完成10人配比的隊伍。大概是主程序、管理（BOSS）及他的文秘、編輯及他的文秘（這個可以省略），副手（和主程序相比，什么都會，但是沒有主程序那么精通），其他程序，語言專家（外援），測試員這樣的配比來執行，相應的還可以有工具維護人員（也是程序員的一種，負責輔助程序的開發）因為小型、精干隊伍最好（思緒少，相互交流容易）-----相對于普通情況下，如果是大型的可以將領導人拆出來做成一個決策組，來提升協調；當然團隊中的每個成員最好都是優秀的編程人員，因為相同程度的培訓，優秀的人員的生產率是較差成員的10倍，只有在這種精悍的團隊下，才更加有益于優秀作品的推出。當然對于開發真正的大型系統的話，人員的增加才是必須的。
??這也給我們我們很大的啟示，要想做一個真正的程序開發人員，我們還是遠遠不夠的我們必須通過不斷地學習，不斷提升自己的能力，能夠融入到優秀得隊伍中去。
javascript匿名函數)
