從需求規(guī)劃，需求分析到需求設(shè)計(jì)的過(guò)程，都可以歸類為產(chǎn)品的設(shè)計(jì)過(guò)程，這中間現(xiàn)在有很多細(xì)分，諸如市場(chǎng)調(diào)研、競(jìng)品分析、交互設(shè)計(jì)等，其本質(zhì)都是都是產(chǎn)品設(shè)計(jì)，并在最終可以形成一份產(chǎn)出物《產(chǎn)品需求設(shè)計(jì)說(shuō)明書(shū)》，以提供給開(kāi)發(fā)和測(cè)試人員去實(shí)現(xiàn)產(chǎn)品。瀑布型開(kāi)發(fā)模式要求需求必須先全部梳理清楚，才會(huì)投入開(kāi)發(fā)資源，這樣的好處是需求完整，可以從整體上把握產(chǎn)品；而敏捷模式下的產(chǎn)品設(shè)計(jì)，也需要從整體上規(guī)劃產(chǎn)品，但會(huì)拆分成若干個(gè)相互間較為獨(dú)立的部分，分別實(shí)現(xiàn)，最后又能整合成為一個(gè)完整的產(chǎn)品，這就對(duì)產(chǎn)品設(shè)計(jì)人員提出了更高的要求。

通常情況下，當(dāng)我們接到一部分產(chǎn)品的需求之后，會(huì)按業(yè)務(wù)優(yōu)先級(jí)來(lái)做分析，并將相互關(guān)聯(lián)的需求放在一起，或者是按優(yōu)先級(jí)高低進(jìn)行分類，這個(gè)過(guò)程將需求進(jìn)行了劃分，可以依據(jù)這個(gè)劃分來(lái)決定哪些需求是要先做的，哪些是可以后做的。不過(guò)這里有一個(gè)問(wèn)題需要注意，那就是什么樣的需求適合拆分，一般有以下幾種類型：

1、各需求功能之間較為獨(dú)立的適合拆分。一個(gè)產(chǎn)品有十個(gè)功能點(diǎn)，各個(gè)功能點(diǎn)之間相互依賴關(guān)系不強(qiáng)的，松耦合的，就可以每個(gè)功能點(diǎn)單獨(dú)抽取出來(lái)做設(shè)計(jì)；

2、需求功能本身的邏輯遵循某種操作流程的適合拆分。功能的實(shí)現(xiàn)是按照一個(gè)較為固定的流程一步一步往下走的，這樣可以將每一個(gè)步驟單獨(dú)拆分開(kāi)來(lái)設(shè)計(jì)；

3、產(chǎn)品上線之后的版本維護(hù)適合拆分。上線之后，對(duì)一些BUG、問(wèn)題、小需求的縫縫補(bǔ)補(bǔ)，都適合用敏捷的方式來(lái)設(shè)計(jì)；

4、產(chǎn)品上線后的新增需求適合拆分。新增需求一般都針對(duì)某個(gè)功能模塊來(lái)進(jìn)行設(shè)計(jì)，相對(duì)來(lái)說(shuō)較為獨(dú)立，因此也適合敏捷設(shè)計(jì)；

拆分后的需求會(huì)分別寫(xiě)PRD，最后合成一份。敏捷開(kāi)發(fā)模式中把需求都稱為Backlog，維護(hù)backlog表就是一個(gè)對(duì)產(chǎn)品需求進(jìn)行拆分的過(guò)程，拆分完成后再根據(jù)迭代計(jì)劃來(lái)設(shè)計(jì)具體的實(shí)現(xiàn)。一般有名稱、優(yōu)先級(jí)、工作量估算、描述、備注信息等幾個(gè)維度，如下實(shí)例：

通常都把backlog存放在共享的Excel文檔里面，以便團(tuán)隊(duì)成員都可以隨時(shí)查看。一般來(lái)說(shuō)這個(gè)文檔歸產(chǎn)品經(jīng)理維護(hù)，但也并不把其他團(tuán)隊(duì)成員排斥在外。開(kāi)發(fā)人員和測(cè)試人員常常要查閱這個(gè)文檔或者修改工作量估算。需要注意的是，描述Backlog的時(shí)候只需說(shuō)明要達(dá)到什么結(jié)果即可，而不能說(shuō)如何去達(dá)到。

產(chǎn)品的敏捷開(kāi)發(fā)

需求Backlog清單都列出來(lái)了之后，開(kāi)發(fā)人員需要根據(jù)排定的需求優(yōu)先級(jí)，從需求池當(dāng)中選出需求排到當(dāng)前的迭代中，直到所有需求的估算工作量加起來(lái)達(dá)到迭代周期的工作量為止，一般會(huì)留一小部分時(shí)間來(lái)做為緩沖。開(kāi)發(fā)人員集體估算每個(gè)需求的工作量并維護(hù)到上述的Backlog列表中，這些都是在敏捷的迭代計(jì)劃會(huì)上完成的。通常一個(gè)迭代的開(kāi)始都是通過(guò)計(jì)劃會(huì)議來(lái)開(kāi)始的。

接下來(lái)是確定Backlog是否還需要拆分，即判定是否可以在一個(gè)迭代內(nèi)完成，或者是否可以在一天內(nèi)完成，敏捷開(kāi)發(fā)模式可以建立詳細(xì)的考核機(jī)制，每天都跟蹤之前一天的任務(wù)是否已經(jīng)完成。開(kāi)發(fā)人拆分Backlog出來(lái)的結(jié)果就是一條條的Task，然后開(kāi)發(fā)人員根據(jù)各自的任務(wù)來(lái)編寫(xiě)《產(chǎn)品系統(tǒng)設(shè)計(jì)說(shuō)明書(shū)》，最后匯總。

這里涉及到工時(shí)估算的問(wèn)題，一般的估算方法都是讓團(tuán)隊(duì)中不同級(jí)別的成員對(duì)某個(gè)Backlog進(jìn)行估時(shí)，并取某個(gè)中間值或者團(tuán)隊(duì)都可并接受的值為最終的估算工時(shí)。一般拆分的依據(jù)如下：

1、? 每個(gè)拆分出來(lái)的Task都是可單獨(dú)驗(yàn)證并上線的；

2、? 每個(gè)拆分出來(lái)的Task都是可以在單個(gè)迭代內(nèi)完成的；

每日站會(huì)可以跟蹤需求實(shí)現(xiàn)的進(jìn)度，檢查每天的工作進(jìn)展是否按照迭代計(jì)劃在進(jìn)行，永遠(yuǎn)確保資源投入在高優(yōu)先級(jí)的Backlog上；該完成而未完成的任務(wù)有哪些以及是什么原因？及時(shí)識(shí)別出對(duì)迭代中后續(xù)問(wèn)題的影響，并根據(jù)風(fēng)險(xiǎn)和應(yīng)急方案努力規(guī)避；遇到的問(wèn)題應(yīng)該由誰(shuí)來(lái)負(fù)責(zé)解決以及何時(shí)必須解決，否則會(huì)影響后續(xù)計(jì)劃中哪些條目？尤其是那些有前后依賴關(guān)系的條目；開(kāi)發(fā)過(guò)程中會(huì)出現(xiàn)對(duì)原有需求的進(jìn)一步細(xì)化，可能會(huì)和迭代計(jì)劃時(shí)討論的結(jié)論有一些差異，那么變更的內(nèi)容是否會(huì)對(duì)既定的業(yè)務(wù)需求產(chǎn)生調(diào)整？

需求變更一般發(fā)生在計(jì)劃會(huì)議之后，既定的Backlog盡可能保持穩(wěn)定；但是需求變更是很難避免的，若業(yè)務(wù)或者技術(shù)發(fā)生變化時(shí)，敏捷團(tuán)隊(duì)該如何響應(yīng)呢？一般從需求的緊急程度來(lái)考慮，緊急的需要團(tuán)隊(duì)內(nèi)部開(kāi)發(fā)討論，如果能在緩沖時(shí)間內(nèi)完成的就完成掉，如果不能則需要從已安排的任務(wù)當(dāng)中挪出一部分到下個(gè)迭代。

產(chǎn)品的敏捷測(cè)試

有人說(shuō)敏捷測(cè)試是順應(yīng)敏捷開(kāi)發(fā)方法，是力求達(dá)到質(zhì)量和效率平衡的一系列的測(cè)試實(shí)踐，其實(shí)并一定要敏捷開(kāi)發(fā)了才敏捷測(cè)試，其他開(kāi)發(fā)模式下也可以采用敏捷測(cè)試。敏捷測(cè)試只是測(cè)試的一種，強(qiáng)調(diào)從用戶的角度，即從使用系統(tǒng)的用戶的角度來(lái)測(cè)試系統(tǒng)。重點(diǎn)關(guān)注持續(xù)迭代的測(cè)試新開(kāi)發(fā)的功能，而不再?gòu)?qiáng)調(diào)傳統(tǒng)測(cè)試過(guò)程中嚴(yán)格的測(cè)試階段。

所以在敏捷開(kāi)發(fā)模式下，開(kāi)發(fā)人員不是等整個(gè)迭代的任務(wù)都開(kāi)發(fā)完了才送測(cè)，而是做完一個(gè)送測(cè)一個(gè)。前面也講到Backlog拆解成Task時(shí)要求每個(gè)Task都是可以單獨(dú)驗(yàn)證的，也就是說(shuō)每個(gè)Task都是可以單獨(dú)測(cè)試的，這樣測(cè)試人員可以對(duì)每個(gè)已開(kāi)發(fā)完成的Task進(jìn)行測(cè)試，及時(shí)發(fā)現(xiàn)問(wèn)題，及時(shí)改進(jìn)。這種模式下，效率高的話可以精確控制到每天的開(kāi)發(fā)結(jié)果驗(yàn)證，這樣可以確保產(chǎn)品需求都是按照計(jì)劃來(lái)進(jìn)行的，并且不會(huì)偏離需求本身。

測(cè)試人員也是從迭代計(jì)劃會(huì)議開(kāi)始參與到每個(gè)迭代當(dāng)中，對(duì)本次迭代中安排的所有需求清單編寫(xiě)測(cè)試用例，最后形成一份匯總后的《測(cè)試用例及測(cè)試報(bào)告》。在每天的站會(huì)上，測(cè)試人員可以及時(shí)告知每天的測(cè)試進(jìn)展和測(cè)試的問(wèn)題，及時(shí)幫助開(kāi)發(fā)人員修正。這樣測(cè)試人員就可以持續(xù)測(cè)試、持續(xù)反饋，整個(gè)測(cè)試的階段性會(huì)比較模糊，主要強(qiáng)調(diào)測(cè)試的速度和適應(yīng)性。

敏捷測(cè)試要求測(cè)試人員去扮演“用戶”的角色，確保產(chǎn)品滿足既定的需求；強(qiáng)調(diào)直接的溝通、協(xié)作以及團(tuán)隊(duì)責(zé)任，不太關(guān)注對(duì)缺陷的記錄與跟蹤；需要建立起有效的自動(dòng)化測(cè)試方法，對(duì)老模塊的功能用自動(dòng)化測(cè)試，新模塊用手工測(cè)試結(jié)合的方法。

從以上的內(nèi)容可以看出，一個(gè)好的高效的迭代計(jì)劃會(huì)議非常重要，可以將需求拆分成可在一個(gè)迭代內(nèi)實(shí)現(xiàn)的幾個(gè)部分，再加上每日站會(huì)的過(guò)程跟蹤，發(fā)現(xiàn)問(wèn)題及時(shí)解決，最后通過(guò)敏捷測(cè)試及時(shí)驗(yàn)證已開(kāi)發(fā)完成的任務(wù)，這樣的過(guò)程基本可以保證每個(gè)需求的實(shí)現(xiàn)都是按照原先的需求規(guī)劃來(lái)的。

敏捷開(kāi)發(fā)模式下也并不是沒(méi)有文檔的要求，設(shè)計(jì)、開(kāi)發(fā)、測(cè)試這樣的過(guò)程下來(lái)，會(huì)有《產(chǎn)品需求設(shè)計(jì)說(shuō)明書(shū)》、《產(chǎn)品系統(tǒng)設(shè)計(jì)說(shuō)明書(shū)》、《測(cè)試用例及測(cè)試報(bào)告》三份文檔，而且文檔也是走敏捷的模式，每個(gè)迭代更新其中的一部分，最后合成在一起，這樣的方式有過(guò)程也有記錄，敏捷開(kāi)發(fā)照樣重視文檔的作用，也重視文檔的維護(hù)，只不過(guò)比較強(qiáng)調(diào)宜少且精煉。

敏捷開(kāi)發(fā)是否深入到團(tuán)隊(duì)中，一般是根據(jù)團(tuán)隊(duì)呈現(xiàn)出來(lái)的工作氛圍、項(xiàng)目運(yùn)作狀態(tài)、團(tuán)隊(duì)成員的感性認(rèn)識(shí)等方面來(lái)評(píng)估團(tuán)隊(duì)和其開(kāi)發(fā)過(guò)程的敏捷成熟度。團(tuán)隊(duì)有共同的愿景，并且對(duì)這個(gè)愿景充滿信心的；有明確的階段目標(biāo)并且為每個(gè)成員所知曉；知道當(dāng)前計(jì)劃：做什么、何時(shí)完成、預(yù)期效果等；所有任務(wù)是低耦合的，團(tuán)隊(duì)之間緊密協(xié)作。

采用敏捷開(kāi)發(fā)模式，一定要把敏捷設(shè)計(jì)、敏捷開(kāi)發(fā)、敏捷測(cè)試連在一起，這樣才能最大限度的發(fā)揮敏捷的效用。

來(lái)源：《網(wǎng)絡(luò)傳播》2013年第8期，作者：朱軍華