plan-do-check-act
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChinesePlan-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
- Define the problem or improvement goal
- Analyze current state (baseline metrics)
- Identify root causes (use or
/why)/cause-and-effect - Develop hypothesis: "If we change X, Y will improve"
- Design experiment: what to change, how to measure success
- Set success criteria (measurable targets)
- 定义问题或改进目标
- 分析当前状态(基准指标)
- 识别根本原因(使用或
/why工具)/cause-and-effect - 提出假设:“如果我们调整X,Y将得到改善”
- 设计实验:确定调整内容与成功衡量方式
- 设定成功标准(可衡量的目标)
Phase 2: DO
阶段2:DO
- Implement the planned change (small scale first)
- Document what was actually done
- Record any deviations from plan
- Collect data throughout implementation
- Note unexpected observations
- 实施计划的调整(先从小范围开始)
- 记录实际执行的内容
- 记录任何与计划不符的偏差
- 在实施全程收集数据
- 记录意外发现的情况
Phase 3: CHECK
阶段3:CHECK
- Measure results against success criteria
- Compare to baseline (before vs. after)
- Analyze data: did hypothesis hold?
- Identify what worked and what didn't
- Document learnings and insights
- 对照成功标准衡量结果
- 与基准状态对比(实施前后对比)
- 分析数据:假设是否成立?
- 确定有效与无效的措施
- 记录经验与见解
Phase 4: ACT
阶段4:ACT
- If successful: Standardize the change
- Update documentation
- Train team
- Create checklist/automation
- Monitor for regression
- If unsuccessful: Learn and adjust
- Understand why it failed
- Refine hypothesis
- Start new PDCA cycle with adjusted plan
- If partially successful:
- Standardize what worked
- Plan next cycle for remaining issues
- 若成功:将调整措施标准化
- 更新文档
- 培训团队
- 创建检查清单/实现自动化
- 监控是否出现倒退
- 若失败:总结经验并调整
- 分析失败原因
- 优化假设
- 基于调整后的计划启动新的PDCA循环
- 若部分成功:
- 将有效的措施标准化
- 针对剩余问题规划下一个循环
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 weeksCYCLE 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 completeCYCLE 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 hypothesisPLAN:
问题: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 (A3) for comprehensive documentation
/analyse-problem
- 从微小、可衡量的调整开始(不要大规模整改)
- PDCA是迭代式的——多轮循环属正常情况
- 失败的实验是学习的机会
- 记录所有内容:便于发现多轮循环中的规律
- 成功标准必须可衡量(而非主观判断)
- 第4阶段“Act”决定启动下一个循环或结束
- 若3轮循环后仍无进展,重新进行根本原因分析
- PDCA适用于技术与流程改进
- 使用(A3方法)进行全面文档记录
/analyse-problem