技术设计与排期会议结束
准入通过
每日测试进展：（邮件形式发出）1.总体进度2.老bug修复情况3.发现新bug
正常的前进流程
bug反馈
产品初步方案评审（产品故事）
发出准入测试，至少需要在提测前一天发出。
PM验证
NO
问题反馈
对当前步骤的解释说明
需要依赖其他的交付才能执行下一步
bug修复
需要确定全部视觉交付时间UE如果有后续更新，需要标注清楚更新范围
准入测试必须在提测前给出
合并代码，封板
PM发起预评审 1.创建TB任务“项目名称+版本+预评审\
QA梳理思路
交互需求说明
标准产出物
核心功能回归测试
YES
目标与策略说明
PM产出:1.会议纪要2.完整的需求文档并上传到TB任务3.完整的线框图
发布
测试计划产出测试计划，主要是测试排期和每天测试的内容
上线前回归测试
交互关键路径与目标交互方案
1.需求文档达标 2.需求文档标出本次迭代内容
RD1.组内技术方案讨论审核2.预估开发时间3.明确各责任人
上线（op操作）
测试用例编写
PM（产品经理）
需要参与当前环节
产品目标验证
不大于三次
准入测试
研发复议会议
里程碑阶段
UE: 发起视觉评审 1.创建TB任务“项目名称+版本+视觉评审\
验证通过
回滚
技术文档产出
根据视觉准备测试用例
性能测试
测试用例产出
bug日清每一次修复完bug，需要阐述影响面
测试结束
相关说明
每次更新都需要有更新日志
测试计划
QA（测试）
编码
上传TB文档区域
根据视觉稿准备技术方案
RD发起技术设计与排期会议：（邀请QA PM，需要提前发出）
需求评估
测试通过
RD（开发）
发布到预览环境
技术方案文档和详情设计文档
开始测试
需要其他放审核通过才能执行下一步
技术文档（详设和接口文档）
视觉评审结束
交互评审
开始交互与视觉
UE（设计）
需求文档符合要求（完整性，规范性，合理性）
研发流程规范
RD初步方案评估
视觉评审
RD技术方案开始
标注详细的标注有相关动效的详细演示和交互稿的差异不超过10%
QA:技术方案和详情设计文档是否符合标准RD:描述技术方案与设计思路PM:确认QA和RD对需求的理解没有出现偏差
开始开发阶段
这个节点不代表要在联调之前给出，但是必须在准入测试前给出
测试用例评审结束
需求阶段结束
需求预评审合理性可行性
文档符合标准规范
如果PM、RD、QA无异议不需要开会议评审
提测
UE: 发起交互评审 1.创建TB任务“项目名称+版本+交互评审\
准入测试产出
RD技术方案准备
准备回归测试
版本：1.0
待审核产出
产出check
回归测试
QA梳理测试思路
PM验证通过
测试用例评审:RD和PM对相关用例进行了解和补充
业务需求说明
产出：1.详设文档到位时间2.接口文档到位时间3.RD联调时间4.各个story的自测试件5.各个story的体侧时间6.迭代封板时间7.上线时间8.RD需要明确每个人所负责的需求
需求调研与整理
相关负责人在TB发起任务（技术方案与时间计划）
QA，相关开发发现产出文档不达标或者有变更未及时通知，可以拒绝测试，或者项技术经理提出反馈。文档编写的RD应及时修正和通知所有相关人员
产出高保真视觉稿(产出包括切图和详细的标注)
技术设计与排期会议
测试用例评审
大于三次需要向上反馈
codeReiview
项目经理：TB创建任务创建开发任务
完整视觉稿
异常质量反馈：（TB及时反馈，技术经理快速协调跟进）1.提测质量差2.bug修复不及时3.其他导致测试无法正常进行不明确bug责任人可以指派给技术经理，技术经理及时协调
测试用例
联调
