plan-do-check-act
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChinesePlan-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:计划
- 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:执行
- 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:检查
- 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:处理
- 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:在复制源码文件前先复制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 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阶段“处理”决定了下一个循环或结束
- 若3个循环后仍无进展,重新审视根本原因分析
- PDCA适用于技术与流程改进
- 使用 (A3)进行全面文档记录
/analyse-problem