1，提要
軟體開發是一個系統工程，包括最初的可行性分析、再到設計、開發、測試、維護等整個生命週期。在這個過程中某些階段的失誤或說是變化，都可能增加整個軟體專案的風險。
如何在保證效率的基礎上還能安計劃、保證質量的完成軟體專案？於是產生了軟體開發的一些方法，這個方法不是指具體有編碼階段的各種設計模式和技巧，而是在整個軟體開發策略層面的方法。
傳統瀑布模式和新型的敏捷開發就是其中最常用的方法，後面著重討論敏捷開發的優缺點和敏捷開發的基礎知識。
2，常用的開發模式
（1）傳統的瀑布式開發，也就是從需求到設計，從設計到編碼，從編碼到測試，從測試到交付大概這樣的流程，要求每一個開發階段都要做到最好。特別是前期階段，設計的越完美，提交後的成本損失就越少。下面就是典型的瀑布模型。

認識敏捷開發
（3）原型模型，原型化模型第一步就是建立一個快速原型，能夠滿足專案干係人與未來的使用者可以與原型進行互動，再通過與相關干係人進行充分的討論和分析，最終弄清楚當前系統的需求，進行了充分的瞭解之後，在原型的基礎上開發出使用者滿意的產品。
（3）螺旋模型，將瀑布模型和快速原型模型結合，並特別強調專案風險。通常分為四個階段組成：制定計劃、風險分析、實施工程和客戶評估。一般第一個原型只是雙方交流的參考，隨著後面的版本完善，最終達到目標。比較適合大型專案。
（2）新型的敏捷開發，即迭代式開發，不要求非常完美的需求分析、設計、文件，而是在最短時間內完成一個框架，然後不斷迭代，不斷測試，直至交付。
但它並不是不需要文件，不需要從需求、設計、開發、測試這樣一個過程，在每個迭代過程中仍然需要做這樣的事情。
但是敏捷開發更加註重人的因素，不像瀑布式開發那樣，由專門的需求人員採集使用者需求，由設計師完成設計文件。敏捷開發每個人都是需要了解專案的需求，並不斷的進行小會議，不斷的測試修改，直到提交。
敏捷開發則是以測試驅動開發，而瀑布式開發是以文件驅動開發。
下圖是Scrum(敏捷開發的一種)敏捷開發模式

認識敏捷開發
3，傳統開發模式和敏捷開發的優缺點
主要對比比較常用的瀑布模型和敏捷開發。
(1)瀑布式開發：
a.講求階段明確，嚴格把軟體專案的開發分隔成各個開發階段：需求分析，要件定義，基本設計，詳細設計，編碼，單體測試，結合測試，系統測試等。使用里程碑的方式，嚴格定義了各開發階段的輸入和輸出。如果達不到要求的輸出，下一階段的工作就不展開。 軟體生命週期前期造成的Bug的影響比後期的大的多。
b.特別強調文件，在開發的後期才會看到軟體的模樣。在這種情況下，文件的重要性彷彿已經超過了程式碼的重要性。
c.流水式的開發，瀑布模型把開發人員定義為流水線上的工人。由於各階段的開發人員只能接觸到自己工作範圍內的東西，所以對客戶需求的理解程度高低不等。對於客戶需求變更，編碼人員會比設計人員更容易產生很強的抵觸情緒。當然好的方面就是按一定規範開發，如果有人員流失，短時間內可以補上去，除了核心的東西有文件參考外，開發過程本身就是在一定框架內的。
d.進度一目瞭解，瀑布模型產生的管理文件(計劃書，進度表)等，能讓不太瞭解該專案的人也能看懂專案的進度情況（只有能看懂百分比就行），很適合向領導彙報用。所以管理人員比較喜歡瀑布模型，但是開發人員不喜歡，因為它束縛了開發人員的創造性。
（2）敏捷開發
a.唯快不破，敏捷即是快之意，不僅思維快節奏，而且行為也是快節奏，因上受到當今快節奏社會的喜愛。
b.以人為本，和瀑布開發對應的文件為主來說，在敏捷開發中更強調人，在細節開發上個人可以發揮主觀性，使用自己善長的技術和模式開發，而非機器式的開發，容易激發團隊成員興趣和創造力。除了專案參與者，人的因素中更考慮到與客戶的溝通。每個成員都需要從溝通中，會議交流中，不斷實現迭代。
c.結果第一，不強調文件，突破束縛，軟體的最終結果才是重點，文件等都是為軟體開發本身服務的，完成了一個優秀的、質量可靠的軟體才是敏捷開發的重中之重。
d.迭代開發，迭代是敏捷開發的核心，不斷迭代測試的過程，實際上就是精益求精的過程，正和現在這個社會的工匠精神相吻合。
e.整合不易，快速迭代，就需要分割整體業務，對於複雜的客戶需求，如何兼顧分割與整體，並不容易，這個需要在專案設計之初考慮到。
4，敏捷開發管理方法
敏捷開發的管理方法有很多種，比較廣泛應用的有XP、Scrum等。既然都是敏捷開發，他們都有共同點，強調高速響應變更、以人為主重視團隊成員自身發展，傾向採用迭代式的軟體開發生命週期模型。
敏捷開發中，XP和Scrum的區別：
a.迭代週期不同,XP的每個Sprint(衝階)的長度大概為1~2周，而Scrum為2~4周。
b.迭代週期內專一性不同，XP在一個迭代中，如一個User Story(使用者素材，也就是一個使用者需求)還未實現，可以考慮另外需求替換，原則是時間當量相等。而Scrum不允許這樣，一旦迭代開發會畢，任何需求不允新增進入，並有Master嚴格把關，使團隊不受干擾。
c.User Story優先順序機制不同,XP必須遵守優先順序（當然需要先確實優先順序），Scrum更靈活，可以不遵循優先順序。比如依賴關係中，雖然 US-A高於US-B，但由於要完成A需依賴B，則需要先開發B。
d.實施中是否採用工程方法問題兩者做法不同，Scrum這點上沒有工程實踐處方，體現的是以人為本，自我創造；而XP必須嚴格按TDD,自動測試，結對程式設計，簡單設計，重構等約束團隊，似乎看起來XP的方式束縛了團隊，但需要看這個約束的程度，過細則會讓人感覺與“以人為本，自我創新”思想不符，但優點就是一定程度上的規範更有利於保證軟體質量。
一個讓人困惑的矛盾, 因為xp的理念，結合敏捷模式，表達給團隊的資訊是“你是一個完全自我管理的組織， 但你必須要實現TDD, 結對程式設計, ...等等”
通過區別，看出： Scrum非常突出Self-Orgnization, XP注重強有力的工程實踐約束
5，總結
通過了解傳統瀑布開發模式和新型敏捷開發模式的差異，理解敏捷開發的在現在快節奏時代有更好的適用性：唯快不破，以人為本。