软件工程师常用复盘模型

1. 4F 复盘（最通用、最适合日常周 / 日复盘）

• 模型：Fact 事实 → Feeling 感受 → Finding 发现 → Future 未来

• 适合：个人周复盘、日常任务、小需求、编码节奏

• 工程师举例：

  • Fact：本周完成 3 个接口、1 次线上 bug、1 次评审被打回

  • Feeling：bug 焦虑、评审返工烦躁

  • Finding：接口缺少边界用例；评审前自测不足

  • Future：每条接口必写单测 + 边界用例；提审前自验清单

• 用法：每天 5 分钟 / 每周 20 分钟，按四栏写清。

2. GRAI 复盘（项目 / 迭代复盘标准）

• 模型：Goal 目标 → Result 结果 → Analysis 原因 → Insight 改进

• 适合：迭代复盘、项目结项、里程碑

• 工程师举例：

  • Goal：本周完成支付模块联调

  • Result：延期 1 天，接口联调不通

  • Analysis：文档不一致、依赖方变更未同步、自测不充分

  • Insight：接口先对齐契约；依赖变更必通知；联调前本地 mock

• 用法：迭代结束必做，聚焦 “目标差在哪、为什么、改什么”。

3. 5Why 复盘（根因定位，故障 / BUG 神器）

• 模型：连续问5 个为什么，挖到可落地的根因

• 适合：线上故障、严重 bug、反复问题

• 工程师举例（接口超时）：

  1. 为什么超时？查询慢

  2. 为什么慢？没索引

  3. 为什么没索引？评审漏了

  4. 为什么漏了？无 SQL 审查清单

  5. 为什么无清单？流程缺失

• 改进：加 SQL 审核、慢查询拦截、建性能清单

• 用法：故障复盘必用，停在 “人为疏忽” 不算根因。

4. PDCA 循环（持续改进、流程化）

• 模型：Plan 计划 → Do 执行 → Check 检查 → Act 处理

• 适合：工作流优化、编码规范、交付质量提升

• 工程师举例：

  • Plan：定代码提交规范

  • Do：执行两周

  • Check：冲突减少但仍有遗漏

  • Act：加入 CI 检查、模板化 MR

• 用法：把改进变成闭环，不做一次性复盘。

5. RPDCA 复盘（风险前置，工程师很实用）

• 在 PDCA 前加Risk 风险识别

• 适合：需求开发、跨团队项目、上线发布

• 举例：先识别依赖风险、第三方变更、数据兼容问题，再计划执行。

6. KPT 复盘（最快、团队最常用）

• 模型：Keep 继续 → Problem 问题 → Try 改进

• 适合：快速站会、小迭代、轻量复盘

• 工程师举例：

  • Keep：每日同步进度

  • Problem：需求变更频繁、沟通成本高

  • Try：需求冻结窗口、变更走正式流程

• 用法：10 分钟快速复盘，不拖沓。