敏捷開發

簡介：

是一種從1990年代開始逐漸引發普遍關注的一些新型 軟件開發方法，是一種應對快速變化的需求的一種軟件開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對於"非敏捷"，更強調程序員團隊與業務專家之間的緊密協做、面對面的溝通（認爲比書面的文檔更有效）、頻繁交付新的 軟件版本、緊湊而 自我組織型的團隊、可以很好地適應需求變化的代碼編寫和團隊組織方法，也更注重作爲軟件開發中人的做用。

若是要實行一個很好的scrum,一般要知足兩點：1、團隊有三名或以上的研發工程師；2、團隊內有一名合適的 Scrum Master。當團隊內沒法找到合適的Scrum Master時，不要輕易推行敏捷。若是你的團隊是由新人組成，或者即便有資深員工可是他並不瞭解或認同敏捷開發的話，那麼你須要等待合適的Scrum Master出現。

當你真正實行敏捷開發時，要注意量化衡量團隊的執行力的指標：完成度、評估準確度、計劃合理度。這是評定整個進度的很重要的指標，也是讓迭代更好的進行下去的準則。
適用性：

在敏捷方法其獨特之處之外，他和其餘的方法也有不少共同之處，好比迭代開發，關注互動溝通，減小中介過程的無謂資源 消耗。一般能夠在如下方面衡量敏捷方法的適用性：從產品角度看，敏捷方法適用於需求萌動而且快速改變的狀況，如系統有比較高的關鍵性、可靠性、安全性方面 的要求，則可能不徹底適合；從 組織結構的角度看，組織結構的文化、人員、溝通則決定了敏捷方法是否適用。跟這些相關聯的關鍵成功因素有：

組織文化必須支持談判人員彼此信任，人少可是精幹，開發人員所做決定獲得承認，環境設施知足成員間快速溝通之須要。最重要的因素恐怕是項目的規模。規模增加，面對面的溝通就越發困難，所以敏捷方法更適用於較小的隊伍，20、40人或者更少。大規模的 敏捷軟件開發尚處於積極研究的階段。

另外的問題是項目初期的大量設想或快速的需求收集可能致使項目走入誤區，特別是客戶對其自身須要毫無概念的狀況下。 與之相似，人之天性很容易形成某我的成爲主導並將項目目標和設計引入錯誤方向的境況。開發者常常會把不恰當的方案授予客戶，而直到最後出問題前都能得到客 戶認同。雖然理論上快速交互的過程能夠限制這些錯誤的發生，但前提是有效的負反饋，不然錯誤會迅速膨脹。

敏捷方法有時候被誤認爲是無計劃性和紀律性的方法，實際上更確切的說法是敏捷方法強調適應性而非預見性。

適應性的方法集中在快速適應現實的變化。當項目的需求起了變化，團隊應該迅速適應。這個團隊可能很難確切描述將來將會如何變化.

對比迭代方法

相比迭代式開發二者都強調在較短的開發週期提交 軟件，敏捷開發的週期可能更短，而且更增強調隊伍中的高度協做。

對比瀑布式開發

二者沒有不少的共同點，瀑布模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求、分析、設計、編碼、測試的步驟順序進行。步驟成果做爲衡量進度的方法，例如需求規格，設計文檔， 測試計劃和代碼審閱等等。

瀑布式的主要的問題是它的嚴格分級致使的自由度下降，項目早期即做出承諾致使對後期需求的變化難以調整，代價高昂。瀑布式方法在需求不明而且在項目進行過程當中可能變化的狀況下基本是不可行的。

相對來說，敏捷方法則在幾周或者幾個月的時間內完成相對較小的功能，強調的是能將盡早將盡可能小的可用的功能交付使用，並在整個項目週期中 持續改善和加強。

有人可能在這樣小規模的範圍內的每次迭代中使用瀑布式方法，另外的人可能將選擇各類工做並行進行。