迭代流程
开发人员：周一到周五
产品设计：周一到周五
测试人员：周六
收集需求：周一周二周三
周四需求梳理
周五用户意见
周六第二次需求梳理
需求阶段
第一次需求梳理会议
开发人员和测试人员通过此会议了解下一次迭代的需求点
对需求有任何问题需要在此会议及时反馈给产品（技术层面，实现难度，实现方式的建议等）
产品人员收集反馈并修改需求
开发人员需在会后自发讨论会涉及到的开发工作
第二次需求梳理会议
产品提供修改后的需求点以及细节
开发和测试需要通过此会议理解需求
需求不在此会议上做任何修改了（除非一些实现细节方面）
迭代计划会议
结合第二次需求梳理会议
产品人员根据优先级排序Backlog
根据评估的工作量，开发人员按照优先级承诺这个迭代能够实现的Backlog
承诺的Backlog必须这个迭代按时完成
其余Backlog放到下一个迭代
开发人员尽可能多的拆分Task
开发阶段
在此阶段出现的新需求一律放到下个迭代实现
需求不做任何更改（除非产品和开发在不影响时间的前提下都同意改动）
根据项目开发情况，测试人员可以及时测试已完成的功能点，并把问题报到禅道上.为确保开发可以顺利完成，测试人员在此期间不能干捞开发人员（除非特殊原因）
周五开发结束后，产品人员会拿到一个内测版本，主要用来总结和收集反馈
如果反馈是BUG，在测试阶段修复，如果是新需求，就放到下一个迭代
特别强调:
在开发过程中遇到需求不理解或是不清楚等情况，一定要先和产品确认需求，确保实现是正确的，如果最后
发现由于沟通不及时导致实现有误，开发迭代周期不会因此延长，开发人员只能加班完成
测试阶段
测试后的版本应该是一个没有大BUG功能完整实现的BETA版