Agile——敏捷開發，作為CMM神話崩潰后被引入的一套新的軟件開發模式，這幾年來被廣泛引起關注，并被寄予厚望。敏捷開發在其它業界的應用是否理想不得而知，但下面總結了我所在公司的敏捷開發試驗，希望能夠達到管中窺豹的目的。

敏捷開發宣言——
個體和交互 勝過 過程和工具
能夠工作的軟件 勝過 面面俱到的文檔
客戶合作 勝過 合同談判
響應變化 勝過 遵循計劃
盡管右項也有價值，可是我們覺得左項具有更大的價值。

以上的宣言比較抽象，基于該理念，下面是ThoughtsWork咨詢公司的推崇的n個敏捷開發實踐：
Iteration
迭代開發。能夠工作的軟件勝過面面俱到的文檔。因此，敏捷開發提倡將一個完整的軟件版本號劃分為多個迭代，每一個迭代實現不同的特性。重大的、優先級高的特性優先實現，風險高的特性優先實現。在項目的早期就將軟件的原型開發出來，并基于這個原型在興許的迭代不斷晚上。迭代開發的優點是：盡早編碼，盡早暴露項目的技術風險。盡早使客戶見到可執行的軟件，并提出優化意見。能夠分階段提早向不同的客戶交付可用的版本號。
IterationPlanningMeeting
迭代計劃會議。每一個迭代啟動時，召集整個開發團隊，召開迭代計劃會議，全部的團隊成員暢所欲言，明白迭代的開發任務，解答疑惑。
Story Card/Story Wall/Feature List
在每一個迭代中，架構師負責將全部的特性分解成多個Story Card。每一個Story能夠視為一個獨立的特性。每一個Story應該能夠在最多1個星期內完畢開發，交付提前測試（Pre-Test）。當一個迭代中的全部Story開發完畢以后，測試組再進行完整的測試。在整個測試過程中（pre-test，test），基于Daily build，測試組永遠都是每天從配置庫上取下最新編譯的版本號進行測試，開發者也隨時改動測試人員提交的問題單，并合入配置庫。
敏捷開發的一個特點是開放式辦公，充分溝通，包含測試人員也和開發者一起辦公。基于Story Card的開發方式，團隊會在開放式辦公區域放置一塊白板，上面粘貼著全部的Story Card，按當前的開發狀態貼在4個區域中，各自是：未開發，開發中，預測試中，測試中。Story Card的開發者和測試人員依據開發進度在Story Wall上移動Story Card，更新Story Card的狀態。這樣的方式能夠對項目開發進度有一個非常直觀的了解。
在開發者開始開發一個Story時，ta須要找來相應的測試人員解說Story功能，以便測試人員有一致的理解，同一時候開始自己主動化系統測試腳本的開發。
Standup Meeting
站立會議。每天早上，全部的團隊成員圍在Story Wall周圍，開一個高效率的會議，通常不超過15分鐘，匯報開發進展，提出問題，但不浪費全部人的時間立馬解決這個問題，而是會后個別溝通解決。
Pair Programming
結對編程是指兩個開發者結對編碼。結對編程的優點是：經過兩個人討論后編寫的代碼比一個人獨立完畢會更加的完好，一些大的方向不至于出現偏差，一些細節也能夠被充分考慮到。一個有經驗的開發者和一個新手結對編程，能夠促進新手的成長，保證軟件開發的質量。
CI/Daily Build
持續集成和每日構建能力是否足夠強大是迭代開發是否成功的一個重要基礎?；诿咳諛嫿?。開發者每天將編寫/改動的代碼及時的更新到配置庫中，自己主動化編譯程序每天至少一次自己主動從配置庫上取下代碼，執行自己主動化代碼靜態檢查（如PCLint），單元測試，編譯版本號，安裝，系統測試，動態檢查（如Purify）。以上這些自己主動化任務執行完畢后，會輸出報告，自己主動發送郵件給團隊成員。假設當中存在著不論什么的問題，相關責任人應該及時的改動。
能夠看到，整個開發組頻繁的更新代碼，出現一些問題不可避免。通過測試部又在不停地基于最新的代碼進行測試。新增的問題能否夠被及時發現并消滅掉，取決于自己主動化單元測試和系統測試能力是否足夠強大，特別是自己主動化系統測試能力。假設自己主動化測試僅僅能驗證最簡單的操作，則新合入代碼的隱患將非常難被發現，并遺留到項目后期，形成大的風險。而實際上，提升自己主動化測試的覆蓋率是最困難的。
Retrospect
總結和反思。每一個迭代結束以后，項目組成員召開總結會議，總結好的實踐和教訓，并落實到興許的開發中。
ShowCase
演示。每一個Story開發完畢以后，開發者叫上測試人員，演示軟件功能，以便測試人員充分理解軟件功能。
Refactoring
重構。由于迭代開發模式在項目早期就開發出可執行的軟件原型，一開始開發出來的代碼和架構不可能是最優的、面面俱到的，因此在興許的Story開發中，須要對代碼和架構進行持續的重構。迭代開發對架構師要求非常高。由于架構師要將一個完整的版本號拆分成多個迭代，每一個跌倒由拆分成非常多Story，從架構的角度看，這些Story必須在是有非常強的繼承性，是能夠不斷疊加的，不至于興許開發的Story全然推翻了早期開發的代碼和架構，同一時候也不可避免的須要對代碼進行不斷完好，不斷重構。
TDD
測試驅動開發。正如上面講的，迭代開發的特點是頻繁合入代碼，頻繁公布版本號。測試驅動開發是保證合入代碼正常執行且不會在后期被破壞的重要手段。這里的測試主要指單元測試。

敏捷方法反思：
自己參與的敏捷開發項目總的來說不是非常成功，這可能也是業界遇到的通病：
1、對于全新的軟件，在項目早期測試人員就參與并實現自己主動化測試腳本，但實際上軟件的界面等非常不穩定，導致測試人員返工的工作量非常大。
2、對于全新的軟件，資料人員過早參與，后期返工工作量大，原因同第一點。
3、自己主動化系統測試工作量大，測試人員投入大量的精力在使測試自己主動化起來，而沒有足夠的精力放在真正的測試軟件的功能是否正常。即便是這樣，自己主動化系統測試腳本也多流于形式，測不出深層次的問題。
4、代碼動態檢查工具執行不理想，流于形式。沒有人對Purify有深刻的理解和應用經驗，報告中查出來非常多告警，但不知怎樣消除。
5、由于高速搭建原型，沒有在架構上進行嚴謹的設計，導致后期一直堆砌代碼。
6、異地開發模式下無法實現高速構建、高速交付，團隊普遍感覺非常疲憊。
7、敏捷開發不提倡加班，但實際上無論是CMM還是Agile哪一種開發模式跟是否加班都沒有必定聯系。

總結

以上是生活随笔為你收集整理的敏捷开发流程总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。