目录
目的
为规范产品迭代流程，提升团队成员产品迭代参与度，更好的衡量团队成员贡献度，量化产出，明确各成员角色的责任及义务，特制定此流程。
发版周期
两周一个迭代
概念描述
使用Jira管理自定义字段的描述如下：
Epic Link：史诗故事链接，产品线将比较大的任务项定义为史诗故事，一个史诗故事可能跨越多个迭代冲刺
PRD链接：如果需求，则填写需求对应的产品文档的wiki链接
version：迭代版本号，常规的版本迭代时间为两周一个迭代
Sprint：冲刺，一个冲刺与一个版本对应，时间相同
视觉设计URL：UI同学填写，如果需要，则填写此需求的视觉设计URL
测试人：需求指定的测试人员
测试用例：测试同学填写，如果需要，则填写此需求的测试用例wiki链接
标签：暂定可用标签为紧急需求、插入需求、被阻碍、无PRD、无接口文档，记录任务字段不不能体现的一些特定项
客户：主要指付费客户或者非黑卡客户但值得记录的客户名单
黑卡客户：非黑卡客户，无需填写此字段，支持多选（多个客户的同类需求）
链接的问题：关联的一线问题
开发文档URL：业务设计的wiki地址， 包含类图、时序图、架构拓扑、uml、部署图等
接口文档URL：后端开发的供前端及其它调用方使用的接口均需提供接口文档
预估工时：团队成员完成此任务预计需要耗用的工时，目前有近三（0.5，1，2，3，4，5）6个数值可选选项，其它两项（无，待研发评估）排除默认创建外，不建议勾选，预估工时同步填写到Story Points
Story Points：完成故事预计耗用点数，当前默认同步预估工时数据
提交Git地址：任务Jira号设置为Git分支号，原则每一个任务号的分支都是独立的，此处提供Git merge request地址，
CodeReview人员：填写Git merge操作人员的信息
计划提测时间：团队成员对任务分解后，根据任务需要消耗的工时及优先级，预计当前任务的提测时间
实际提测时间：团队成员接收任务，完成开发工作后并自测完成的实际提测时间
整体流程
需求整理
产品经理接收一线需求，分析需求可行性，对于需要团队研发完成交付的需求在业务线创建研发任务，并制定优先级
优先级制定策略
最高优：安全漏洞、线上影响正常交易并且范围广易复现的问题、黑卡需求、明确交付日期的需求
高优：影响部分交易场景的技术债、付费需求、delay超过两次及以上或者时间超过两个月的需求
中优：影响部分数据统计的技术债、数据统计字段完善类需求
低优：长期规划的前期探索任务、部分需求使用场景的技术可行性调研
编写需求PRD：根据一线客户实际需求场景，现有产品功能是否涵盖，是否为新增功能需求等评估是否需要提供产品需求文档，需求文档通过wiki地址URL在需求字段上作展现
视觉设计图：对于需要UI介入参与作视觉设计的需求，需在迭代开始前一周与UI沟通需求背景，提供PRD文档和原型图，尽量在迭代开始前完成高保真图设计
需求评审
（全员参与，建议时长：不低于4小时）
团队评审，由产品经理讲解需求，所有定义为最高优的需求必需在版本中交付，迭代中不被干扰（紧急bugfix、hotfix、或其他需要研发耗时参与介入的工作等）的情况下，高优需求也必须交付，所有最高优和高优需求都需要评审完毕，由对应的研发自身分配子任务。根据每位同学的story points总和，按sprint迭代的总工时适当评审一部分中低优需求
任务整理
（全员参与，建议时长：不低于4小时）
需求评审会后，研发针对自身分配的子任务整理分析，完成以下事项：
- 是否存在被其它子任务关联情况，如果存在，給自身的子任务的标签属性上添加被阻碍，在链接上添加阻碍本任务的Jira链接的问题，贴上被阻碍的任务不强制要求迭代前完善计划提测时间字段
- 需求是存在不理解或者不明确的地方，部分迭代时间超过3天的产品需求可要求产品经理必须提供PRD链接，如未提供，增加备注说明，并在标签上标记无PRD
- 所有分配到自身的高优和最高优的任务必须在迭代开始之前完成计划提测时间的评估和填写，填写完成之后不可变更，需合理避开发版时间、网络调整等已知影响正常提测事项的日期
- 理性分析需求，对于无法准确评估工时（技术难度较大、新接手项目不熟悉代码结构等）的Jira，需要客观的将原因整理以后写在备注中，并与团队协商适当给予较为充分的STORY POINTS
- 汇总统计所有任务的STORY POINTS，在整个Sprint迭代可用时间中，是否存在超期情况，是否存在交付压力，及时整理信息填写备注，与团队沟通协调部分Jira任务的再分配
- 任务整理环节需要确定本次Sprint需要完成的所有任务，Sprint开始后加入的所有需求都在标签上标记为插入需求
每日晨会流程
- 检查所有最高优和高优任务：所有优先级标记为最高优和高优任务需要由对应的研发同学创建子任务，并填写计划提测时间
- 检查昨日需提测：所有昨日需提测的内容的状态是否已经变更为待提测，如未填写，是否存在被阻碍、无PRD、无接口文档等标签，或者在备注中列明原因
- 检查历史需提测：截止到今日为止所有需提测内容是否都已经交付，如未提测，备注中是否列明原因，并提供实际提测时间
- 检查提测任务：所有提测任务原则上都要提供Git MergeRequest，后端的开发任务识需求难易度提供开发文档URL，需要与前端交互的后端接口提供接口文档URL（历史文档均可），CODEREVIEW人员字段需要填写，默认填写合并代码的同学
- 收集问题：收集所有同学的问题，尽量简短沟通，对于需要讨论或者遇到阻碍的任务，建议晨会结束以后专项讨论
注释：计划提测时间 实际提测时间 两个自定义字段的值类型是日期时间，建议填写的时间默认为当日23:00，避免当天下班以后查看任务归类为第二天
研发自测提测
- 所有研发类任务的STORY POINTS包含开发、自测时间，研发必须自测通过之后才能变更状态为测试中，变更为测试中的子任务必须填写提交GIT地址
- 所有研发类的任务都需按照计划提测时间完成自测，变更Jira状态，如不能正常提测，填写标签描述原因，任务提测后填写实际提测时间
- 要求子任务提交的Git MergeRequest必须包含Junit单元测试，对于没有单元测试的任务都可以直接打回，可不做merge操作
- 发版周的周一所有任务必须提测，如不能提测的任务挪出本期Sprint，并填写延期原因优先级属于HIGHEST的任务需要通过hotfix发版上线
测试验收
- 待测试Task必须满足：提交GIT地址字段不能为空、CODEREVIEW人员字段不能为空、实际提测时间不能超过发版周周一
- 子任务测试发现的bug提交时必须关联上子任务，建议关联方式通过关联需求／bug类型字段添加
迭代完成
- 任务完成：所有的任务都变更为已完成或者关闭，Sprint可以关闭
- Sprint时间截止：Sprint有固定的时间周期，截止到Sprint截止日期需要关闭Sprint，未完成的任务移动到Backlog中，可以再次冲刺
迭代延期
- Sprint开始时所有加入的任务都视为必须完成的任务
- Sprint结束时所有被动迁移或者主动迁移的任务都视为延期，延期任务需要提交延期原因，并更新下次发版版本
回顾总结
- 回顾此次产品迭代的交付内容，通过Epic、优先级、服务客户、任务类别等讲解，现场演示重点功能
- 分析此次发版的概况，完成总任务数、关联一线需求数据、子任务总数、总的STORY POINTS、总解决问题数量、总BUG数、BUG率
- 回顾迭代的任务完成速度，交付时间趋势，插入需求及delay需求数量
- 产品研发的产出，产品提出的任务数及PRD产出数量，研发的子任务数量、Git提交数及占比、开发文档提交数及占比、接口文档提交数及占比，对于STORY POINTS数量较多、任务完成质量较高的同学要予以表扬完成插入需求、紧急加塞需求的同学都需要记小红本
- BUG率及BUG数最高的同学需要记一下小黑本，因自身原因产生Delay的同学记一下小黑本（未及时提测但如期发版的记一次，Delay及不能如其发版的记两次）
