plan-do-check-act

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Plan-Do-Check-Act (PDCA)

Plan-Do-Check-Act (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.
四阶段迭代循环:Plan(识别与分析)、Do(实施变更)、Check(衡量结果)、Act(标准化或调整)。可实现系统化的实验与改进。

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:PLAN

  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:DO

  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:CHECK

  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:ACT

  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:在复制src文件前先复制package*.json
  - 为node_modules添加.dockerignore配置
  - 为Docker分层配置CI缓存
  - 在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分钟)
    - 编译错误减少至0次(原3次)
  分析: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阶段“Act”决定启动下一个循环或结束
  • 若3轮循环后仍无进展,重新进行根本原因分析
  • PDCA适用于技术与流程改进
  • 使用
    /analyse-problem
    (A3方法)进行全面文档记录