3.3    项目执行和监控过程
　　迭代N的执行
　　A、迭代N的需求细化
　　考虑每个迭代需要完成的用户故事；
　　用户故事需包含几个部分，工作量评估、功能性需求、非功能性需求。具体的可参考《用户故事模板及样例及拆分说明》
　　用户故事编写完成后需要在团队内部进行需求评审，一方面是为了向团队成员解读该需求，另一方面团队成员也可在评审时给出指导性意见。
　　B、测试用例评审
　　测试人员根据用户故事要求编写对应的测试用例，并组织项目团队进行测试用例评审。根据评审意见修改测试用例
　　C、开发
　　将用户故事的需求开发的过程。
　　D、开发自测
　　在开发过程中，每完成一个功能点，都需要及时的进行开发自测并通知产品策划人员进行验收体验。
　　E、验收
　　开发完成后，产品策划需要对开发完成的成果进行验收，验证其是否符合用户故事的要求，验证通过后方可流到测试环节，否则需与开发详细讨论其不符合性，其验收的checklist可以参考《产品验收checklist及模板》
　　F、测试和回归
　　提交测试时，必须要有正确的版本。测试人员根据测试用例进行测试，在IT平台中提交测试bug，并根据测试的角度给出产品是否发布的意见，输出《测试报告》
　　G、bug修改
　　在IT平台中获取分配给自己的bug进行修改。
　　H、showCase
　　阶段性必须有可体验版本进行showCase.需要
　　确定showCase时间：某个迭代开发、自测完成，准备提交测试前
　　会议前1-2天发出体验版给到参与人员
　　会议期间，由项目经理组织大家体验、反馈问题、记录问题。
　　项目经理根据问题情况，与开发或产品确定问题的解决时间并发出会议纪要。
　　I、灰度发布
　　迭代一定版本后，由项目经理与团队共同决定是否需要进行灰度发布。
　　监控方式
　　每日站立会
　　主持人轮流担任，负责控制节奏，记录问题，以备会后跟踪。
　　每人讲自己昨天做了什么，有什么问题，的计划是什么；
　　其他人了解别人的工作情况，并发现指出可能存在的问题。
　　对于发现的问题，鼓励认领，其余由项目经理指定责任人。
　　时间通常控制在15分钟内。
　　会议期间，更新任务墙，任务墙样式如下：

　　周报
　　反馈项目计划的执行情况，强调本周工作要达成的目标
　　暴露出项目的问题，特别是需要领导或其他团队需要协助的问题。
　　周报可在IT平台中输出。
　　月报
　　反馈项目当月的执行情况，包括进度、人力及质量。
　　反映项目存在的问题和风险。
　　迭代回顾
　　每人讲述本次迭代做的好的地方和不好的地方
　　回顾上个迭代不好的地方，看看改进情况。
　　让每个人发言。
　　每次迭代回顾会议完成后，可更新燃尽图
　　3.4    结项阶段
　　项目经理指导产品策划收集总结项目的产品运营数据，同时指导团队成员从自身角色进行总结，包括测试、开发、UI等。
　　项目经理与项目团队成员给出项目总结报告，内容可参考《项目经验教训总结-项目团队》，《项目经验教训总结-项目经理》
　　召开结项会议，各成员进行结项汇报。
　　PM小组将过程文档和经验教训总结进行归档。