一、关于双周迭代
据粗略了解，双周迭代模式是目前行业内普遍使用的开发迭代模式，产研部门互相配合，每两周交付一个版本，一般采用一周开发、一周测试的方式。公司项目也将采用此迭代模式，以一个版本的维度看，流程如下图所示，其中 FL 是 Feature List 的简称：
暂时无法在文档外展示此内容
以双周的维度看，双周将涉及四个版本的工作产出，工作流程说明如下：
| 周三 | 周四 | 周五 | 周一 | 周二 | |
| 第 N 周 | 测试交付 | 上个版本发布 | |||
| 开发 | 开发 | 开发 | 开发 | 开发 | |
| 测试用例评审 | |||||
| 下个版本 PRD&交互评审 | |||||
| 第 N+1 周 | 测试 | 测试 | 测试 | 测试 | 测试 |
| 下个版本视觉&技术评审 | 前后端部署 prod | ||||
| 下下个版本 FL 评审 |
考虑到部分需求的特殊性，这里根据需求实现难度 / 耗时的不同，做以下分类：
- 日常需求
- 一个周期（双周，下同）可以完成，作为日常迭代，双周交付
- 一个周期没有任何需求，适当调整上一个周期的迭代节奏，不按双周交付
- 专项项目
- 需要超过一个周期及以上才能完成的需求，作为专项项目，独立安排交付时间，或跟随最近交付的迭代版本上线
- 紧急需求
- 需快速响应的需求，如后端事故的修复、客户端 hotfix、应用市场下架、安全整改等，打破迭代的限制，一周（半个周期）内完成上线
综合以上，每双周交付版本中，包含了日常、专项、紧急三类需求，这三类需求的发版统一由 Scrum Master 协调处理。同时，Jira 将结合此流程，确保每个关键节点都体现在 Jira Task 中，尽量减少不必要的沟通。
二、人物角色 & 职责
Scrum Master 在双周迭代流程之后扮演了非常重要的角色，是迭代流程中的主 owner 也是主协调人，TA 是决定迭代流程能否顺畅执行的最重要角色之一。Scrum Master 的职责范围包括但不限于：
- 和 PM 共同确定 FL（Feature List 的简称）
- 版本信息同步和推进
- Block 问题处理和跟进
- 保证版本按时交付
- 跟进需求上线后的质量和数据情况
- 资源协调
- 组织必要的版本复盘和迭代方式改进会议
- 及时发现问题，并协助相关方解决
在项目迭代过程中，各端 leader / 各端项目负责人需协助和支持 Scrum Master 完成版本迭代，确保按时高质量交付。
三、固定会议和产出
- FL 评审
- 会议前准备：PM 确定此版本 FL 及 FL 的优先级，需求 PRD 完成初稿
- 会议目的：初步评审需求，研发对需求合理性、技术成本难度做出初步评估，初步确定要开发的 FL
- 会议产出：面向设计师版本的 FL，此后设计师根据 FL 去计划对应的工作
- 会议发起人：PM
- 参会人员：PM + 设计师 + Scrum Master + （各职能技术负责人）
- PRD & 交互评审
- 会议前准备：PRD 和交互图 Ready
- 会议目的：深度评审需求，提出合理建议，确定最终要开发的 FL 且需求理解达成一致
- 会议产出：确定最终要开发的 FL，确定需求参与的开发和 QA
- 会议发起人：PM
- 参会人员：PM + 设计师 + 开发 + QA + 数据分析师 + Scrum Master
- 视觉 + 技术评审
- 会议前准备：视觉稿 Ready，技术方案完成草案（若需求较简单，技术评审可忽略）
- 会议目的：深度评审视觉，提出合理建议，确定最终的视觉稿 ；确定并对齐需求的技术方案，确定需求依赖方（比如算法），确定工时评估
- 会议产出：确定最终的视觉稿；确定技术方案并落地技术文档；确定工时；确定可带上的 FL
- 会议发起人：PM / 设计师 + 开发
- 参会人员：PM + 设计师 + 开发 + QA + Scrum Master
- 测试用例评审
- 会议前准备：测试用例 Ready
- 会议目的：确定测试用例最终版本，确保用例无遗漏、无 bug
- 会议产出：确定测试用例最终版本
- 会议发起人：QA
- 参会人员：PM + 设计师 + 开发 + QA + Scrum Master
四、排期反馈
Scrum Master 根据排期情况给予所有同学反馈，以邮件或群公告形式发送排期报告，包括但不限于需求列表、关键节点、上线时间等内容，此后需求封版，不再接收额外需求。
五、开发测试
各端 leader/负责人分配好任务后进入开发阶段、测试阶段，期间包括完成需求开发、上报 bug、bug fix、bug 验证、回归测试、部署上线等操作。
六、交 Release 包
交 Release 包是此迭代进入尾声的信号，具体规则：
- 前后端及依赖方发布 production ，QA 完成核心流程的回归
- 回归结束且无严重问题，客户端打 Release 包，QA 再次回归核心流程，没问题后交由市场渠道同学
七、灰度及发布流程
为尽量减小 App 端 crash 对用户的影响，市场渠道同学上传 Release 包需遵循：
- 安卓端全渠道发布（后期再考虑自研走灰度流程）；苹果端按照苹果后台的灰度百分比进行灰度
- 全量发布 1 天后研发测监控 crash、卡顿等情况，PM、数分做数据回收，有严重问题及时提出并解决
八、迭代复盘会
迭代结束后，定期对本次迭代进行复盘，包括但不限于流程、质量、数据回收结果说明等
附：版本迭代表格
| Stage | Week | V1.0（上个版本） | V2.0（当前版本） | V3.0（下个版本） | V4.0（下下个版本） |
| 开发周 | 周三 | 核心功能回归 - QA 同步回归结果，确认无问题后将需求 task 置为 Ready for Release - 下午 4 点前交付 Release 包 - 渠道 / iOS 开发提审，安卓端全量发布 | 开发阶段 - 进入开发的需求，Dev 将其状态置为 In Dev - 每日下班前需求群里同步需求进度及潜在风险 | 同 11 行 F 列 | |
| 周四 | 正式发布 - 正式发布后，需求方将 task 置为 Release，完成生命周期 - 观察线上灰度情况，若无问题发布正式版本，需求方回收线上数据 - 若有线上问题，评估并推进 hotfix | 同上 | 同上 | ||
| 周五 | 同上 | 同上 | |||
| 周一 | 测试用例评审 - QA 发出会议邀请，相关 PM、开发、QA 必须参加，设计可选择性参加 - 评审后 QA 进行用例查漏补缺，补充完整后下班前给到 Dev 冒烟用例 | PRD & 交互评审 - PM 方发出会议邀请，相关 PM、设计、开发、QA 等必须参加 - 会前需求方将 task 置为 PRD Review - 会前提前 review 相关需求/设计文档 - 评审期间着重关注自己负责的需求，尽早提出风险或不合理的地方，积极提出自己的想法和建议 - 会后跟进 TODO list - 评审是否通过由除需求方外的中下游同学决定，若通过可进入下个环节的评审，若不通过，将不进入此迭代周期。若 PRD 极其不完整，核心功能逻辑不自洽，建议不予通过 | |||
| 周二 | 提测前 - Dev 开发结束后，使用冒烟用例、UT 进行自测 - 自测结束确认没问题，将 Jira task 状态更改为 Ready for Testing | 视觉 & 技术评审前准备 - PRD 评审会后，需再次深度理解需求，判断需求实现风险以及所需各端资源 - 涉及到与三方如算法、市场、运营、外部三方合作的需求，需确认好排期情况和 DDL - 组建需求群 - 群名规则：[版本号-需求号]-需求名，例：[V3.0-WEATHER-140]-优化首页分钟级显示 - 群成员：项目Scrum Master，需求涉及的 PM、设计、开发、QA、数分等关联同学 - 群公告：公告包括 Jira task 链接，预计提测时间，版本发布时间等关键信息 - 准备设计和技术评审相关文档 | |||
| 测试周 | 周三 | 冒烟测试 - 确认进入测试后，将需求的状态置为 In Testing - QA 推进 Bug 快速解决，Block 问题解决等，建议 P0 bug 当天下班前解决，P1 bug 第二天下午 3 点前解决 - QA 每天同步测试进度和潜在风险 | 同上 | ||
| 周四 | 详细测试 - 冒烟通过后，QA 通知设计走查 - 设计验收出 bug，自行创建 jira bug 给 Dev，并验收 | 同上 | |||
| 周五 | 详细测试 - 详细测试结束后，允许有小部分 P1 bug 和 P2 bug 情况下，通知需求方走查 - 需求方验收出不符合 PRD 的部分，再找相关开发、QA 沟通并解决 | 同上 | |||
| 周一 | 视觉 & 技术评审 - 设计方发出会议邀请，相关 PM、设计、开发、QA 等必须参加；视觉评审结束后做技术评审，PM、设计可选择参加 - 会后跟进 TODO list - 评审通过后，需求方将 task 状态置为 Ready for Dev；各端 Dev 和 QA 创建 Subtask 并填写 Workload - 技术评审，对风险不易控制的需求，做节点拆分，采用文档落实，进度跟踪，及时同步 - 评审是否通过由负责需求的中下游同学决定，若通过可进入下个环节，若不通过，将不进入此迭代周期 | FL 评审 - 需求方发出会议邀请，相关 PM、设计负责人、Scrum Master、QA 负责人必须参加，其他相关同学选择性参加 - 确定可做的需求列表 - 会后跟进 TODO list | |||
| 周二 | 集成测试 - 集成测试结束后，确认 P1 及以上 bug 且 P2 bug 控制在一定量内，上午12:00前，前后端部署上线 - QA 开始对线上新功能和核心功能回归 | 排期反馈 - 排期确认，Scrum Master 给予排期反馈，以邮件或群公告形式发送排期报告 - 排期报告发送后，需求封板，不再接受额外需求 | PRD & 交互评审会前准备 - FL 评审后，确认可做的FL，完善 PRD 和交互稿，在 PRD 评审前文档需全部 ready 状态 - 确认依赖方，尤其是非常规参与的依赖方，如算法、市场等部门 |
扫一扫
250
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
