敏捷迭代流程设计-两周版

输出

周五

代码评审结果

周三

迭代计划会议：拆分需求池需求

输入

第二周

代码、功能

产品、开发、测试

需求文档、STORY设计文档

STORY

测试用例初稿

STORY设计文档编写和互评+上个迭代大版本发布上线

STORY设计文档初稿

测试用例初稿（含准入案例）

周二

第一周

功能

代码评审会议

产品、开发测试、运维

测试用例终稿

备注1. SM 由tl 担任2. 80P 8h*7*5*2 = 560 mh 1P= 8h 约等于 1 Man Day，团队内部达成共识，有个考量45P做业务+25P做技改+10P做技术支持 deadline不绑定点数，点数按实际工作量来评估超过10个点的story要拆开，不限制点数值3. relese train 周三 esc/cdc 一起 4. 需求分配考虑侧重点给到对应的组，但不需要强绑定系统5. 发布准入条件：常规发布走大车，紧急需求走打的6. 需求准入条件：临时需求插入场景7. 发布窗口封版、需求准入封版，需求变更（变大）8. 线上问题分场景准入9. >10P 必须拆 <=5P单人做，>5P结对做 10. 点数单位放开，不局限3，5，8，13 之类的

工作内容

需求池需求和高保真原型

开发、测试（互评）

生产热修

开发、测试

UAT测试联调

retro迭代总结会议

STORY设计文档终稿

测试用例评审会议&技术方案评审

周四

测试

上个迭代上线收尾

完成迭代内容

测试验收报告

角色：SM（敏捷大师），每个迭代选派一位同事担任SM角色，进行迭代周期内的事项管理。建议最少占用半个人力。1、预定会议室，并主持会议。2、每天的进度会议，并督促更新devops上的任务状态。3、各个环境的checklist维护以及发版4、准备分享内容并在总结会议中进行分享。主要会议说明：1、第一周周一的迭代计划会：组内需求澄清，将需求拆分成STROY，评估出工作人天并分配到对应的前后端开发。2、第一周周三的STORY设计文档评审会议：组内共同对成员的STORY设计文档进行评审，测试需要重点关注文档中的验收标准。3、测试用例评审会议：测试同学安排时间，须在第一周完成。4、第二周周三的代码评审会议：评审迭代期间开发的代码，测试同学需要关注并验证。5、第二周周五的迭代总结会议：复盘本次迭代的优缺点，缺点改进，优点发扬，目的不是追责。SM进行组内分享。（有条件可以通过经费弄点零食）

UAT测试验收报告

无

迭代总结报告

部署结果报告（可工作群通知）

部署UAT环境

部署生产环境

周一

部署结果报告

部署测试环境

部署TEST测试环境

STORY设计文档评审会议

迭代过程记录

完成STORY开发内容

TEST测试联调+当前迭代小版本发布上线（每周四）

TEST测试验收报告

需求澄清和迭代计划

代码

planning&测试用例编写&技术方案设计

相关方

开发