敏捷開(kāi)發(fā)實(shí)踐分享

Agile——敏捷開(kāi)發(fā)，作為CMM神話(huà)崩潰后被引入的一套新的軟件開(kāi)發(fā)模式，這幾年來(lái)被廣泛引起關(guān)注，并被寄予厚望。敏捷開(kāi)發(fā)在其他業(yè)界的應(yīng)用是否理想不得而知，但以下總結(jié)了我所在公司的敏捷開(kāi)發(fā)試驗(yàn)，希望可以達(dá)到管中窺豹的目的。

敏捷開(kāi)發(fā)宣言——
個(gè)體和交互 勝過(guò) 過(guò)程和工具
可以工作的軟件 勝過(guò) 面面俱到的文檔
客戶(hù)合作 勝過(guò) 合同談判
響應(yīng)變化 勝過(guò) 遵循計(jì)劃
雖然右項(xiàng)也有價(jià)值，但是我們認(rèn)為左項(xiàng)具有更大的價(jià)值。

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