八、迭代结束，确认本次迭代完成的用户故事，对于完成一部分的用户故事计算到下一次迭代中。并对本次迭代的过程资产进行总结，形成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个迭代周期用来做为发布版本的反馈收尾。
文章来源于领测软件测试网 https://www.ltesting.net/
