plan-do-check-act

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Plan-Do-Check-Act (PDCA)

计划-执行-检查-处理(PDCA)

Apply PDCA cycle for continuous improvement through iterative problem-solving and process optimization.
通过迭代式问题解决与流程优化,应用PDCA循环实现持续改进。

Description

说明

Four-phase iterative cycle: Plan (identify and analyze), Do (implement changes), Check (measure results), Act (standardize or adjust). Enables systematic experimentation and improvement.
四阶段迭代循环:计划(识别与分析)、执行(实施变更)、检查(衡量结果)、处理(标准化或调整)。可实现系统性实验与改进。

Usage

使用方式

/plan-do-check-act [improvement_goal]
/plan-do-check-act [improvement_goal]

Variables

变量

  • GOAL: Improvement target or problem to address (default: prompt for input)
  • CYCLE_NUMBER: Which PDCA iteration (default: 1)
  • GOAL:要实现的改进目标或需解决的问题(默认:提示输入)
  • CYCLE_NUMBER:PDCA循环的迭代次数(默认:1)

Steps

步骤

Phase 1: PLAN

阶段1:计划

  1. Define the problem or improvement goal
  2. Analyze current state (baseline metrics)
  3. Identify root causes (use
    /why
    or
    /cause-and-effect
    )
  4. Develop hypothesis: "If we change X, Y will improve"
  5. Design experiment: what to change, how to measure success
  6. Set success criteria (measurable targets)
  1. 定义问题或改进目标
  2. 分析当前状态(基线指标)
  3. 识别根本原因(使用
    /why
    /cause-and-effect
  4. 提出假设:“如果我们改变X,Y将得到改善”
  5. 设计实验:要改变什么、如何衡量成功
  6. 设置成功标准(可衡量的目标)

Phase 2: DO

阶段2:执行

  1. Implement the planned change (small scale first)
  2. Document what was actually done
  3. Record any deviations from plan
  4. Collect data throughout implementation
  5. Note unexpected observations
  1. 实施计划中的变更(先从小规模开始)
  2. 记录实际执行的内容
  3. 记录与计划的任何偏差
  4. 在实施过程中收集数据
  5. 记录意外观察结果

Phase 3: CHECK

阶段3:检查

  1. Measure results against success criteria
  2. Compare to baseline (before vs. after)
  3. Analyze data: did hypothesis hold?
  4. Identify what worked and what didn't
  5. Document learnings and insights
  1. 将结果与成功标准对比
  2. 与基线对比(变更前后)
  3. 分析数据:假设是否成立?
  4. 识别有效和无效的措施
  5. 记录经验与见解

Phase 4: ACT

阶段4:处理

  1. If successful: Standardize the change
    • Update documentation
    • Train team
    • Create checklist/automation
    • Monitor for regression
  2. If unsuccessful: Learn and adjust
    • Understand why it failed
    • Refine hypothesis
    • Start new PDCA cycle with adjusted plan
  3. If partially successful:
    • Standardize what worked
    • Plan next cycle for remaining issues
  1. 若成功:将变更标准化
    • 更新文档
    • 培训团队
    • 创建检查清单/自动化流程
    • 监控是否出现倒退
  2. 若失败:总结经验并调整
    • 理解失败原因
    • 优化假设
    • 基于调整后的计划启动新的PDCA循环
  3. 若部分成功:
    • 将有效的措施标准化
    • 针对剩余问题规划下一个循环

Examples

示例

Example 1: Reducing Build Time

示例1:缩短构建时间

CYCLE 1
───────
PLAN:
  Problem: Docker build takes 45 minutes
  Current State: Full rebuild every time, no layer caching
  Root Cause: Package manager cache not preserved between builds
  Hypothesis: Caching dependencies will reduce build to <10 minutes
  Change: Add layer caching for package.json + node_modules
  Success Criteria: Build time <10 minutes on unchanged dependencies

DO:
  - Restructured Dockerfile: COPY package*.json before src files
  - Added .dockerignore for node_modules
  - Configured CI cache for Docker layers
  - Tested on 3 builds

CHECK:
  Results:
    - Unchanged dependencies: 8 minutes ✓ (was 45)
    - Changed dependencies: 12 minutes (was 45)
    - Fresh builds: 45 minutes (same, expected)
  Analysis: 82% reduction on cached builds, hypothesis confirmed

ACT:
  Standardize:
    ✓ Merged Dockerfile changes
    ✓ Updated CI pipeline config
    ✓ Documented in README
    ✓ Added build time monitoring
  
  New Problem: 12 minutes still slow when deps change
  → Start CYCLE 2


CYCLE 2
───────
PLAN:
  Problem: Build still 12 min when dependencies change
  Current State: npm install rebuilds all packages
  Root Cause: Some packages compile from source
  Hypothesis: Pre-built binaries will reduce to <5 minutes
  Change: Use npm ci instead of install, configure binary mirrors
  Success Criteria: Build <5 minutes on dependency changes

DO:
  - Changed to npm ci (uses package-lock.json)
  - Added .npmrc with binary mirror configs
  - Tested across 5 dependency updates

CHECK:
  Results:
    - Dependency changes: 4.5 minutes ✓ (was 12)
    - Compilation errors reduced to 0 (was 3)
  Analysis: npm ci faster + more reliable, hypothesis confirmed

ACT:
  Standardize:
    ✓ Use npm ci everywhere (local + CI)
    ✓ Committed .npmrc
    ✓ Updated developer onboarding docs
  
  Total improvement: 45min → 4.5min (90% reduction)
  ✓ PDCA complete, monitor for 2 weeks
CYCLE 1
───────
PLAN:
  问题: Docker构建耗时45分钟
  当前状态: 每次完全重建,无层缓存
  根本原因: 构建之间未保留包管理器缓存
  假设: 缓存依赖项可将构建时间缩短至<10分钟
  变更: 为package.json + node_modules添加层缓存
  成功标准: 依赖项未变更时,构建时间<10分钟

DO:
  - 重构Dockerfile:在复制源码文件前先复制package*.json
  - 为node_modules添加.dockerignore规则
  - 配置CI的Docker层缓存
  - 在3次构建中进行测试

CHECK:
  结果:
    - 依赖项未变更: 8分钟 ✓ (原45分钟)
    - 依赖项变更: 12分钟 (原45分钟)
    - 全新构建: 45分钟 (与之前相同,符合预期)
  分析: 缓存构建耗时减少82%,假设成立

ACT:
  标准化:
    ✓ 合并Dockerfile变更
    ✓ 更新CI流水线配置
    ✓ 在README中记录相关内容
    ✓ 添加构建时间监控
  
  新问题: 依赖项变更时12分钟仍偏慢
  → 启动CYCLE 2


CYCLE 2
───────
PLAN:
  问题: 依赖项变更时构建仍需12分钟
  当前状态: npm install会重新构建所有包
  根本原因: 部分包需从源码编译
  假设: 使用预编译二进制文件可将时间缩短至<5分钟
  变更: 使用npm ci替代install,配置二进制镜像
  成功标准: 依赖项变更时,构建时间<5分钟

DO:
  - 切换为npm ci(使用package-lock.json)
  - 添加包含二进制镜像配置的.npmrc
  - 在5次依赖更新中进行测试

CHECK:
  结果:
    - 依赖项变更: 4.5分钟 ✓ (原12分钟)
    - 编译错误从3次降至0次
  分析: npm ci更快且更可靠,假设成立

ACT:
  标准化:
    ✓ 在所有环境(本地+CI)使用npm ci
    ✓ 提交.npmrc文件
    ✓ 更新开发者入职文档
  
  总改进: 45分钟 → 4.5分钟(减少90%)
  ✓ PDCA循环完成,监控2周

Example 2: Reducing Production Bugs

示例2:减少生产环境Bug

CYCLE 1
───────
PLAN:
  Problem: 8 production bugs per month
  Current State: Manual testing only, no automated tests
  Root Cause: Regressions not caught before release
  Hypothesis: Adding integration tests will reduce bugs by 50%
  Change: Implement integration test suite for critical paths
  Success Criteria: <4 bugs per month after 1 month

DO:
  Week 1-2: Wrote integration tests for:
    - User authentication flow
    - Payment processing
    - Data export
  Week 3: Set up CI to run tests
  Week 4: Team training on test writing
  Coverage: 3 critical paths (was 0)

CHECK:
  Results after 1 month:
    - Production bugs: 6 (was 8)
    - Bugs caught in CI: 4
    - Test failures (false positives): 2
  Analysis: 25% reduction, not 50% target
  Insight: Bugs are in areas without tests yet

ACT:
  Partially successful:
    ✓ Keep existing tests (prevented 4 bugs)
    ✓ Fix flaky tests
  
  Adjust for CYCLE 2:
    - Expand test coverage to all user flows
    - Add tests for bug-prone areas
    → Start CYCLE 2


CYCLE 2
───────
PLAN:
  Problem: Still 6 bugs/month, need <4
  Current State: 3 critical paths tested, 12 paths total
  Root Cause: UI interaction bugs not covered by integration tests
  Hypothesis: E2E tests for all user flows will reach <4 bugs
  Change: Add E2E tests for remaining 9 flows
  Success Criteria: <4 bugs per month, 80% coverage

DO:
  Week 1-3: Added E2E tests for all user flows
  Week 4: Set up visual regression testing
  Coverage: 12/12 user flows (was 3/12)

CHECK:
  Results after 1 month:
    - Production bugs: 3 ✓ (was 6)
    - Bugs caught in CI: 8 (was 4)
    - Test maintenance time: 3 hours/week
  Analysis: Target achieved! 62% reduction from baseline

ACT:
  Standardize:
    ✓ Made tests required for all PRs
    ✓ Added test checklist to PR template
    ✓ Scheduled weekly test review
    ✓ Created runbook for test maintenance
  
  Monitor: Track bug rate and test effectiveness monthly
  ✓ PDCA complete
CYCLE 1
───────
PLAN:
  问题: 每月8个生产环境Bug
  当前状态: 仅手动测试,无自动化测试
  根本原因: 发布前未发现回归问题
  假设: 添加集成测试可将Bug数量减少50%
  变更: 为关键路径实现集成测试套件
  成功标准: 1个月后每月Bug数<4个

DO:
  第1-2周: 编写以下场景的集成测试:
    - 用户认证流程
    - 支付处理
    - 数据导出
  第3周: 设置CI运行测试
  第4周: 团队测试编写培训
  覆盖率: 3条关键路径(原0)

CHECK:
  1个月后结果:
    - 生产环境Bug: 6个(原8个)
    - CI中发现的Bug: 4个
    - 测试失败(误报): 2个
  分析: 减少25%,未达到50%的目标
  见解: Bug出现在未覆盖测试的区域

ACT:
  部分成功:
    ✓ 保留现有测试(避免了4个Bug)
    ✓ 修复不稳定的测试
  
  为CYCLE 2调整:
    - 将测试覆盖率扩展至所有用户流程
    - 为易出Bug的区域添加测试
    → 启动CYCLE 2


CYCLE 2
───────
PLAN:
  问题: 仍有6个Bug/月,需降至<4个
  当前状态: 已测试3条关键路径,共12条路径
  根本原因: UI交互Bug未被集成测试覆盖
  假设: 为所有用户流程添加E2E测试可使Bug数<4个
  变更: 为剩余9条流程添加E2E测试
  成功标准: 每月Bug数<4个,覆盖率80%

DO:
  第1-3周: 为所有用户流程添加E2E测试
  第4周: 设置视觉回归测试
  覆盖率: 12/12用户流程(原3/12)

CHECK:
  1个月后结果:
    - 生产环境Bug: 3个 ✓ (原6个)
    - CI中发现的Bug: 8个(原4个)
    - 测试维护时间: 3小时/周
  分析: 达成目标!较基线减少62%

ACT:
  标准化:
    ✓ 将测试设为所有PR的必填项
    ✓ 在PR模板中添加测试检查清单
    ✓ 安排每周测试评审
    ✓ 创建测试维护手册
  
  监控: 每月跟踪Bug率与测试有效性
  ✓ PDCA循环完成

Example 3: Improving Code Review Speed

示例3:提升代码审查速度

PLAN:
  Problem: PRs take 3 days average to merge
  Current State: Manual review, no automation
  Root Cause: Reviewers wait to see if CI passes before reviewing
  Hypothesis: Auto-review + faster CI will reduce to <1 day
  Change: Add automated checks + split long CI jobs
  Success Criteria: Average time to merge <1 day (8 hours)

DO:
  - Set up automated linter checks (fail fast)
  - Split test suite into parallel jobs
  - Added PR template with self-review checklist
  - CI time: 45min → 15min
  - Tracked PR merge time for 2 weeks

CHECK:
  Results:
    - Average time to merge: 1.5 days (was 3)
    - Time waiting for CI: 15min (was 45min)
    - Time waiting for review: 1.3 days (was 2+ days)
  Analysis: CI faster, but review still bottleneck

ACT:
  Partially successful:
    ✓ Keep fast CI improvements
  
  Insight: Real bottleneck is reviewer availability, not CI
  Adjust for new PDCA:
    - Focus on reviewer availability/notification
    - Consider rotating review assignments
  → Start new PDCA cycle with different hypothesis
PLAN:
  问题: PR平均需3天才能合并
  当前状态: 仅手动审查,无自动化
  根本原因: 评审者等待CI通过后才开始审查
  假设: 自动审查+更快的CI可将时间缩短至<1天
  变更: 添加自动化检查+拆分长CI任务
  成功标准: 平均合并时间<1天(8小时)

DO:
  - 设置自动化代码检查(快速失败)
  - 将测试套件拆分为并行任务
  - 添加包含自我审查清单的PR模板
  - CI时间: 45分钟 → 15分钟
  - 跟踪2周内的PR合并时间

CHECK:
  结果:
    - 平均合并时间: 1.5天(原3天)
    - 等待CI的时间: 15分钟(原45分钟)
    - 等待审查的时间: 1.3天(原2+天)
  分析: CI速度提升,但审查仍是瓶颈

ACT:
  部分成功:
    ✓ 保留CI提速的改进
  
  见解: 真正的瓶颈是评审者的可用性,而非CI
  为新PDCA循环调整:
    - 聚焦评审者的可用性/通知机制
    - 考虑轮换评审任务
  → 启动基于新假设的PDCA循环

Notes

注意事项

  • Start with small, measurable changes (not big overhauls)
  • PDCA is iterative—multiple cycles normal
  • Failed experiments are learning opportunities
  • Document everything: easier to see patterns across cycles
  • Success criteria must be measurable (not subjective)
  • Phase 4 "Act" determines next cycle or completion
  • If stuck after 3 cycles, revisit root cause analysis
  • PDCA works for technical and process improvements
  • Use
    /analyse-problem
    (A3) for comprehensive documentation
  • 从微小、可衡量的变更入手(而非大规模改造)
  • PDCA是迭代式的——多次循环属于正常情况
  • 失败的实验也是学习机会
  • 记录所有内容:便于跨周期发现规律
  • 成功标准必须可衡量(而非主观)
  • 第4阶段“处理”决定了下一个循环或结束
  • 若3个循环后仍无进展,重新审视根本原因分析
  • PDCA适用于技术与流程改进
  • 使用
    /analyse-problem
    (A3)进行全面文档记录