Agile——敏捷開發(fā)，作為CMM神話崩潰后被引入的一套新的軟件開發(fā)模式，這幾年來被廣泛引起關(guān)注，并被寄予厚望。敏捷開發(fā)在其他業(yè)界的應(yīng)用是否理想不得而知，但以下總結(jié)了我所在公司的敏捷開發(fā)試驗，希望可以達到管中窺豹的目的。
敏捷開發(fā)宣言——
個體和交互 勝過 過程和工具
可以工作的軟件 勝過 面面俱到的文檔
客戶合作 勝過 合同談判
響應(yīng)變化 勝過 遵循計劃
雖然右項也有價值，但是我們認為左項具有更大的價值。
以上的宣言比較抽象，基于該理念，以下是ThoughtsWork咨詢公司的推崇的n個敏捷開發(fā)實踐：
Iteration
迭代開發(fā)?？梢怨ぷ鞯能浖龠^面面俱到的文檔。因此，敏捷開發(fā)提倡將一個完整的軟件版本劃分為多個迭代，每個迭代實現(xiàn)不同的特性。重大的、優(yōu)先級高的特性優(yōu)先實現(xiàn)，風(fēng)險高的特性優(yōu)先實現(xiàn)。在項目的早期就將軟件的原型開發(fā)出來，并基于這個原型在后續(xù)的迭代不斷晚上。迭代開發(fā)的好處是：盡早編碼，盡早暴露項目的技術(shù)風(fēng)險。盡早使客戶見到可運行的軟件，并提出優(yōu)化意見?？梢苑蛛A段提早向不同的客戶交付可用的版本。
IterationPlanningMeeting
迭代計劃會議。每個迭代啟動時，召集整個開發(fā)團隊，召開迭代計劃會議，所有的團隊成員暢所欲言，明確迭代的開發(fā)任務(wù)，解答疑惑。
Story Card/Story Wall/Feature List
在每個迭代中，架構(gòu)師負責(zé)將所有的特性分解成多個Story Card。每個Story可以視為一個獨立的特性。每個Story應(yīng)該可以在最多1個星期內(nèi)完成開發(fā)，交付提前測試（Pre-Test）。當一個迭代中的所有Story開發(fā)完畢以后，測試組再進行完整的測試。在整個測試過程中（pre-test，test），基于Daily build，測試組永遠都是每天從配置庫上取下最新編譯的版本進行測試，開發(fā)人員也隨時修改測試人員提交的問題單，并合入配置庫。
敏捷開發(fā)的一個特點是開放式辦公，充分溝通，包括測試人員也和開發(fā)人員一起辦公?；赟tory Card的開發(fā)方式，團隊會在開放式辦公區(qū)域放置一塊白板，上面粘貼著所有的Story Card，按當前的開發(fā)狀態(tài)貼在4個區(qū)域中，分別是：未開發(fā)，開發(fā)中，預(yù)測試中，測試中。Story Card的開發(fā)人員和測試人員根據(jù)開發(fā)進度在Story Wall上移動Story Card，更新Story Card的狀態(tài)。這種方式可以對項目開發(fā)進度有一個非常直觀的了解。
在開發(fā)人員開始開發(fā)一個Story時，ta需要找來對應(yīng)的測試人員講解Story功能，以便測試人員有一致的理解，同時開始自動化系統(tǒng)測試腳本的開發(fā)。
Standup Meeting
站立會議。每天早上，所有的團隊成員圍在Story Wall周圍，開一個高效率的會議，通常不超過15分鐘，匯報開發(fā)進展，提出問題，但不浪費所有人的時間立刻解決問題，而是會后個別溝通解決。
Pair Programming
結(jié)對編程是指兩個開發(fā)人員結(jié)對編碼。結(jié)對編程的好處是：經(jīng)過兩個人討論后編寫的代碼比一個人獨立完成會更加的完善，一些大的方向不至于出現(xiàn)偏差，一些細節(jié)也可以被充分考慮到。一個有經(jīng)驗的開發(fā)人員和一個新手結(jié)對編程，可以促進新手的成長，保證軟件開發(fā)的質(zhì)量。
CI/Daily Build
持續(xù)集成和每日構(gòu)建能力是否足夠強大是迭代開發(fā)是否成功的一個重要基礎(chǔ)?；诿咳諛?gòu)建。開發(fā)人員每天將編寫/修改的代碼及時的更新到配置庫中，自動化編譯程序每天至少一次自動從配置庫上取下代碼，執(zhí)行自動化代碼靜態(tài)檢查（如PCLint），單元測試，編譯版本，安裝，系統(tǒng)測試，動態(tài)檢查（如Purify）。以上這些自動化任務(wù)執(zhí)行完畢后，會輸出報告，自動發(fā)送郵件給團隊成員。如果其中存在著任何的問題，相關(guān)責(zé)任人應(yīng)該及時的修改。
可以看到，整個開發(fā)組頻繁的更新代碼，出現(xiàn)一些問題不可避免。通過測試部又在不停地基于最新的代碼進行測試。新增的問題是否能夠被及時發(fā)現(xiàn)并消滅掉，取決于自動化單元測試和系統(tǒng)測試能力是否足夠強大，特別是自動化系統(tǒng)測試能力。如果自動化測試只能驗證最簡單的操作，則新合入代碼的隱患將很難被發(fā)現(xiàn)，并遺留到項目后期，形成大的風(fēng)險。而實際上，提升自動化測試的覆蓋率是最困難的。
Retrospect
總結(jié)和反思。每個迭代結(jié)束以后，項目組成員召開總結(jié)會議，總結(jié)好的實踐和教訓(xùn)，并落實到后續(xù)的開發(fā)中。
ShowCase
演示。每個Story開發(fā)完成以后，開發(fā)人員叫上測試人員，演示軟件功能，以便測試人員充分理解軟件功能。
Refactoring
重構(gòu)。因為迭代開發(fā)模式在項目早期就開發(fā)出可運行的軟件原型，一開始開發(fā)出來的代碼和架構(gòu)不可能是最優(yōu)的、面面俱到的，因此在后續(xù)的Story開發(fā)中，需要對代碼和架構(gòu)進行持續(xù)的重構(gòu)。迭代開發(fā)對架構(gòu)師要求很高。因為架構(gòu)師要將一個完整的版本拆分成多個迭代，每個跌倒由拆分成很多Story，從架構(gòu)的角度看，這些Story必須在是有很強的繼承性，是可以不斷疊加的，不至于后續(xù)開發(fā)的Story完全推翻了早期開發(fā)的代碼和架構(gòu)，同時也不可避免的需要對代碼進行不斷完善，不斷重構(gòu)。
TDD
測試驅(qū)動開發(fā)。正如上面講的，迭代開發(fā)的特點是頻繁合入代碼，頻繁發(fā)布版本。測試驅(qū)動開發(fā)是保證合入代碼正常運行且不會在后期被破壞的重要手段。這里的測試主要指單元測試。
敏捷方法反思：
自己參與的敏捷開發(fā)項目總的來說不是很成功，這可能也是業(yè)界遇到的通?。?br>1、對于全新的軟件，在項目早期測試人員就參與并實現(xiàn)自動化測試腳本，但實際上軟件的界面等非常不穩(wěn)定，導(dǎo)致測試人員返工的工作量很大。
2、對于全新的軟件，資料人員過早參與，后期返工工作量大，原因同第一點。
3、自動化系統(tǒng)測試工作量大，測試人員投入大量的精力在使測試自動化起來，而沒有足夠的精力放在真正的測試軟件的功能是否正常。即便是這樣，自動化系統(tǒng)測試腳本也多流于形式，測不出深層次的問題。
4、代碼動態(tài)檢查工具執(zhí)行不理想，流于形式。沒有人對Purify有深刻的理解和應(yīng)用經(jīng)驗，報告中查出來很多告警，但不知如何消除。
5、由于快速搭建原型，沒有在架構(gòu)上進行嚴謹?shù)脑O(shè)計，導(dǎo)致后期一直堆砌代碼。
6、異地開發(fā)模式下無法實現(xiàn)快速構(gòu)建、快速交付，團隊普遍感覺很疲憊。
7、敏捷開發(fā)不提倡加班，但實際上不管是CMM還是Agile哪一種開發(fā)模式跟是否加班都沒有必然聯(lián)系
