输出
周五
代码评审结果
周三
迭代计划会议：拆分需求池需求
输入
第二周
代码、功能
产品、开发、测试
需求文档、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&测试用例编写&技术方案设计
相关方
开发
