第4章 过程评估模型（PAM）：评估指标、评估过程与评分规则
说到ASPICE的评估模型，很多人第一反应就是「又要被审计了」。说实话，我当年第一次面对PAM时也是这个心态。但后来我发现，搞懂这套评估体系，反而能帮你把开发过程理得清清楚楚。
这一章，我们就来聊聊PAM的核心内容。说白了，就是回答三个问题：评什么？怎么评？评几分？
4.1 评估指标：BP、WP、RL
ASPICE的评估指标分三层，我习惯叫它们「三兄弟」。
4.1.1 BP（Base Practices，基础实践）
BP是每个过程必须做的基本活动。比如软件单元验证过程，它的BP就包括：
- 制定验证策略
- 选择验证方法
- 执行静态分析
- 执行动态测试
- 记录验证结果
每个BP都有明确的输出要求。我在项目中遇到过有人问：「我做了测试，但没写报告算不算？」答案很明确：不算。ASPICE讲究的是「做了就要有证据」。
4.1.2 WP（Work Products，工作产品）
WP就是你的产出物。包括文档、代码、测试用例、评审记录等等。每个过程都有对应的WP清单。
举个例子，软件需求分析过程的WP包括：
- 软件需求规格说明
- 需求追溯矩阵
- 需求评审记录
- 需求变更记录
嗯，这里要注意：WP不是越多越好。我见过有人为了应付评估，搞了一堆没用的文档。其实ASPICE更看重的是WP的质量和一致性。
4.1.3 RL（Resource and Role，资源与角色）
RL评估的是你有没有「人」和「工具」来做这件事。比如：
- 有没有专职的测试工程师？
- 有没有配置管理工具？
- 有没有缺陷跟踪系统？
我曾经在一个小团队里做评估，他们连版本管理工具都没有，全靠手动拷贝文件。这种场景下，RL评分基本就是0级。
4.2 评估过程：从准备到出报告
ASPICE的评估过程，我总结为四个阶段。
4.2.1 评估准备
这个阶段主要做三件事：
- 确定评估范围：评估哪些过程？是全部还是部分？
- 组建评估团队：至少需要一名主任评估师
- 收集初步证据：先看文档，再定计划
我个人习惯在准备阶段先做一次「预评估」。就是自己先对照PAM过一遍，看看哪些地方明显有漏洞。这样正式评估时就不会太被动。
4.2.2 现场评估
这是最核心的阶段。评估师会：
- 访谈项目成员
- 审查工作产品
- 观察实际工作流程
- 验证过程执行情况
你想想看，评估师问你的问题，其实都是围绕BP来的。比如：「你们怎么做代码评审的？」「评审记录在哪里？」「发现的问题怎么跟踪？」
4.2.3 评分与评级
评估师会根据收集到的证据，对每个过程进行评分。评分结果会汇总成一份评估报告。
4.2.4 结果反馈
评估结束后，评估师会给出改进建议。这时候别急着反驳，先听听对方的逻辑。我见过有人当场和评估师争论，结果反而暴露了更多问题。
4.3 评分规则：能力等级怎么定？
ASPICE的能力等级从0级到5级。但实际项目中，大多数企业做到2级或3级就够了。
| 等级 | 名称 | 核心要求 |
|---|---|---|
| 0级 | 不完整 | 过程未执行或部分执行 |
| 1级 | 已执行 | 所有BP都完成，有产出物 |
| 2级 | 已管理 | 有计划、有监控、有资源保障 |
| 3级 | 已建立 | 过程标准化，可跨项目复用 |
| 4级 | 可预测 | 有量化指标，可预测过程表现 |
| 5级 | 持续优化 | 有持续改进机制 |
评分时，评估师会看每个BP、WP、RL的满足程度。评分标准是：
- N（Not achieved）：0-15% 满足
- P（Partially achieved）：16-50% 满足
- L（Largely achieved）：51-85% 满足
- F（Fully achieved）：86-100% 满足
4.4 我的实战经验
最后分享几个我踩过的坑：
- 别把BP当清单：BP是指导你「怎么做」的，不是让你「做完打勾」的。我见过有人把BP当checklist，做完一项划掉一项，结果过程之间完全脱节。
- WP要可追溯：你的需求文档、设计文档、测试用例之间要有明确的关联关系。评估师最喜欢问：「这个需求对应的测试用例在哪里？」
- RL不是摆设：你写了「有专职测试工程师」，但实际测试工作全是开发在做。这种前后矛盾的情况，评估师一眼就能看出来。
说白了，PAM评估不是要为难你。它是一面镜子，照出你开发过程中的真实状态。搞懂它，你就能知道自己的团队到底处在什么水平，下一步该往哪里走。
下一章，我们会聊聊如何根据评估结果制定改进计划。到时候我会分享一个我实际用过的改进模板，希望对你有帮助。