敏捷迭代流程
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 条评论
回复 删除
下一页