乙個壞蘋果會毀了一箱好蘋果，在軟體開發過程中，無論你做了多少正確的事情，你只要做了一件錯事，軟體的開發進度就會延期。
這次最大的感受就是軟體工程的核心是按期質量的完成計畫，最好能夠快速開發。
關鍵是按期。軟體的時間規劃很難。就像書中寫的你很可能肯定的列出了乙個專案的時間計畫表。但是由於種種的原因，計畫一拖再拖，最後甚至可能直接被取消的。乙個過於樂觀的計畫表，會使你突然在交付前夕突然匆忙起來，而匆忙的結果導致更多的錯誤，最後使得工期一再拖延。所以，乙個真實可靠的時間計畫表非常重要。《快速軟體開發》中說「有少數的一些組織的進度估算準確到了10%以內，能控制在5%之內的還沒有聽說」。
的確軟體的估算真的很難很難。書中有這樣乙個例子:一天，你去找乙個建築師，告訴他你要建乙個房子，並問他能否用10萬元建一棟有三個臥室的房子。建築師告訴你可以，但也告訴你依據要求的細節，費用為有所變化。如果你接受他的建議，那麼他有可能按照估算完成工作。但是如果你對想要的房子有特殊的要求——堅持要能容納三輛車的車庫、美食廚房、日光浴室、游泳池等，那麼即使當初的建築師曾告訴你有可能用10萬元建的一棟三個臥室的房子，最終你的房子的造價可能會是最初估算的好幾倍。所以說這牽扯兩個方面的問題。乙個是使用者的需求是否與程式設計師想的需求一致，也就是說他們兩個心中的房子是否相同。另乙個就是軟體工程開發是乙個逐漸改進的過程，剛開始你只有乙個模糊的認識，隨著工作的進行，你才能越來越清晰，所以對於時間的估算也比較模糊。只有詳細的理解了每個功能，才可能準確估算。
對此，我表示疑問很大，當我們做乙個全新的專案的時候，又該怎麼估算呢？如果使用者的需求不斷改變，又怎樣能夠最小限度的減少損失呢?
那麼時間不夠，是否新增人手就行呢？答案是否定的。布魯克斯在《人月神話》中提出了布魯克斯法則——「往已延誤的專案中補充人力，只會使其繼續延誤。」這個問題是基於如下法則，它假定生產力是可拆分為不連續、無差異、可替換的單元。所以，如果100個人能在乙個月內完成50個部件，則單個部件需要2個人月——故而只要往專案中投入更多工人，就能更快地生產出相同數量的部件。這就是人月神話。布魯克斯觀察到，「只有在任務能分派給許多互相之間無須溝通的工作者是，人和月才是可互換品。」因為每當團隊中加入乙個新組員，老組員就得放下手邊的工作，幫助新組員進入角色，每位組員都要等待重新分派任務，好讓新組員有事可做。在你意識到這一切之前，已經遠遠落後於進度了。
那麼落後了進度，是否還有方法能夠快速彌補呢？
第一次閱讀作業
恢復內容開始 第一次閱讀和準備作業 這個作業屬於哪個課程 課程的鏈結 這個作業要求在 作業要求的鏈結 我在這個課程的目標是 更深層次的了解軟體工程 這個作業在哪個具體方面幫助我實現目標 建立學習這門課程的學習目標，有主動意識的去學習 其他參考文獻 一.建立部落格並介紹自己 2.一名學生，平時愛好看電...
第一次閱讀作業
這個作業屬於哪個課程 課程的鏈結 這個作業要求在 作業要求的鏈結 我在這個課程的目標是 學習軟體開發流程，方法，需求分析等 這個作業在哪個具體方面幫助我實現目標 閱讀大量相關資料讓我對軟體開發有了更全面的了解 一.建立部落格並介紹自己 1 在cnblogs.com上註冊開設部落格。2 自我簡介 二....
第一次閱讀作業
本次作業屬於的課程 作業要求 homework 2713 我在這個課程的目標 學會軟體開發過程中的各種實用技術與開發軟體的思想過程 這個作業在哪個具體方面幫助我實現目標 促使我自己去從書中與其他軟體開發大師和學霸那裡發掘自己所需要的東西 正文 一 自我介紹 我是乙個在陌生人面前害羞緊張，爸媽所謂牽不...