第三章：度量指标基础——什么是度量指标、度量指标的分类
各位同学，咱们今天聊点实在的。
做ASPICE这么多年，我见过太多团队一上来就喊「我们要做度量」，结果呢？收集了一堆数据，最后全躺在Excel里吃灰。为什么？因为大家根本没搞清楚——到底什么是度量指标。
3.1 度量指标到底是什么？
先别急着翻定义。我用自己的话给你解释：度量指标，就是把「感觉」变成「数字」的工具。
举个例子。你问一个项目经理：「项目进度怎么样？」他可能说：「还行吧，感觉挺顺利的。」——这叫感觉。但如果你问他：「需求覆盖率是多少？测试通过率是多少？」——这叫度量指标。
我个人习惯把度量指标比作汽车的仪表盘。你开车的时候，不可能光靠「感觉」来判断车速吧？你得看时速表。同样，做软件开发，你不能光靠「感觉」来判断质量，你得看数据。
核心定义：度量指标是对过程、产品、项目的某个属性进行量化测量的结果。它帮助我们客观地评估现状、预测趋势、做出决策。
嗯，这里要注意：度量指标 ≠ 原始数据。原始数据是「代码行数5000行」，度量指标是「千行代码缺陷率2.3个/KLOC」。后者才有意义。
3.2 度量指标的分类
在ASPICE里，度量指标通常分成三大类：过程度量、产品度量、项目度量。我刚开始做过程改进时，也经常搞混这三者的区别。后来在项目中踩过坑，才真正理解。
3.2.1 过程度量
过程度量，说白了就是看你的流程跑得怎么样。
它关注的是「怎么做」的问题。比如：
- 需求评审的效率如何？
- 代码审查的覆盖率是多少？
- 变更请求的平均处理周期是多久？
我在项目中遇到过这样一个案例：有个团队，过程度量显示「需求评审通过率」高达98%。乍一看，流程执行得不错吧？但仔细一查，发现评审会根本没人认真看文档，都是走过场。所以，过程度量一定要结合实际情况来看，不能只看数字。
我的建议：过程度量最好选那些「能反映行为变化」的指标。比如「评审缺陷发现率」就比「评审通过率」更有价值。
3.2.2 产品度量
产品度量，关注的是你造出来的东西质量怎么样。
它回答的是「做得好不好」的问题。比如：
- 代码的圈复杂度是多少？
- 单元测试覆盖率达到了多少？
- 静态分析发现的严重缺陷数量？
你想想看，产品度量是客户最关心的。客户不会管你流程多规范，他只关心你交付的产品靠不靠谱。
我记得有一次做功能安全项目，客户要求「MC/DC覆盖率必须达到100%」。这就是典型的产品度量——它直接跟产品质量挂钩。
避坑指南：我曾经见过一个团队，为了追求「代码覆盖率100%」，写了一大堆无意义的测试用例。覆盖率是上去了，但真正的逻辑漏洞一个都没测出来。产品度量要追求「有效」，而不是「好看」。
3.2.3 项目度量
项目度量，关注的是项目本身管得怎么样。
它回答的是「能不能按时交付」的问题。比如：
- 项目进度偏差是多少？
- 预算偏差率是多少？
- 资源利用率如何？
项目度量跟项目经理关系最大。我经常跟项目经理说：项目度量是你的「方向盘」和「油门」。没有它，你就是在闭着眼睛开车。
举个例子。项目度量显示「进度偏差超过20%」，这时候你就得赶紧调整计划了。别等到交付前一周才发现来不及。
3.3 三类度量的关系
这三类度量不是孤立的。它们之间有关系，而且关系还挺紧密。
| 度量类型 | 关注点 | 典型指标 | 使用场景 |
|---|---|---|---|
| 过程度量 | 流程执行效率 | 评审覆盖率、变更处理周期 | 过程改进、流程审计 |
| 产品度量 | 产品质量水平 | 缺陷密度、测试覆盖率 | 质量评估、验收决策 |
| 项目度量 | 项目管控状态 | 进度偏差、成本偏差 | 项目监控、风险预警 |
你看这个表就明白了。过程度量做得好，通常能带动产品度量提升；产品度量稳定了，项目度量自然好看。反过来，如果项目度量一直亮红灯，那多半是过程或产品出了问题。
3.4 如何选择度量指标？
这个问题，我每次培训都会被问到。我的回答很简单：别贪多，选对的。
很多团队一上来就列了二三十个指标，结果呢？数据收集累死人，分析起来又不知道重点在哪。我个人习惯是：每个类型先选3-5个核心指标，跑一段时间再调整。
给你一个实用的选择原则：
- 跟目标挂钩——这个指标能直接反映你的目标达成情况吗？
- 可测量——数据能稳定获取吗？还是需要人工估算？
- 可行动——看到这个指标异常，你能采取什么行动？
- 有时效性——数据能及时获取吗？还是等收集完已经过时了？
记住：度量指标不是用来「展示」的，而是用来「决策」的。如果一个指标不能帮你做决策，那它就是多余的。
3.5 一个真实的案例
最后，分享一个我亲身经历的项目。
那是一个ADAS（高级驾驶辅助系统）项目，ASPICE Level 2认证。刚开始，团队只关注「测试用例执行通过率」这一个指标。结果呢？测试通过率一直维持在95%以上，但现场反馈的缺陷却越来越多。
后来我介入，建议他们增加几个度量指标：
- 过程度量：需求评审的缺陷发现率
- 产品度量：静态分析严重缺陷数、代码圈复杂度
- 项目度量：缺陷修复周期、回归测试覆盖率
结果发现，问题出在需求评审环节——评审缺陷发现率只有12%，说明评审根本没认真做。根源找到了，后面的事情就好办了。
所以你看，度量指标不是摆设。用对了，它就是你的「火眼金睛」。
好了，这一章的内容就到这里。下一章，咱们聊聊「如何设计一套实用的度量指标体系」——这可是实战中的硬功夫。