六、迭代开始，在迭代开始时召开迭代启动会，分配迭代周期内的用户故事和工作任务到个人，每个工作任务必须精确到个人，同一个用户故事的不同工作任务可以根据情况适当分配给不同的人来完成。

    当前团队的实践推行办法：

    第一阶段，任务分配给个人，通常一个故事的任务分配给同一个人。

    第二阶段，任务分配给结对，通常一个故事的任务分配给同一个结对。

七、迭代进行，每日早对昨日完成的工作任务和问题进行汇报，并且同时计划今天需要完成的工作任务，对于迭代过程中的进度和问题进行及时的观察和调整，要求每个人完成某个任务之后要及时的告知整个小组知道（qq群的方式最为快捷）。

    当前团队的实践推行办法：

    第一阶段，由PM及时地对当日工作进行询问。并负责把遇到的问题跑出来进行解决。

    第二阶段，小组成员主动地对已经完成的任务进行汇报，并及时把自己遇到的问题抛出来。

八、迭代结束，确认本次迭代完成的用户故事，对于完成一部分的用户故事计算到下一次迭代中。并对本次迭代的过程资产进行总结，形成FAQ方式的文档进行规整。

    同时根据新的需求情况，资源情况，已完成功能的回馈，以及开发中遭遇的不确定性问题，对发布规划和迭代规划作出调整。

    当前团队的实践推行办法：

    第一阶段，使用学习网站，或者博客等方式对经验进行记录。

    第二阶段，使用完善的skills对经验进行记录，可以方便的组织成培训文档，并方便的进行搜索，查找。

九、迭代测试，为了保证用户功能完整的提交，每个用户故事开发完成之后都要对该用户故事进行测试，然后在针对开发中出现的问题进行修复，以便完整的完成一个用户故事。

    第一阶段：测试迭代周期和开发迭代周期分开。

    每次迭代开始阶段由PM告知开发组需要开发的和修复的的用户故事，同时告知测试组本次迭代需要测试的故事，需要准备的故事，需要复测的故事。

    并在分配任务时，把修复故事的工作规划到本次迭代中来。

    每次开发完成的用户故事点算作本次迭代的速度。

    每次迭代开始阶段由PM告知开发组需要开发的故事，同时这些故事也是测试组需要准备测试的故事。要求这些故事分解的工作任务中要包括测试工作和修复工作。

    每次测试完成的用户故事点算作本次迭代的速度

    1 确定最终完成的用户故事，以及花费的迭代周期。

    2 通过计算得到一个团队的人平均速度，这个速度做为下次发布规划的参考。

    3 分析哪些用户故事的估计出现了失误，以及出现失误的原因是什么。

    4 最初的发布版本在市场上有了初步反馈信息之后，可以延长1个迭代周期用来做为发布版本的反馈收尾。