敏捷開發模式

如果要實行一個很好的scrum,通常要滿足兩點：一、團隊有三名或以上的研發工程師；二、團隊內有一名合適的Scrum Master。當團隊內無法找到合適的Scrum Master時，不要輕易推行敏捷。如果你的團隊是由新人組成，或者即使有資深員工但是他並不了解或認同敏捷開發的話，那麼你需要等待合適的Scrum Master出現。

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

敏捷一詞來源於2001年初美國猶他州雪鳥滑雪勝地的一次敏捷方法發起者和實踐者（他們發起組成了敏捷聯盟）的聚會。

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

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

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

瀑布模型是由W.W.Royce在1970年最初提出的軟體開發模型，瀑布式開發是一種老舊的計算機軟體開發方法。

瀑布模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求分析、設計、編碼、集成、測試、維護的步驟順序進行。

步驟成果作為衡量進度的方法，例如需求規格，設計文檔，測試計劃和代碼審閱等等。

瀑布式的主要的問題是它的嚴格分級導致的自由度降低，項目早期即作出承諾導致對後期需求的變化難以調整，

代價高昂。瀑布式方法在需求不明並且在項目進行過程中可能變化的情況下基本是不可行的。

迭代式開發也被稱作迭代增量式開發或迭代進化式開發，是一種與傳統的瀑布式開發相反的軟體開發過程，它彌補了傳統開發方式中的一些弱點，具有更高的成功率和生產率。

什麼是迭代式開發？

每次只設計和實現這個產品的一部分,

逐步逐步完成的方法叫迭代開發,

每次設計和實現一個階段叫做一個迭代.

在迭代式開發方法中，整個開發工作被組織為一系列的短小的、

固定長度（如3周）的小項目，被稱為一系列的迭代。

每一次迭代都包括了需求分析、設計、實現與測試。

採用這種方法，開發工作可以在需求被完整地確定之前啟動，

並在一次迭代中完成系統的一部分功能或業務邏輯的開發工作。

再通過客戶的反饋來細化需求，並開始新一輪的迭代。

迭代式開發的優點：

1、降低風險

2、得到早期用戶反饋

3、持續的測試和集成

4、使用變更

5、提高復用性

螺旋開發，1988年，巴利·玻姆(Barry Boehm)正式發表了軟體系統開發的“螺旋模型”，它將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合於大型複雜的系統。

“螺旋模型”剛開始規模很小，當項目被定義得更好、更穩定時，逐漸展開。

“螺旋模型”的核心就在於您不需要在剛開始的時候就把所有事情都定義的清清楚楚。您輕鬆上陣，定義最重要的功能，實現它，然後聽取客戶的意見，之後再進入到下一個階段。如此不斷輪迴重複，直到得到您滿意的最終產品。

（1）制定計劃：確定軟體目標，選定實施方案，弄清項目開發的限制條件；

（2）風險分析：分析評估所選方案，考慮如何識別和消除風險；

（3）實施工程：實施軟體開發和驗證；

（4）客戶評估：評價開發工作，提出修正建議，制定下一步計劃。

螺旋模型很大程度上是一種風險驅動的方法體系，因為在每個階段之前及經常發生的循環之前，都必須首先進行風險評估。

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

• 人和交互重於過程和工具。

• 可以工作的軟體重於求全而完備的文檔。

• 客戶協作重於合同談判。

• 隨時應對變化重於循規蹈矩。

其中位於右邊的內容雖然也有其價值，但是左邊的內容最為重要。

人員彼此信任 人少但是精幹 可以面對面的溝通

項目的敏捷開發：

敏捷開發小組主要的工作方式可以歸納為：作為一個整體工作；按短迭代周期工作；每次迭代交付一些成果；

關注業務優先順序；檢查與調整。

最重要的因素恐怕是項目的規模。規模增長，面對面的溝通就愈加困難，

因此敏捷方法更適用於較小的隊伍，40、30、20、10人或者更少。

大規模的敏捷軟體開發尚處於積極研究的領域。

傳統的瀑布式開發，也就是從需求到設計，從設計到編碼，從編碼到測試，從測試到提交大概這樣的流程，要求每一個開發階段都要做到最好。

特別是前期階段，設計的越完美，提交后的成本損失就越少。

迭代式開發，不要求每一個階段的任務做的都是最完美的，而是明明知道還有很多不足的地方，卻偏偏不去完善它，而是把主要功能先搭建起來為目的，以最短的時間，

最少的損失先完成一個“不完美的成果物”直至提交。然後再通過客戶或用戶的反饋信息，在這個“不完美的成果物”上逐步進行完善。

螺旋開發，很大程度上是一種風險驅動的方法體系，因為在每個階段之前及經常發生的循環之前，都必須首先進行風險評估。

敏捷開發，相比迭代式開發兩者都強調在較短的開發周期提交軟體，但是，敏捷開發的周期可能更短，並且更加強調隊伍中的高度協作。

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

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