跳到内容
返回

作为研发Leader,如何做迭代管理

写在前面

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

以下是我的团队在2023年初,刚刚优化过的迭代流程。

迭代管理在解决什么问题

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

开发过程方法论

开发过程方法论

原则和框架

说明:在整体迭代阶段上,我们采用类似「瀑布」方式进行了大阶段的拆分;

在需求的理解、交付上,我们采用「敏捷」方式,以故事的粒度进行交付和验收。

遵循的原则

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

使用的框架

Scrum + Kanban

敏捷(Agile)的目标是为了:帮助我们尽早了解我们到底有多糟糕,尽早管理这种局面。

流程概览

流程概览

角色说明

团队角色说明

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

详细说明

需求阶段

启动会 Kick Off Meeting

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

参加人员: 全体

相关动作

需求影响分析会 Impact Analysis Meeting

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

参加人员: RD、FE、QA

相关动作

需求评审会 PRD Review Meeting

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

参加人员: 全体

相关动作

UI评审会 UI Review Meeting

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

参加人员: 全体

相关动作

设计及评估阶段

计划会 Plan Meeting

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

参加人员: 全体

相关动作

设计评审会 Design Review Meeting

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

参加人员: RD 或 FE、QA

相关动作

工作量评估会 Estimate Meeting

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

参加人员: RD、FE、QA

相关动作

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

相关动作

「研发周期」计划模版

测试用例评审会 Test Case Review Meeting

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

参加人员: RD、FE、QA

相关动作

开发阶段

每日站会 Stand Up Meeting

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

参加人员: 全体

相关动作

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

相关动作

中期检查 Mid-term Check

会议目标: 沟通问题,预知风险

相关动作

测试 & 验收阶段

系统测试 System Testing

相关动作

验收 Acceptance

相关动作

发布阶段

发布 Release

相关动作

迭代回顾阶段

迭代回顾会 Review Meeting

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

参加人员: 全体

相关动作

使用的相关工具或平台

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

分享这篇文章:

上一篇文章
计划扑克
下一篇文章
我的2022