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