☆ 需求整理阶段
◇ 干系人：产品经理、技术负责人、项目经理
◇ 时间：这一环节的时间往往不计入迭代周期。这一阶段的需求和设计经常变动，而功能设计确定以后，进入开发阶段的变动比较少。
◇ 工作任务：产品人员对迭代的需求进行梳理，对需求完成设计；产品在做完设计后，小范围召集技术负责人等干系人进行评审；在交互稿件、设计稿件都完成后召开迭代会议。
◇ 产品工作重心：在需求池中进行筛选，挑选出优先级高的任务，制作迭代的功能列表。
◇ 注意事项：由于该环节主要是对总体功能列表进行讨论，只需要叫上产品小队、技术负责人就好，不要叫太多人，影响会议时间和效果。设计的原型不用做的太细，需求不稳定，有些可能会砍掉，设计以大的框架和流程为主，细节上的交互、规则可以在之后再根据需要进行完善。
☆ 迭代会议阶段
◇ 干系人：项目组所有成员
◇ 时间：该环节标志迭代周期正式开始
◇ 工作任务：产品经理对本次迭代的主要任务进行讲解，包括需求来源、产品设计，技术人员对此次迭代的时间进行排期。
◇ 产品工作重心：这个会议实际上就是个需求评审会，撕逼挨怼在所难免，所以产品要多做准备工作，特别是业务流程、规则、交互等具体实现的东西，不要被技术问死。
◇ 注意事项：前期的需求整理会议要打好基础，不要埋下隐患；在设计的时候一定要把各种情况尽可能地考虑全，以应付技术的提问。
☆ 迭代计划阶段
◇ 时间：开发、测试阶段
◇ 参与人员：项目组所有人员
◇ 工作任务：技术负责人对功能列表进行拆分、排期，开发人员开始编码；测试人员根据需求书写测试用例，在开发完成后进行产品测试。
◇ 产品工作重心：与开发人员保持沟通，有疑问的地方越早沟通越好，需要产品决策的地方决策的要有理有据；产品提测后产品要跟进功能验证，看一下是否符合预期。
◇ 注意事项：原则上迭代会议结束后，不能在迭代里新增需求。如果出现了改动较大的变更，需要召集小分队成员进行讨论，决定是否在此次迭代中加入变更的需求；
如果是小的改动，更新相关的文档，并通知项目组成员。
☆ 发布演示阶段这个阶段要注意的是发布前一定要做好测试等准备工作，要定好发布计划，不要陷入发布-测试-发现bug-修改bug-测试-发现新的bug......这样的死循环里面。
