摘要：Ulf Eriksson根據(jù)自己多年的敏捷開發(fā)經(jīng)歷，總結(jié)了6個(gè)實(shí)施敏捷開發(fā)的技巧：快速迭代,、讓測試人員和開發(fā)者參與需求討論,、編寫可測試的需求文檔、多溝通&盡量減少文檔,、做好產(chǎn)品原型,、及早考慮測試等。
在大型企業(yè)中經(jīng)常是各種軟件開發(fā)模式混用,，一些采用敏捷開發(fā),，一些則是采用傳統(tǒng)的瀑布式或RUP（統(tǒng)一軟件開發(fā)過程）。敏捷開發(fā),，相對傳統(tǒng)軟件開發(fā)模式,，它主要是針對快速變化的需求，不斷優(yōu)化管理流程,，最終推出優(yōu)質(zhì)軟件,。
原文作者Ulf Eriksson，是一家在線問題跟蹤軟件公司的創(chuàng)始人之一,，他是敏捷開發(fā)的忠實(shí)粉絲,，已經(jīng)進(jìn)行了多年敏捷開發(fā)的實(shí)踐。下面內(nèi)容主要是作者根據(jù)自己多年經(jīng)歷進(jìn)行的經(jīng)驗(yàn)總結(jié),。
1. 快速迭代
相對那種半年一次的大版本發(fā)布來說,，小版本的需求、開發(fā)和測試更加簡單快速,。一些公司,，一年僅發(fā)布僅2~3個(gè)版本，發(fā)布流程緩慢,，它們?nèi)圆捎闷俨奸_發(fā)模式,，更嚴(yán)重的是對敏捷開發(fā)模式存在誤解。
由一年發(fā)布2個(gè)版本轉(zhuǎn)到一個(gè)月發(fā)布2個(gè)版本,，這也不太可能,。但是現(xiàn)在來看，快速迭代已經(jīng)成為事實(shí)標(biāo)準(zhǔn),，關(guān)鍵是要比目前的版本發(fā)布速度更快一些,。
快速迭代,，可以逼迫團(tuán)隊(duì)不斷優(yōu)化流程、提升工作效率,，不要在無足輕重的事情上浪費(fèi)時(shí)間,。如果離deadline還有6個(gè)月，那么整個(gè)工作節(jié)奏必然悠哉,。如果每月發(fā)布一個(gè)版本,，那么較以前效率必然會(huì)更高。如果發(fā)布周期過長,，導(dǎo)致無法盡快發(fā)現(xiàn)用戶需求,，進(jìn)而無法及時(shí)改進(jìn)產(chǎn)品。
2. 讓測試人員和開發(fā)者參與需求討論
需求討論以研討組的形式展開最有效率,。研討組,，需要包括測試人員和開發(fā)者,，這樣可以更加輕松定義可測試的需求,，將需求分組并確定優(yōu)先級(jí)。
同時(shí),，該種方式也可以充分利用團(tuán)隊(duì)成員間的互補(bǔ)特性,。如此確定的需求往往比開需求討論大會(huì)的形式效率更高，大家更活躍,，參與感更強(qiáng),。
確定需求時(shí)，不要過度盯在細(xì)節(jié)上,。需求報(bào)告過于詳細(xì),，就是一種不敏捷的習(xí)慣，還浪費(fèi)大家的時(shí)間,。當(dāng)然,，不能錯(cuò)過好點(diǎn)子，但就是不要太細(xì),，因?yàn)轫?xiàng)目真正實(shí)施起來時(shí)需求將會(huì)產(chǎn)生很大的變動(dòng),。
3. 編寫可測試的需求文檔
開始就要用“用戶故事”（User Story）的方法來編寫需求文檔。這種方法,，可以讓我們將注意力放在需求上,，而不是解決方法和實(shí)施技術(shù)上。過早的提及技術(shù)實(shí)施方案,，會(huì)降低對需求的注意力,。
規(guī)劃業(yè)務(wù)需求，可以采用“3W模板”,，也就是：
- 誰（Who）
- 是什么（What）
- 為什么（Why）
上面的3W實(shí)際上就是描述了相關(guān)利益者是誰,，他們想要什么，他們?yōu)槭裁从羞@種需求。下面舉一例子進(jìn)行說明：
| 誰（Who） |
是什么（What） |
為什么（Why） |
用戶
|
希望借助一個(gè)應(yīng)用程序在不同服務(wù)器間傳輸文件
|
為了存儲(chǔ)項(xiàng)目數(shù)據(jù) |
為了更加接近“用戶故事”,，我們可以改寫為：
| 誰（Who） |
是什么（What） |
為什么（Why） |
| 消費(fèi)者/用戶 |
想將歸檔過程數(shù)字化 |
為了增強(qiáng)溝通,，提高分享效率 |
敏捷項(xiàng)目中編寫用戶故事有一個(gè)常用模板：作為一名[用戶類型]，我想要[需求],，以便于[原因],。應(yīng)用到這個(gè)例子，就是：作為一名用戶,，我想要將歸檔程序數(shù)字化,，以便于增強(qiáng)溝通、提高分享效率,。
多數(shù)情況下,，需求內(nèi)容需要更加充實(shí)和詳細(xì)，這一步要放到后面做,，開始不要這樣,。用戶故事的方法有時(shí)會(huì)因過于簡短、不斷重復(fù)而受到批評,。這里我們必須明白：需求文檔不是散文或詩歌,，應(yīng)該清晰、簡明地描述用戶需求,；需求文檔的重點(diǎn)也在于此,，不要管形式多變或內(nèi)容是否重復(fù)這樣的問題。
4. 多溝通,，盡量減少文檔
任何項(xiàng)目中,，溝通都是一個(gè)常見的問題。好的溝通,，是敏捷開發(fā)的先決條件,。在圈子里面混得越久，越會(huì)強(qiáng)調(diào)良好高效的溝通的重要性,。
團(tuán)隊(duì)要確保日常的交流,，面對面溝通比郵件強(qiáng)得多。
敏捷開發(fā)鼓勵(lì)日常的協(xié)調(diào)會(huì)議和碰頭會(huì),，5~7人參與的會(huì)議盡量控制在10分鐘內(nèi),。碰頭時(shí)，要過一遍昨天完成了什么,，今天要做什么,，哪些問題仍待討論?？梢杂肂urndown Chart（燃盡圖）來形象展示工作進(jìn)度,。每次迭代的時(shí)候也都要開一個(gè)計(jì)劃會(huì)議和評審會(huì)議,，一般需要的時(shí)間可能會(huì)長些，比如半天,。這些會(huì)議的目的就是對工作查缺補(bǔ)漏,。
評審會(huì)議很重要，傳統(tǒng)開發(fā)模式往往略過該環(huán)節(jié),，導(dǎo)致一些錯(cuò)誤做法不斷重復(fù),，好的做法無法推廣。
開會(huì)時(shí),，可以將原先的分組打散,，讓整個(gè)團(tuán)隊(duì)都參與到項(xiàng)目的需求討論和測試中來，這樣可以突出成員個(gè)人,，讓大家更樂意參與,。
5. 做好產(chǎn)品原型
建議使用草圖和模型來闡明用戶界面。并不是所有人都可以理解一份復(fù)雜的文檔,，但人人都會(huì)看圖,。
一個(gè)常見的問題是軟件新的功能與用戶想要的不一致。為了避免這一問題,，可以模擬真實(shí)操作,，改進(jìn)模擬操作過程中難以理解和不清楚的操作行為,。
6. 及早考慮測試
及早地考慮測試在敏捷開發(fā)中很重要,。傳統(tǒng)的軟件開發(fā)，測試用例很晚才開始寫,，這導(dǎo)致過晚發(fā)現(xiàn)需求中存在的問題,，使得改進(jìn)成本過高。較早地開始編寫測試用例,，當(dāng)需求完成時(shí),，可以接受的測試用例也基本一塊完成了。
敏捷開發(fā)中一個(gè)常見問題就是開發(fā)者沒有對已有的代碼庫進(jìn)行充分的回歸測試,。迭代周期很短,，從開始到交付就是4周的時(shí)間，這樣可以對迭代的設(shè)計(jì),、實(shí)現(xiàn)和底層測試一塊進(jìn)行回歸測試,。
一系列迭代之后，可以只針對測試活動(dòng)再補(bǔ)充一個(gè)迭代,。這個(gè)迭代可以將重點(diǎn)放在系統(tǒng)測試,、與其他系統(tǒng)的集成度、性能等方面,。敏捷開發(fā)過程中,，可能會(huì)導(dǎo)致過少的測試文檔,。如果迭代周期為1個(gè)月左右，可以不必對測試文檔過于要求,，但要制定好測試策略,。
最后
可能大多數(shù)公司或團(tuán)隊(duì)還沒有開始嘗試敏捷開發(fā)，不過可以開始從點(diǎn)滴做起,，比如開碰頭會(huì),、為項(xiàng)目管理采用一個(gè)更加高效的管理工具等等。最后,，希望上面的建議能夠?yàn)榇蠹业能浖_發(fā)管理帶來幫助,。（編譯/王殿進(jìn)）
