需求規(guī)劃完成了之后，我們要確保這些需求能在敏捷開發(fā)的過程當(dāng)中實(shí)現(xiàn)。相比較與瀑布模式，需求規(guī)劃完成了之后，提供一份完整的PRD就可以逐項(xiàng)開始 開發(fā)了，敏捷模式下需求規(guī)劃中的功能清單首先有可能不是一次實(shí)現(xiàn)，會分多次，可能中間還穿插了別的項(xiàng)目，其次是每個功能清單還是再拆分成開發(fā)任務(wù)去分別實(shí) 現(xiàn)，再加上中間的需求變更，所以在需求實(shí)現(xiàn)的過程當(dāng)中是要采取一些措施去避免實(shí)現(xiàn)中的困難的，比如需求實(shí)現(xiàn)的連續(xù)性問題，需求拆分的方式方法，需求變更的 處理，敏捷開發(fā)過程當(dāng)中問題的解決等。

在敏捷開發(fā)模式當(dāng)中，需求實(shí)現(xiàn)的過程有以下幾個方面需要注意：

計(jì)劃會議如何分解Backlog

需求規(guī)劃完成后就形成了確定的需求，體現(xiàn)在敏捷流程當(dāng)中，就是一條產(chǎn)品需求Product Backlog，我們要實(shí)現(xiàn)它，就要開啟一個新的敏捷迭代，通常一個迭代的開始都是通過計(jì)劃會議來開始的。

開計(jì)劃會議的前提是需求規(guī)劃已經(jīng)完成，Product Backlog必須已經(jīng)存在；通常，對單個產(chǎn)品或者項(xiàng)目而言，只能有一個Product Backlog和Product Owner；每個Product Backlog的描述都是完整的，包括主題、描述、優(yōu)先級和驗(yàn)收標(biāo)準(zhǔn)等；Product Owner應(yīng)當(dāng)理解每個Product Backlog的含義；敏捷團(tuán)隊(duì)成員根據(jù)Product Backlog優(yōu)先級，已經(jīng)預(yù)先了解即將開始的迭代大致會涉及的Product Backlog，并能列出相應(yīng)的問題；

注意：Product Owner之外的人也可以添加Product Backlog，但是他們不能說這個Backlog有多重要，也不能定優(yōu)先級，這是Product Owner獨(dú)有的權(quán)利。他們也不能添加時間估算，這是開發(fā)團(tuán)隊(duì)獨(dú)有的權(quán)利。

首先就是確認(rèn)Product Backlog的開發(fā)順序，如果有多條的話，基本都是按照需求的優(yōu)先級的來確定的；

其次是確定Product Backlog是否需要拆分，即判定是否可以在一個迭代內(nèi)完成，或者是否整體需求的優(yōu)先級都是一樣高的；

最后就是按照拆分好的條目重新排定開發(fā)順序；拆分的依據(jù)如下：

1、? 每個拆分出來的條目都是可單獨(dú)驗(yàn)證并上線的；

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

這就涉及到工時估算的問題，一般的估算方法都是讓團(tuán)隊(duì)中不同級別的成員對某個Backlog進(jìn)行估時，并取某個中間值或者團(tuán)隊(duì)都可并接受的值為最終的估算工時；

每日站會確保需求實(shí)現(xiàn)的進(jìn)度

檢查每天的工作進(jìn)展是否按照迭代計(jì)劃在進(jìn)行，永遠(yuǎn)確保資源投入在高優(yōu)先級的Backlog上；

該完成而未完成的任務(wù)有哪些以及是什么原因？及時識別出對迭代中后續(xù)問題的影響，并根據(jù)風(fēng)險(xiǎn)和應(yīng)急方案努力規(guī)避；

遇到的問題應(yīng)該由誰來負(fù)責(zé)解決以及何時必須解決，否則會影響后續(xù)計(jì)劃中哪些條目？尤其是那些有前后依賴關(guān)系的條目；

開發(fā)過程中會出現(xiàn)對原有需求的進(jìn)一步細(xì)化，可能會和迭代計(jì)劃時討論的結(jié)論有一些差異，那么變更的內(nèi)容是否會對既定的業(yè)務(wù)需求產(chǎn)生調(diào)整？

需求變更的原則是在計(jì)劃會議之后，既定的Backlog盡可能保持穩(wěn)定；但是需求變更是很難避免的，若業(yè)務(wù)或者技術(shù)發(fā)生變化時，敏捷團(tuán)隊(duì)該如何響應(yīng)呢？

1、如果有緊急插入的需求，但不影響既定Backlog需求進(jìn)度的，可以在迭代當(dāng)中安排插入開發(fā)；如果會影響原有Backlog需求進(jìn)度的，此時需召集PO開會討論，以決定將哪個Backlog移出本次迭代的開發(fā)計(jì)劃；

2、如果沒有插入需求，但既定Backlog需求完不成，如果通過加班能解決的，盡量安排加班來完成，實(shí)在不行的將剩余部分安排進(jìn)下一個迭代，原則 就是“今日事今日畢”；如果既定Backlog需求不飽和，可以適當(dāng)將未安排的需求移到本迭代內(nèi)開發(fā)，也可以安排一些內(nèi)部的技術(shù)分享或者培訓(xùn)，以提高團(tuán)隊(duì) 的整體實(shí)力；

3、如果遇到一些特殊的情況，比如因?yàn)橐恍┎豢煽沟囊蛩貙?dǎo)致既定的迭代計(jì)劃無法繼續(xù)完成，則應(yīng)該提前終止；并總結(jié)出現(xiàn)類似問題的原因，盡量避免此類 問題再次出現(xiàn)。最常見的就是和第三方的合作項(xiàng)目，有的時候因?yàn)橼s進(jìn)度，合同還沒談好就要開始開發(fā)，到最后合同沒談成，就白干了，這種情況要和業(yè)務(wù)部門協(xié) 商，盡量避免；

敏捷測試保證需求實(shí)現(xiàn)的準(zhǔn)確率

敏捷測試是順應(yīng)敏捷開發(fā)方法、力求達(dá)到質(zhì)量和效率平衡的一系列的測試實(shí)踐。

1、持續(xù)測試、持續(xù)反饋，階段性比較模糊，強(qiáng)調(diào)測試的速度和適應(yīng)性；

2、扮演“用戶代表”角色，確保產(chǎn)品滿足既定的需求；

3、強(qiáng)調(diào)直接的溝通、協(xié)作以及團(tuán)隊(duì)責(zé)任，不太關(guān)注對缺陷的記錄與跟蹤；

4、敏捷功能測試 = 新特性的手工測試+ 原有功能的自動化測試

5、敏捷測試的基礎(chǔ)就是自動化測試，敏捷測試是具有良好的自動化測試框架支撐的快速測試；

一個好的計(jì)劃會議可以將需求拆分成可在一個迭代內(nèi)實(shí)現(xiàn)的幾個部分，再加上每日站會的過程跟蹤，發(fā)現(xiàn)問題及時解決，最后通過敏捷測試及時驗(yàn)證已開發(fā)完成的條目，這樣的過程基本可以保證每個需求的實(shí)現(xiàn)都是按照原先的需求規(guī)劃來的。

上一篇：敏捷開發(fā)模式中的需求規(guī)劃

轉(zhuǎn)自： http://www.itfarmer.com.cn/1805.html