敏捷迭代流程
2022-04-08 14:31:09 1 举报
登录查看完整内容
迭代流程把控
作者其他创作
大纲/内容
发布预告
需求开发
演示会
需求宣讲、拆解
发布
参加演示会
整理迭代进展，晨会纪要群里通知
针对发生的问题展开讨论
回顾上个回归会的问题
针对第三方对接需求及较复杂需求内容（开发时间超过3天）需要进行测试用例评审
发布清单再确认
高保真走查
参加回顾会
验证演示问题
拉取分支
docdd讲解
高保真出图工具：蓝狐
通过
测试报告宣读
登记演示问题
是否设计会
为了保证需求宣讲会能理解需求，需要提前查看需求文档
产品设计文档（包含高保真及工作量）
测试用例编写
评估上线风险
回顾会
不清晰和工作量超出的需求不纳入迭代宣讲
跟进迭代进度
分支MR合并代码，打tag，填入发布清单
发布通知到组内
演示预告
填写提测时间/功能演示人员
设计复杂需求
产品经理
需求宣讲
晨会进度跟进
功能演示
进入研发
功能发布
SM和PO、测试确认具体解决方案
需求预估会
主持选择点赞榜
研发经理
需求设计
发布企业微信号通知
不通过
提前阅读需求文档
是
测试用例评审
迭代跟进清单
测试人员
否
任务jira拆解
是否存在演示问题
修复演示问题
测试功能
回顾会总结准备
UI设计师
研发
提交对应MR到对应仓库，并开启WIP模式
是否通过
不通过，需要1天内重新出方案，不可设计时间无限延长
敏捷迭代流程
整理发布清单等待发布
DOCDD拆解拆解人员：前后端拆解标准：前端需要包含页面交互和对高保真的疑问，后端需要包含表结构设计和接口改动，前后端需要提前沟通部分交互细节拆解效果:拆解完能够根据docdd直接开发
单个单子时间不可超过4h，特殊情况可特殊分析，提测时间和单子拆解需要在docdd当天拆解完成
设计产出RP+高保真
反馈进度，及时暴露风险
提交测试（分支sql等需要准备），并且同步测试环境SQL
迭代延期、需求置换、测试支援、开发支援、
回顾会准备
问卷填写
设计评审
通知回顾会时间
需求拆解分配
不通过：工作量超出，需求不合理等
根据具体需求提测前1天到2天了解提测风险
研发人员
晨会纪要通知SM和PO具体风险点
工作量评估
针对迭代问题回顾
需求评审
需求预告
原始需求采集
注意点:宣讲只沟通讨论具体业务和交互场景。技术能否实现和实现方案在docdd评审时体现，需求宣讲重点业务逻辑和交互
测试报告总结准备
0 条评论
回复 删除
下一页
