敏捷開發流程

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哪一種開發模式跟是否加班都沒有必然聯絡。

敏捷開發流程

敏捷開發流程

敏捷開發流程

Scrum敏捷開發流程

相關推薦