八、迭代結束，確認本次迭代完成的用戶故事，對于完成一部分的用戶故事計算到下一次迭代中。并對本次迭代的過程資產進行總結，形成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/
