八、迭代結束,確認本次迭代完成的用戶故事,對于完成一部分的用戶故事計算到下一次迭代中。并對本次迭代的過程資產進行總結,形成FAQ方式的文檔進行規整。
同時根據新的需求情況,資源情況,已完成功能的回饋,以及開發中遭遇的不確定性問題,對發布規劃和迭代規劃作出調整。
當前團隊的實踐推行辦法:
第一階段,使用學習網站,或者博客等方式對經驗進行記錄。
第二階段,使用完善的skills對經驗進行記錄,可以方便的組織成培訓文檔,并方便的進行搜索,查找。
九、迭代測試,為了保證用戶功能完整的提交,每個用戶故事開發完成之后都要對該用戶故事進行測試,然后在針對開發中出現的問題進行修復,以便完整的完成一個用戶故事。
第一階段:測試迭代周期和開發迭代周期分開。
每次迭代開始階段由PM告知開發組需要開發的和修復的的用戶故事,同時告知測試組本次迭代需要測試的故事,需要準備的故事,需要復測的故事。
并在分配任務時,把修復故事的工作規劃到本次迭代中來。
每次開發完成的用戶故事點算作本次迭代的速度。
迭代1 迭代2 迭代3 迭代4 迭代5 測試準備故事1,2 測試故事1,2
準備故事3,4 測試故事3,4
準備故事5,6 復測故事1,2
測試故事5,6
準備故事7,8 復測故事3,4
測試故事7,8
準備故事9,10 開發開發故事1,2 開發故事3,4 修復故事1,2
開發故事5,6 修復故事3,4
開發故事7,8 修復故事5,6
開發故事9,10
第二階段:測試迭代周期和開發迭代周期合并。
每次迭代開始階段由PM告知開發組需要開發的故事,同時這些故事也是測試組需要準備測試的故事。要求這些故事分解的工作任務中要包括測試工作和修復工作。
每次測試完成的用戶故事點算作本次迭代的速度
迭代X 測試準備故事1,2,3,4 測試故事1,2,3,4 復測故事1,2,3,4 開發開發故事1,2,3,4 修復故事1,2,3,4 完成故事1,2,3,4
十、發布結束,對本次發布中完成的用戶故事進行會議總結:
1 確定最終完成的用戶故事,以及花費的迭代周期。
2 通過計算得到一個團隊的人平均速度,這個速度做為下次發布規劃的參考。
3 分析哪些用戶故事的估計出現了失誤,以及出現失誤的原因是什么。
4 最初的發布版本在市場上有了初步反饋信息之后,可以延長1個迭代周期用來做為發布版本的反饋收尾。
文章來源于領測軟件測試網 http://www.kjueaiud.com/