产品原型
立项说明书
分支合并冻结
项目复盘总结
项目周报
集成测试
设计图
设计
线上回归
PRD文档
开发计划
1、迭代里程碑节点2、提测计划和内容
组织评审会议
用例设计
技术守护人
测试计划
运维
冒烟自测记录
技术设计
迭代总结准备
开发
项目经理
预发布环境验证
前端应用上架
开发改进
1、更新迭代计划表2、确定前后端联调时间和内容
技术评审
编码开发
测试
需求终审
UI评审
验收清单
项目验收
1、app上架应用市场2、前端应用发布
了解需求
用例评审
识别风险
数据分析建议收集策略调整
迭代计划表
阶段任务开发完成
每日站会
UI/UX
1、测试时间2、任务分解
需求
1、冒烟用例2、迭代功能用例
上线观察
集成测试报告
UI改进
需求初审
更新每日任务
技术可行性分析
1、技术设计时间2、任务分解
部署方案
UI设计
1、需求终审目标：对迭代需求内容进行最终评审，让迭代内所有成员了解项目背景、功能需求，对迭代内容、功能操作流程及功能的交互方式达成共识，识别迭代内的重要影响点。形式：会议。参与人员：迭代负责人（项目经理），产品经理，UI/UX设计师，开发组长及成员，测试组长及成员。前置条件：产品经理需提前至少1天将需求发至相关参会人员；——事项负责人：产品经理所有参会人员提前查阅需求，在需求评审会前把问题发给产品，如果涉及到需求变更，则产品和相关技术人员在会议前做好沟通及变更，会议上进行同步——事项负责人：除产品经理之外的参会人员产品经理提前汇总收集参会人员的问题——事项负责人：产品经理（若参会人员没有提前熟悉需求，那需求会议可以推迟启动，该情况由scrum muster负责确认）会议过程：产品经理讲解需求，功能的交互；讨论、解答参会人员提出的问题；参与开发人员已经提前进行了分工，如果迭代内容较多，可以只关注分工部分；后置事件：产品经理记录会议纪要，并以邮件的方式发至参会人；若有需求变更，由产品经理进行需求文档更改，更改完成后发至项目组成员，由master确定组内成员全部查阅（根据需求变更情况判断是否需要进行二次评审）；2、立项目标：阐述迭代项目背景和意义，明确迭代功能范围和参与人员，使迭代参与人员统一目标。形式：会议。参与人员：全部迭代参与人员。前置条件：迭代负责人准备好立项说明文档，内容包括项目背景和意义，迭代需求清单，迭代参与人员，技术守护人，测试负责人；会议过程：项目经理讲解项目目标，需求清单；明确开发分工；明确技术守护人（后端，前端，客户端）职责；确定迭代计划会议时间点；（一般控制在立项后三天内）后置事件：迭代负责人制定好项目管理表格，同步给技术守护人，大家可以将已经明确的任务进行填写；禅道上创建迭代，设置团队，关联需求；预定迭代计划会会议室及时间，同步迭代参与人员
产品
迭代计划会
上线研发准备
迭代上线准备
单元测试
总结
部署计划
缺陷修复
立项
1、数据库脚本2、发布服务清单3、app打包
review
发布
使用跟进
技术难点评估，人员分工
技术设计文档
1、checklist2、运维通知3、发布邮件
测试改进
计划
运维上线准备
跟进迭代进度
整理评审会议纪要
跟进评估迭代风险点
新老版本应用回归测试
研发
开发联调
冒烟自测
UI验收
测试用例
发布构建
运维支持
1、向项目成员收集迭代问题2、整理迭代输出成果物
产品验收
项目管理流程
1、阐述迭代立项背景2、明确迭代范围3、明确迭代参与人员
设计计划
1、脚本执行2、服务发布支持
