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

[敏捷開發實踐]（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。 

==============================================================================================

返回目錄

<若是對你有幫助，記得點一下推薦哦，若有有不明白或錯誤之處，請多交流>

<轉載聲明：技術須要共享精神，歡迎轉載本博客中的文章，但請註明版權及URL>

軟件管理及.NET 技術交流羣：467189533 

==============================================================================================