2、过程改进基础：PDCA循环、CMMI与ASPICE的关系、过程域与能力等级
各位工程师朋友，咱们今天聊聊过程改进的底子。说实话，很多人一听到「过程改进」就觉得虚，觉得是搞质量的人没事找事。我当年也这么想，直到在一个项目里被坑惨了——代码写得飞起，结果集成测试一塌糊涂，返工花了三倍时间。从那以后，我才真正开始琢磨：到底怎么把「改进」这件事，做得靠谱一点？
2.1 PDCA循环：过程改进的「永动机」
PDCA循环，说白了就是四个字：计划、执行、检查、处理。你想想看，这其实是我们做任何事情的底层逻辑。只不过在ASPICE里，它被玩出了花。
核心要点：PDCA不是一次性动作，而是螺旋上升的闭环。每转一圈，你的过程能力就往上走一层。
2.1.1 四个阶段怎么落地？
- P（Plan）：定目标、定方法、定资源。我习惯在项目启动时，先拉一张「过程改进清单」，把痛点列出来，再排优先级。
- D（Do）：按计划执行。这里有个坑——很多人一执行就忘了回头看。我曾经在一个项目中，团队按新流程跑了两个月，结果发现根本没人检查效果。
- C（Check）：检查执行结果。用数据说话，别凭感觉。比如需求变更率、缺陷逃逸率，这些指标比「我觉得有改进」靠谱得多。
- A（Act）：采取行动。好的留下，差的调整。如果发现某个检查点根本没人用，别犹豫，直接砍掉或者改。
我的经验：PDCA最容易被忽略的是「A」阶段。很多人做完检查就完事了，改进措施迟迟不落地。我建议每个PDCA周期结束时，必须输出一份「改进措施跟踪表」，责任到人，截止日期明确。
2.2 CMMI与ASPICE的关系：不是替代，是互补
经常有人问我：「老师，我们公司过了CMMI三级，是不是ASPICE就不用搞了？」嗯，这个问题我回答过不下二十次。其实两者不是二选一的关系。
| 维度 | CMMI | ASPICE |
|---|---|---|
| 起源 | 美国国防部/卡内基梅隆 | 欧洲汽车制造商联盟 |
| 核心关注 | 组织级过程成熟度 | 项目级工程过程能力 |
| 适用范围 | 软件、硬件、服务等 | 汽车嵌入式系统 |
| 等级划分 | 1-5级（成熟度等级） | 0-5级（能力等级） |
| 评估方式 | SCAMPI评估 | 基于ISO 15504的评估 |
你看，CMMI更像是一个「体检报告」，告诉你组织整体处于什么水平。而ASPICE更像是一个「手术刀」，针对汽车电子项目的具体过程进行精细诊断。我见过不少公司，CMMI三级做得很好，但一到ASPICE评估就露馅——为什么？因为CMMI的工程实践要求，没有ASPICE那么细。
避坑指南：我曾经辅导过一家公司，他们拿着CMMI的文档直接套ASPICE，结果被评估师打了回来。原因很简单——ASPICE对需求分析、系统设计、单元验证这些工程过程的要求，比CMMI具体得多。千万别想着「一鱼两吃」，该补的课一节都不能少。
2.3 过程域与能力等级：ASPICE的「骨架」
ASPICE的过程域，说白了就是把你做项目时该干的事，分门别类列出来。一共三大类：主要生命周期过程、组织生命周期过程、支持生命周期过程。嗯，这里要注意，别被这些术语吓到，其实很好理解。
2.3.1 过程域长什么样？
拿最常见的「软件需求分析」（SWE.1）来说，它规定了你要做什么：
- 定义软件需求
- 结构化软件需求
- 分析软件需求的影响
- 确认软件需求
- 建立双向可追溯性
- 确保一致性
- 沟通已确认的软件需求
你看，每个过程域都有一组「基础实践」（Base Practices）。这些就是你必须做到的动作。我刚开始做ASPICE时，觉得这些条目太死板。后来发现，正是这些「死板」的要求，帮我避免了很多低级错误。
2.3.2 能力等级：从「做到」到「做好」
能力等级是ASPICE最精妙的设计之一。它不只看你「做没做」，还看你「做得多好」。一共6个等级（0-5级）：
| 等级 | 名称 | 核心特征 |
|---|---|---|
| 0级 | 不完整 | 过程未实施或未达到预期 |
| 1级 | 已执行 | 过程被执行，但可能靠个人英雄主义 |
| 2级 | 已管理 | 有规划、有监控、有资源保障 |
| 3级 | 已建立 | 有标准过程，且被裁剪使用 |
| 4级 | 已量化 | 用数据管理过程，有量化目标 |
| 5级 | 已优化 | 持续改进，创新驱动 |
这里有个关键点：能力等级是「过程域」级别的，不是「项目」级别的。也就是说，你的需求分析过程可能达到2级，但项目管理过程可能只有1级。这很正常，我见过很多公司都是「偏科」的。
实战建议：别一上来就追求所有过程域都达到3级。我建议先选2-3个核心过程域（比如软件需求分析、软件详细设计、单元验证），把它们做到2级甚至3级。有了经验，再逐步扩展到其他过程域。贪多嚼不烂，这个道理在过程改进里同样适用。
2.4 三者如何联动？
PDCA是「发动机」，CMMI是「导航仪」，ASPICE是「施工图」。你想想看，没有发动机，改进动不起来；没有导航仪，容易走偏；没有施工图，不知道具体该干什么。
我个人习惯的做法是：
- 用PDCA的框架来组织改进活动，每个季度一个循环
- 参考CMMI的成熟度模型，设定组织级改进目标
- 用ASPICE的过程域和能力等级，细化到每个项目的具体改进动作
举个例子：假设你发现项目经常延期，用PDCA来分析，原因可能是需求变更管理混乱。这时候，CMMI告诉你需要提升「需求管理」过程域的成熟度。而ASPICE则告诉你，具体要检查SWE.1（软件需求分析）和SUP.9（问题解决管理）这两个过程域，看看它们的能力等级是否达到了2级。
一个小技巧：在做过程改进时，我习惯先画一张「过程能力热力图」。把每个过程域当前的能力等级标出来，用颜色区分（红色=0-1级，黄色=2级，绿色=3级以上）。这样一眼就能看出哪些是短板，优先改进哪里。这个图我每次做评估前都会更新，效果很好。
好了，这一章的内容就到这里。记住，过程改进不是一蹴而就的事，它更像是在打磨一把刀——每次磨一点，慢慢就锋利了。下一章咱们聊聊具体的改进方法，包括怎么定目标、怎么选过程域、怎么避免常见的坑。到时候我会分享一些我在实际项目中踩过的雷，希望能帮你少走弯路。