敏捷開發模式中的需求實現

0 評論 25466 瀏覽 49 收藏 8 分鐘

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

在敏捷開發模式當中,需求實現的過程有以下幾個方面需要注意:

計劃會議如何分解Backlog

需求規劃完成后就形成了確定的需求,體現在敏捷流程當中,就是一條產品需求Product Backlog,我們要實現它,就要開啟一個新的敏捷迭代,通常一個迭代的開始都是通過計劃會議來開始的。

開計劃會議的前提是需求規劃已經完成,Product Backlog必須已經存在;通常,對單個產品或者項目而言,只能有一個Product Backlog和Product Owner;每個Product Backlog的描述都是完整的,包括主題、描述、優先級和驗收標準等;Product Owner應當理解每個Product Backlog的含義;敏捷團隊成員根據Product Backlog優先級,已經預先了解即將開始的迭代大致會涉及的Product Backlog,并能列出相應的問題;

注意:Product Owner之外的人也可以添加Product Backlog,但是他們不能說這個Backlog有多重要,也不能定優先級,這是Product Owner獨有的權利。他們也不能添加時間估算,這是開發團隊獨有的權利。

首先就是確認Product Backlog的開發順序,如果有多條的話,基本都是按照需求的優先級的來確定的;

其次是確定Product Backlog是否需要拆分,即判定是否可以在一個迭代內完成,或者是否整體需求的優先級都是一樣高的;

最后就是按照拆分好的條目重新排定開發順序;拆分的依據如下:

1、? 每個拆分出來的條目都是可單獨驗證并上線的;

2、? 每個拆分出來的條目都是可以在單個迭代內完成的;

這就涉及到工時估算的問題,一般的估算方法都是讓團隊中不同級別的成員對某個Backlog進行估時,并取某個中間值或者團隊都可并接受的值為最終的估算工時;

敏捷開發中的需求實現

每日站會確保需求實現的進度

檢查每天的工作進展是否按照迭代計劃在進行,永遠確保資源投入在高優先級的Backlog上;

該完成而未完成的任務有哪些以及是什么原因?及時識別出對迭代中后續問題的影響,并根據風險和應急方案努力規避;

遇到的問題應該由誰來負責解決以及何時必須解決,否則會影響后續計劃中哪些條目?尤其是那些有前后依賴關系的條目;

開發過程中會出現對原有需求的進一步細化,可能會和迭代計劃時討論的結論有一些差異,那么變更的內容是否會對既定的業務需求產生調整?

需求變更的原則是在計劃會議之后,既定的Backlog盡可能保持穩定;但是需求變更是很難避免的,若業務或者技術發生變化時,敏捷團隊該如何響應呢?

1、如果有緊急插入的需求,但不影響既定Backlog需求進度的,可以在迭代當中安排插入開發;如果會影響原有Backlog需求進度的,此時需召集PO開會討論,以決定將哪個Backlog移出本次迭代的開發計劃;

2、如果沒有插入需求,但既定Backlog需求完不成,如果通過加班能解決的,盡量安排加班來完成,實在不行的將剩余部分安排進下一個迭代,原則 就是“今日事今日畢”;如果既定Backlog需求不飽和,可以適當將未安排的需求移到本迭代內開發,也可以安排一些內部的技術分享或者培訓,以提高團隊 的整體實力;

3、如果遇到一些特殊的情況,比如因為一些不可抗的因素導致既定的迭代計劃無法繼續完成,則應該提前終止;并總結出現類似問題的原因,盡量避免此類 問題再次出現。最常見的就是和第三方的合作項目,有的時候因為趕進度,合同還沒談好就要開始開發,到最后合同沒談成,就白干了,這種情況要和業務部門協 商,盡量避免;

敏捷測試保證需求實現的準確率

敏捷測試是順應敏捷開發方法、力求達到質量和效率平衡的一系列的測試實踐。

敏捷開發中的需求實現

1、持續測試、持續反饋,階段性比較模糊,強調測試的速度和適應性;

2、扮演“用戶代表”角色,確保產品滿足既定的需求;

3、強調直接的溝通、協作以及團隊責任,不太關注對缺陷的記錄與跟蹤;

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

5、敏捷測試的基礎就是自動化測試,敏捷測試是具有良好的自動化測試框架支撐的快速測試;

敏捷開發中的需求實現

一個好的計劃會議可以將需求拆分成可在一個迭代內實現的幾個部分,再加上每日站會的過程跟蹤,發現問題及時解決,最后通過敏捷測試及時驗證已開發完成的條目,這樣的過程基本可以保證每個需求的實現都是按照原先的需求規劃來的。

上一篇:敏捷開發模式中的需求規劃

轉自: http://www.itfarmer.com.cn/1805.html

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!