認識敏捷開發

[敏捷開發實踐]（1） 認識敏捷開發

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，總結

通過了解傳統瀑布開發模式和新型敏捷開發模式的差異，理解敏捷開發的在現在快節奏時代有更好的適用性：唯快不破，以人為本。

相信每個軟件從業者心中都向往著開放、包容的環境中開展工作，並不是我們要求高，而是我們不喜歡被束縛，不喜歡做一個機器式開發者，我們需要的是尊重和創造。那麼來學習敏捷開發吧！

最後介紹了敏捷開發的兩種常用管理方法：XP和Scrum。