敏捷開發流程總結

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
測試驅動開發。正如上面講的，迭代開發的特色是頻繁合入代碼，頻繁公佈版本號。測試驅動開發是保證合入代碼正常執行且不會在後期被破壞的重要手段。這裏的測試主要指單元測試。

敏捷方法反思：
本身參與的敏捷開發項目總的來講不是很是成功，這可能也是業界遇到的通病：
一、對於全新的軟件，在項目早期測試人員就參與並實現本身主動化測試腳本，但實際上軟件的界面等很是不穩定，致使測試人員返工的工做量很是大。
二、對於全新的軟件，資料人員過早參與，後期返工工做量大，緣由同第一點。
三、本身主動化系統測試工做量大，測試人員投入大量的精力在使測試本身主動化起來，而沒有足夠的精力放在真正的測試軟件的功能是否正常。即使是這樣，本身主動化系統測試腳本也多流於形式，測不出深層次的問題。
四、代碼動態檢查工具執行不理想，流於形式。沒有人對Purify有深入的理解和應用經驗，報告中查出來很是多告警，但不知怎樣消除。
五、因爲高速搭建原型，沒有在架構上進行嚴謹的設計，致使後期一直堆砌代碼。
六、異地開發模式下沒法實現高速構建、高速交付，團隊廣泛感受很是疲憊。
七、敏捷開發不提倡加班，但實際上不管是CMM仍是Agile哪種開發模式跟是否加班都沒有一定聯繫。