18-度量分析体系CMMI3核心迭代效率、缺陷率、版本稳定性数据统计黒漂技术佬 出品 | CSDN原创大家好我是黒漂技术佬。上篇我们搭好了文档体系但光有文档还不够——CMMI3里有一块让很多小团队头疼的东西叫度量分析MAMeasurement and Analysis。简单说就是你说你做得好拿数据出来看看。很多团队的度量状态是“领导我感觉我们最近效率挺高的。” 这种感觉流管理在CMMI3评估里是混不过去的。一、MA在CMMI3中的核心地位为什么它是核心CMMI3的18个过程域PA里MA是一个支持类过程域但它的地位很特殊——没有MA其他PA的自证就缺乏依据。举个例子你说你做了需求管理REQM需求变更率是多少没数据怎么证明管住了你说你做了项目监控PMC进度偏差是多少没数据怎么说明在监控你说你做了验证VER缺陷发现率是多少没数据怎么证明验证有效所以MA是CMMI3的度量底座。好消息是小团队不需要像大厂那样搞几十个指标抓住下面三类关键指标就够了。二、关键度量指标详解2.1 迭代效率类你的团队到底多能打衡量指标指标公式说明Velocity速率完成Story Points / Sprint衡量团队单位迭代的产出能力Throughput吞吐量完成需求数 / 周期和Velocity类似但用需求数而非点数Lead Time交付周期需求提出→上线的时间衡量从想法到交付的全链路速度Cycle Time开发周期开发开始→上线的时间衡量纯开发环节的效率怎么采集Jira / PingCode 这类工具自带报表Velocity Chart和Cumulative Flow Diagram点开就有没有JiraExcel也能搞每个Sprint记录完成的故事点数画个折线图就行怎么分析Velocity持续下降 → 可能是技术债堆积该安排重构Sprint了Lead Time突然拉长 → 查瓶颈在哪个环节等待评审测试排队Cycle Time波动大 → 需求拆分不均匀大的太大小的太小技术佬提示Velocity不要用来考核个人绩效一考核数据就变形了——你懂的。2.2 缺陷率类代码质量是底线衡量指标指标公式说明缺陷密度缺陷数 / 千行代码(KLOC)衡量代码质量的基础指标缺陷逃逸率生产缺陷数 / 总缺陷数测试阶段没抓到、溜到线上的缺陷比例缺陷修复效率平均修复时间(MTTR Bug)从发现到修复完成的时间缺陷注入阶段分布各阶段引入缺陷数分析缺陷在哪个阶段引入最多怎么采集静态分析SonarQube 扫描代码Bug、漏洞、坏味道一目了然缺陷管理Jira里Bug类型的Issue从创建到关闭全生命周期跟踪生产缺陷线上监控系统如Sentry、ARMS记录的生产异常怎么分析缺陷逃逸率20% → 测试覆盖不足该加测试用例了缺陷密度持续上升 → 代码审查该抓严了需求阶段注入的缺陷最多 → 需求评审要加强源头问题要根治关键认知缺陷发现得越晚修复成本越高。需求阶段发现一个Bug可能花5分钟改文档生产环境发现可能花5小时排查回滚修复验证。2.3 版本稳定性类线上不出事才是硬道理衡量指标指标公式说明MTBF平均无故障时间总运行时间 / 故障次数系统多久出一次问题MTTR平均恢复时间总故障恢复时间 / 故障次数出问题后多久能恢复回滚率回滚次数 / 发布次数多少比例的发布需要回滚可用性正常运行时间 / 总时间系统有多大概率是可用的怎么采集Grafana Prometheus服务监控、告警、可用性统计一条龙发布记录Git Tag CI/CD日志记录每次发布的时间、版本、是否回滚故障记录每次线上故障做Post-Mortem事后复盘形成故障记录表怎么分析MTTR超过30分钟 → 自动化运维能力不足该做自动回滚和自愈了回滚率超过10% → 测试环境与生产环境差异大或者发布流程有问题MTBF持续缩短 → 系统稳定性劣化可能跟最近的变更有关三、数据采集工具链小团队的抄作业方案环节工具采集什么项目管理Jira / PingCodeVelocity、Lead Time、缺陷分布代码质量SonarQube缺陷密度、技术债、覆盖率CI/CDJenkins / GitLab CI构建成功率、部署频率、回滚次数监控告警Grafana PrometheusMTBF、MTTR、可用性日志分析ELK / Sentry线上异常、错误趋势小团队入门路线先把Jira报表搞起来迭代效率和缺陷率就有数据了接上SonarQube代码质量指标自动化有余力再上Grafana监控面板版本稳定性一目了然技术佬建议一开始别铺太大就从Jira SonarQube起步三个月后看效果再逐步加。四、度量驱动的过程改进数据不是用来看的是用来改的很多团队把度量数据做成了每周五的汇报PPT这完全违背了MA的初衷。度量的真正价值在于驱动过程改进。建立度量→分析→改进→再度量的闭环设定基线比如当前迭代Velocity是20点/Sprint缺陷逃逸率是15%设定目标Velocity提到25点逃逸率降到10%制定改进措施拆分需求更细、增加代码Review环节观察趋势下个Sprint看数据是否改善调整策略没改善就换方案改善了就固化流程举个例子我们团队某季度缺陷逃逸率从10%涨到了22%一看数据——测试阶段发现的Bug占比在下降生产发现的占比在上升。排查后发现是Sprint压缩得太紧测试时间不够。调整方案Sprint长度从2周改3周测试时间保证3天以上。下个季度逃逸率降回8%。五、总结度量分析不是KPI考核工具是小团队看清自己的镜子。三组指标迭代效率、缺陷率、版本稳定性搞扎实CMMI3的MA这块基本就拿下了。记住一句话测量你想改进的改进你测量的。数据不会说谎但只收集不分析的数据等于废纸。 18-度量分析体系（CMMI3核心）：迭代效率、缺陷率、版本稳定性数据统计
18-度量分析体系CMMI3核心迭代效率、缺陷率、版本稳定性数据统计黒漂技术佬 出品 | CSDN原创大家好我是黒漂技术佬。上篇我们搭好了文档体系但光有文档还不够——CMMI3里有一块让很多小团队头疼的东西叫度量分析MAMeasurement and Analysis。简单说就是你说你做得好拿数据出来看看。很多团队的度量状态是“领导我感觉我们最近效率挺高的。” 这种感觉流管理在CMMI3评估里是混不过去的。一、MA在CMMI3中的核心地位为什么它是核心CMMI3的18个过程域PA里MA是一个支持类过程域但它的地位很特殊——没有MA其他PA的自证就缺乏依据。举个例子你说你做了需求管理REQM需求变更率是多少没数据怎么证明管住了你说你做了项目监控PMC进度偏差是多少没数据怎么说明在监控你说你做了验证VER缺陷发现率是多少没数据怎么证明验证有效所以MA是CMMI3的度量底座。好消息是小团队不需要像大厂那样搞几十个指标抓住下面三类关键指标就够了。二、关键度量指标详解2.1 迭代效率类你的团队到底多能打衡量指标指标公式说明Velocity速率完成Story Points / Sprint衡量团队单位迭代的产出能力Throughput吞吐量完成需求数 / 周期和Velocity类似但用需求数而非点数Lead Time交付周期需求提出→上线的时间衡量从想法到交付的全链路速度Cycle Time开发周期开发开始→上线的时间衡量纯开发环节的效率怎么采集Jira / PingCode 这类工具自带报表Velocity Chart和Cumulative Flow Diagram点开就有没有JiraExcel也能搞每个Sprint记录完成的故事点数画个折线图就行怎么分析Velocity持续下降 → 可能是技术债堆积该安排重构Sprint了Lead Time突然拉长 → 查瓶颈在哪个环节等待评审测试排队Cycle Time波动大 → 需求拆分不均匀大的太大小的太小技术佬提示Velocity不要用来考核个人绩效一考核数据就变形了——你懂的。2.2 缺陷率类代码质量是底线衡量指标指标公式说明缺陷密度缺陷数 / 千行代码(KLOC)衡量代码质量的基础指标缺陷逃逸率生产缺陷数 / 总缺陷数测试阶段没抓到、溜到线上的缺陷比例缺陷修复效率平均修复时间(MTTR Bug)从发现到修复完成的时间缺陷注入阶段分布各阶段引入缺陷数分析缺陷在哪个阶段引入最多怎么采集静态分析SonarQube 扫描代码Bug、漏洞、坏味道一目了然缺陷管理Jira里Bug类型的Issue从创建到关闭全生命周期跟踪生产缺陷线上监控系统如Sentry、ARMS记录的生产异常怎么分析缺陷逃逸率20% → 测试覆盖不足该加测试用例了缺陷密度持续上升 → 代码审查该抓严了需求阶段注入的缺陷最多 → 需求评审要加强源头问题要根治关键认知缺陷发现得越晚修复成本越高。需求阶段发现一个Bug可能花5分钟改文档生产环境发现可能花5小时排查回滚修复验证。2.3 版本稳定性类线上不出事才是硬道理衡量指标指标公式说明MTBF平均无故障时间总运行时间 / 故障次数系统多久出一次问题MTTR平均恢复时间总故障恢复时间 / 故障次数出问题后多久能恢复回滚率回滚次数 / 发布次数多少比例的发布需要回滚可用性正常运行时间 / 总时间系统有多大概率是可用的怎么采集Grafana Prometheus服务监控、告警、可用性统计一条龙发布记录Git Tag CI/CD日志记录每次发布的时间、版本、是否回滚故障记录每次线上故障做Post-Mortem事后复盘形成故障记录表怎么分析MTTR超过30分钟 → 自动化运维能力不足该做自动回滚和自愈了回滚率超过10% → 测试环境与生产环境差异大或者发布流程有问题MTBF持续缩短 → 系统稳定性劣化可能跟最近的变更有关三、数据采集工具链小团队的抄作业方案环节工具采集什么项目管理Jira / PingCodeVelocity、Lead Time、缺陷分布代码质量SonarQube缺陷密度、技术债、覆盖率CI/CDJenkins / GitLab CI构建成功率、部署频率、回滚次数监控告警Grafana PrometheusMTBF、MTTR、可用性日志分析ELK / Sentry线上异常、错误趋势小团队入门路线先把Jira报表搞起来迭代效率和缺陷率就有数据了接上SonarQube代码质量指标自动化有余力再上Grafana监控面板版本稳定性一目了然技术佬建议一开始别铺太大就从Jira SonarQube起步三个月后看效果再逐步加。四、度量驱动的过程改进数据不是用来看的是用来改的很多团队把度量数据做成了每周五的汇报PPT这完全违背了MA的初衷。度量的真正价值在于驱动过程改进。建立度量→分析→改进→再度量的闭环设定基线比如当前迭代Velocity是20点/Sprint缺陷逃逸率是15%设定目标Velocity提到25点逃逸率降到10%制定改进措施拆分需求更细、增加代码Review环节观察趋势下个Sprint看数据是否改善调整策略没改善就换方案改善了就固化流程举个例子我们团队某季度缺陷逃逸率从10%涨到了22%一看数据——测试阶段发现的Bug占比在下降生产发现的占比在上升。排查后发现是Sprint压缩得太紧测试时间不够。调整方案Sprint长度从2周改3周测试时间保证3天以上。下个季度逃逸率降回8%。五、总结度量分析不是KPI考核工具是小团队看清自己的镜子。三组指标迭代效率、缺陷率、版本稳定性搞扎实CMMI3的MA这块基本就拿下了。记住一句话测量你想改进的改进你测量的。数据不会说谎但只收集不分析的数据等于废纸。