写在前面

「迭代流程管理」在每个公司的情况都不一样，随着产品发展阶段、团队规模、资源情况等变化，会进行各种实践和优化。我的团队一般会以半年为单位，进行迭代管理流程的Review，进行相关的流程调整和优化。 以下是我的团队在2023年初，刚刚优化过的迭代流程。

迭代管理在解决什么问题

上图中，共分为3个阶段，其中「产品开发」这个阶段，是下文中描述的「迭代流程」部分。

开发过程方法论

原则和框架

说明：在整体迭代阶段上，我们采用类似「瀑布」方式进行了大阶段的拆分； 在需求的理解、交付上，我们采用「敏捷」方式，以故事的粒度进行交付和验收。

遵循的原则

以「人的主观能动性」为核心，高效、高质量交付更有价值的产品，让团队成员成为更好的自己

使用的框架

Scrum + Kanban 敏捷（Agile）的目标是为了：帮助我们尽早了解我们到底有多糟糕，尽早管理这种局面。

流程概览

角色说明

角色	职责
Scrum Master	敏捷教练，推动迭代的进行，目前QA兼任
PM	产品经理，进行PRD的输出和讲解
RD	服务端工程师，负责后端代码实现
FE	前端工程师，负责前端代码实现
QA	测试工程师，负责迭代质量
UI	UI设计师，负责交互和界面设计

详细说明

需求阶段

启动会 Kick Off Meeting

会议目标： 顾名思义，开球。主要是传达产品价值，以及为什么要做，和本次迭代的目标，不会深入产品细节和原型细节等。

参加人员： 全体

相关动作

• 「PM」→ 输出PRD中的产品价值
• 「Master」→ 在 项目管理平台 创建迭代版本
• 「Master」→ 在 沟通工具 创建沟通群

需求影响分析会 Impact Analysis Meeting

会议目标： 熟悉系统现有功能，分析本次迭代变动的影响

参加人员： RD、FE、QA

相关动作

• 「RD 或 FE」→ 讲解系统现有功能，分析影响

需求评审会 PRD Review Meeting

会议目标： 讨论需求、实现逻辑和规则细节，达成整体团队对于本次需求理解的共识（会议次数原则上不应不超过2次）。

参加人员： 全体

相关动作

• 「PM」→ 输出 Final PRD

UI评审会 UI Review Meeting

会议目标： 讨论页面和交互的实现，达成团队对于本次页面和交互设计的理解共识（会议次数原则上不应不超过2次）。

参加人员： 全体

相关动作

• 「UI」→ 输出页面和交互设计

设计及评估阶段

计划会 Plan Meeting

会议目标： 进行本次迭代内容的确认，可能包含：业务部分、技术部分、遗留问题或Bug等。

参加人员： 全体

相关动作

• 「Master」→ 组织计划会，确定本次迭代的范围（Review 项目管理平台 内的遗留问题和Bug）

设计评审会 Design Review Meeting

会议目标： 讨论设计、规范、实现、数据迁移、历史技术债务、上线发布等多方面。

参加人员： RD 或 FE、QA

相关动作

• （按需）「RD」→ 输出设计文档，并评审（关于设计文档编写，请参考 如何编写「设计文档」TODO）
  • 第1次，RD内部进行设计评审
  • 第2次，RD + FE进行API设计评审
• （按需）「FE」 → 输出设计文档，并评审

工作量评估会 Estimate Meeting

会议目标： 根据计划会的确认的开发范围，进行工作量估算，并分配任务优先级和具体开发人员。

参加人员： RD、FE、QA

相关动作

• 「Master」→ 组织工作量评估会，确定本次迭代的工作量（评估方式：计划扑克 TODO）

「研发周期」计划发布 Plan Deploy

相关动作

• 「QA」→ 发布本次迭代的「研发周期」计划

• 「Master」→ 把各类迭代信息，更新到 项目管理平台，正式进入编码

测试用例评审会 Test Case Review Meeting

会议目标： 评审测试用例的完整性和合理性。

参加人员： RD、FE、QA

相关动作

• 「QA」→ 组织评审（测试用例维护在 测试用例管理平台）

开发阶段

每日站会 Stand Up Meeting

会议目标： 参考 如何进行「每日站会」TODO

参加人员： 全体

相关动作

• 「Master」→ 组织会议，主要沟通依赖、Block、风险等

故事验收 & 测试 Desk Check & Story Testing

相关动作

• 「RD & FE」→ 发起故事验收（如何进行故事验收 TODO），通过后，部署FAT环境进行测试，「QA」记录结果
• 「QA」→ 针对故事进行测试，当故事没有功能相关问题时，结束此故事测试

中期检查 Mid-term Check

会议目标： 沟通问题，预知风险

相关动作

• 「Master」→ 在迭代进行到中段，组织研发人员进行工作进度的Review，预知Delay风险

测试 & 验收阶段

系统测试 System Testing

相关动作

• 「RD & FE」→ 整理部署文档，提交部署工单
• 「QA」→ 在FAT
  • 验证部署文档
  • 冒烟测试
  • 用例测试（黑盒、白盒）
  • 回归测试（黑盒、白盒）

验收 Acceptance

相关动作

• 「QA」→ 在UAT
  • 验证部署文档
• 「PM」→ 进行产品验收
• 「UI」→ 进行UI验收
• 「QA」→ 在UAT
  • 回归测试（黑盒、白盒）

发布阶段

发布 Release

相关动作

• 「QA」→ 提交部署工单进行审核，通过后进行发布动作
• 「QA」→ 填写本次发布说明（对内）

迭代回顾阶段

迭代回顾会 Review Meeting

会议目标： 总结迭代流程和质量问题，进行复盘，优化迭代流程、代码质量、协作方式等。

参加人员： 全体

相关动作

• 「Master」→ 汇总迭代数据，进行报告和总结的编写
• 「Master」→ 组织迭代全部人员进行迭代数据的Review和问题的讨论

使用的相关工具或平台

	工具或平台
项目管理平台	https://www.teambition.com/
沟通工具	钉钉
测试用例管理平台	https://metersphere.io