3、能力度等级0-1:不完全执行与已执行的过程、基本实践与工作产品
好,咱们今天聊聊ASPICE里最基础,也最容易让人栽跟头的两个等级——能力度0级和1级。
说实话,我见过太多团队一上来就盯着高等级去,结果连最基础的0级和1级都没站稳。嗯,这就像盖楼不打地基,后面全是空中楼阁。我个人习惯是,先把这两个等级吃透,再谈什么优化、量化。
3.1 能力度等级0:不完全执行
什么叫不完全执行?说白了就是——过程要么没做,要么做了但没留下任何证据。
你想想看,评审会开了吗?开了。有会议纪要吗?没有。需求分析做了吗?做了。有需求文档吗?没有。这在ASPICE眼里,就是0级。
0级的核心特征其实就三点:
- 过程未执行或部分执行——活动做了,但不成体系
- 没有可验证的工作产品——拿不出任何产出物
- 无法证明过程的有效性——你说你做了,谁信?
我记得有一次做差距分析,客户说他们的需求管理做得很好。我让他们拿出需求跟踪矩阵,结果他们给我看了一个Excel表格,里面只有需求编号,没有测试用例链接,没有变更记录。这其实就是0级——有工具,没过程。
3.2 能力度等级1:已执行的过程
到了1级,情况就好多了。1级要求的是:过程被执行了,而且有明确的工作产品作为证据。
怎么判断是不是1级?我一般看三个东西:
- 过程有没有被定义——哪怕只是简单的流程说明
- 过程有没有被执行——不是嘴上说说,是真干了
- 工作产品有没有产出——文档、代码、报告,总得有一个
💡 关键点:
1级不是要求你做得完美,而是要求你做了并且能证明你做了。
3.3 基本实践(Base Practices)
基本实践,就是每个过程域里必须做的那些事。我把它理解成“最低要求”。
举个例子,软件需求分析过程域(SWE.1)的基本实践包括:
- 定义软件需求
- 结构化软件需求
- 分析软件需求的影响
- 确认软件需求
- 建立双向可追溯性
- 确保一致性
- 沟通已批准的软件需求
你看,每一条都是具体的、可验证的活动。你做了,就有产出;没做,就是0级。
🔧 我的经验:
我建议团队在做基本实践时,不要贪多。先把每个实践对应的输出物列清楚,比如“定义软件需求”对应的输出就是《软件需求规格说明书》。这样审核的时候,一目了然。
3.4 工作产品(Work Products)
工作产品,就是基本实践产出的“物证”。没有工作产品,你说你执行了过程,没人信。
常见的误解是什么?很多人觉得工作产品就是文档。其实不是。工作产品可以是:
| 类型 | 示例 |
|---|---|
| 文档类 | 需求规格说明书、设计文档、测试计划 |
| 代码类 | 源代码、单元测试脚本、构建脚本 |
| 记录类 | 评审记录、会议纪要、变更请求 |
| 工具类 | 模型文件、配置文件、数据库脚本 |
为什么会有人觉得工作产品不重要?我遇到过一种情况:团队觉得“代码就是最好的文档”,所以不写设计文档。结果项目交接的时候,新来的工程师对着代码看了三天,愣是没看懂业务逻辑。嗯,这就是典型的工作产品缺失。
3.5 从0到1的关键转变
从0级到1级,说白了就是一句话:从“做了”到“证明做了”。
我总结了一个简单的检查清单,你可以对照着看看:
- ✅ 过程有没有被定义?(哪怕是一页纸的流程说明)
- ✅ 过程有没有被执行?(有记录、有日志)
- ✅ 工作产品有没有产出?(文档、代码、报告)
- ✅ 工作产品有没有被评审?(评审记录)
- ✅ 工作产品有没有被管理?(版本控制、变更管理)
如果这五条都满足了,恭喜你,至少1级是稳了。
⚠️ 注意:
1级不等于“完美”。你可能会发现工作产品质量不高,或者过程效率低下。没关系,那是2级和3级要解决的问题。1级只要求你有,不要求你优。
3.6 实战中的常见误区
最后,我分享几个我在项目中遇到的典型误区:
- 误区一:文档越多越好
我曾经见过一个团队,为了应付ASPICE审核,写了上百页的文档,结果里面全是模板填充,没有任何实际内容。审核员一看,直接给了0级——因为工作产品没有实际价值。 - 误区二:过程定义太复杂
有些团队一上来就搞什么“全生命周期管理”,流程图画得跟蜘蛛网似的。结果没人看得懂,也没人执行。我建议从最简单的开始,比如“需求→设计→编码→测试”四步走,先把1级跑通。 - 误区三:忽视工具链
你想想看,如果需求管理用Excel,测试管理用Word,代码管理用SVN,那你怎么证明过程被执行了?工具链的整合,其实是1级的一个隐形要求。
嗯,今天就先聊到这儿。记住,0级到1级,核心就是“有证据的执行”。下一章咱们聊聊能力度等级2:已管理的过程。