敏捷開發
敏捷開發模式是一種90年代起才引起廣泛關注的新型軟件開發方法，是一種應對快速變化需求而產生的一種軟件開發能力。在實際的應用或者說理解中，其名稱、理念、過程、術語都有一定的差別，但相對於傳統的“非敏捷”方式，更強調開發團隊與業務專家之間的緊密協作溝通（交流大於文檔）、形成緊湊而自我組織型的團隊，這樣可以有助於頻繁交付新的軟件版本，更好的適應需求變化的代碼編寫和團隊組織方法，也就是更加註重軟件開發中人的作用。
敏捷開發實施條件
如果要想很好的實施scrum，通常有兩點需要滿足：一是團隊有三名或以上的研發工程師，二是團隊內有一名合適的Scrum Master。當團隊內無法找到合適的Scrum Master時，不要輕易推行敏捷。如果你的團隊是由新人組成，或者即使有資深員工但是他並不瞭解或認同敏捷開發的話，那麼你需要等待合適的Scrum Master出現。
當你真正實行敏捷開發時，要注意量化衡量團隊的執行力的指標：完成度、評估準確度、計劃合理度。這是評定整個進度的很重要的指標，也是讓迭代更好的進行下去的準則。
三種常用傳統開發方式
瀑布模型
瀑布模型是由W.W.Royce在70年代左右提出來的一種軟件開發模式，是一種相對老舊的計算機開發方法。瀑布模型需嚴格遵循預先計劃的需求分析、設計、編碼、集成、測試、維護的步驟順序進行，是最典型的預見性方法。步驟成果作爲衡量進度的方法，例如需求規格，設計文檔，測試計劃和代碼審閱等等。
瀑布式的主要的問題是它的嚴格分級導致的自由度降低，項目早期即作出承諾導致對後期需求的變化難以調整。
迭代式開發
迭代式開發也被稱作迭代增量式開發或迭代進化式開發，是一種與傳統的瀑布式開發相反的軟件開發過程，它彌補了傳統開發方式中的一些弱點，具有更高的成功率和生產率。
什麼是迭代式開發？
每次只設計和實現這個產品的一部分,逐步逐步完成的方法叫迭代開發,每次設計和實現一個階段叫做一個迭代.在迭代式開發方法中，整個開發工作被組織爲一系列的短小的、固定長度（如3周）的小項目，被稱爲一系列的迭代。
每一次迭代都包括了需求分析、設計、實現與測試。採用這種方法，開發工作可以在需求被完整地確定之前啓動，並在一次迭代中完成系統的一部分功能或業務邏輯的開發工作，再通過客戶的反饋來細化需求，並開始新一輪的迭代。
迭代式開發的優點：
1、降低風險
2、得到早期用戶反饋
3、持續的測試和集成
4、使用變更
5、提高複用性
3.螺旋開發
1988年，巴利·玻姆(Barry Boehm)正式發表了軟件系統開發的“螺旋模型”，它將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合於大型複雜的系統。
“螺旋模型”剛開始規模很小，當項目被定義得更好、更穩定時，逐漸展開。
“螺旋模型”的核心就在於您不需要在剛開始的時候就把所有事情都定義的清清楚楚。您輕鬆上陣，定義最重要的功能，實現它，然後聽取客戶的意見，之後再進入到下一個階段。如此不斷輪迴重複，直到得到您滿意的最終產品。
（1）制定計劃：確定軟件目標，選定實施方案，弄清項目開發的限制條件；
（2）風險分析：分析評估所選方案，考慮如何識別和消除風險；
（3）實施工程：實施軟件開發和驗證；
（4）客戶評估：評價開發工作，提出修正建議，制定下一步計劃。
螺旋模型很大程度上是一種風險驅動的方法體系，因爲在每個階段之前及經常發生的循環之前，都必須首先進行風險評估。
項目的敏捷開發
敏捷開發小組主要的工作方式可以歸納爲：作爲一個整體工作；按短迭代週期工作； 每次迭代交付一些成果；
關注業務優先級；檢查與調整。
最重要的因素恐怕是項目的規模。規模增長，面對面的溝通就愈加困難，因此敏捷方法更適用於較小的隊伍，40、30、20、10人或者更少。
大規模的敏捷軟件開發尚處於積極研究的領域。
（我司使用的敏捷開發框架，可做參考：www.learun.cn，直接登錄即可）
四種方式的對比
傳統的瀑布式開發，也就是從需求到設計，從設計到編碼，從編碼到測試，從測試到提交大概這樣的流程，要求每一個開發階段都要做到最好。
特別是前期階段，設計的越完美，提交後的成本損失就越少。
迭代式開發，不要求每一個階段的任務做的都是最完美的，而是明明知道還有很多不足的地方，卻偏偏不去完善它，而是把主要功能先搭建起來爲目的，以最短的時間，最少的損失先完成一個“不完美的成果物”直至提交。然後再通過客戶或用戶的反饋信息，在這個“不完美的成果物”上逐步進行完善。
螺旋開發，很大程度上是一種風險驅動的方法體系，因爲在每個階段之前及經常發生的循環之前，都必須首先進行風險評估。
敏捷開發，相比迭代式開發兩者都強調在較短的開發週期提交軟件，但是，敏捷開發的週期可能更短，並且更加強調隊伍中的高度協作。
敏捷方法有時候被誤認爲是無計劃性和紀律性的方法，實際上更確切的說法是敏捷方法強調適應性而非預見性。適應性的方法集中在快速適應現實的變化。當項目的需求起了變化，團隊應該迅速適應。這個團隊可能很難確切描述未來將會如何變化。原文：老鵰
作者：叫我熊大大
鏈接：https://www.jianshu.com/p/837afc83fa06
來源：簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。