度量就是为了识别价值流最大瓶颈

要疏通一个车流量拥堵的道路，加宽堵塞点上游的道路，只会加重拥堵；让堵塞点下游的司机换道行驶，对于缓解堵塞点无济于事。只有识别并解决了最大的堵塞点的拥堵，才能改善全局的流速。

在敏捷IT研发交付中，度量的作用，就好比是在识别价值流中最大的堵塞点，以便在“价值准、流速快、质量好”这3个维度中，识别端到端价值流最大瓶颈（以及方向错误），并将其作为下一步改进点进行改进，以最大化改进成效。

原则

有效的度量，需要具备以下原则：

• 全局性价值、流速和质量指标高于局部性指标
• 指标不要和绩效考核直接挂钩，而主要用于自我提升，否则会变为数字游戏
• 变化趋势高于绝对值
• 明确指标所针对的改进目标
• 指标越多，边际收益递减
• 当指标无法指导改进时，要果断放弃
• 为过滤掉一些会让平均值失真的异常值，可以用P50、P80（从小到大排序前80%的数值中最大的那个值，表示80%的情况都不大于该值，符合二八原则）、P90这样的百分位值来替代平均值

角色

在研发团队中，谁来关注度量呢？

SM（ScrumMaster）可以牵头，驱动QA（Quality Analyst）、TL（Tech Lead）、BA（Business Analyst）、Architect进行度量和改进。

QA、TL和BA可以通过度量数据，识别“价值准、流速快、质量好”的瓶颈。

Architect可以通过度量数据，识别价值流中架构问题所导致的瓶颈。

SM从上面所识别的“价值准、流速快、质量好”和架构问题所导致的瓶颈中，识别当前最大瓶颈，并作为下一步改进点进行改进。

时机

度量贯穿整个迭代过程。指标需要尽早、频繁、小批地搜集。

工具

如果工具平台暂不支持自动收集，可以每个迭代用手工进行统计。由于工作量较大，只能手工收集少量的数据。

需要逐步让流水线等工具平台，实现度量数据的自动收集。

输入

已经将需求拆分成能在一个迭代内完成的用户故事，并以用户故事为单位进行度量统计。

步骤

1. 绘制端到端价值流图
2. 识别指标：SM召集QA、TL、BA和Architect识别适用的度量指标，选出北极星指标，并做度量收集分工，然后从下个迭代开始持续收集
3. 迭代收集：SM驱动各角色每个迭代持续收集度量指标，并可视化变化趋势
4. 分析回顾：SM在每个迭代的回顾会上，向所有团队成员展示本迭代度量指标数据及其变化趋势，邀请大家在价值流图前，识别价值流最大的瓶颈，作为下个迭代的改进点，并讨论对其进行改进的行动项和负责人（下个回顾会改进项负责人简述改进成效）；请大家回顾度量指标是否能起到推动改进的目标，从而调整不适用的指标

输出

各个迭代所搜集的指标及其变化趋势

每个迭代回顾会上大家根据度量指标所识别的价值流最大瓶颈，以及相应的改进行动项和负责人

如果条件具备，可以将关键指标通过工具平台制作成仪表盘，并投在电视上，可视化给团队所有成员

方法

度量价值准的指标

• 业务满意度 = 类似NPS净推荐值（问业务人员：“能在多大程度上解决你的问题”从0到10打分） = 推荐值（9～10分）占比 - 贬损者（0～6分）占比

度量流速快的指标

• 生产环境业务系统部署频率 = 该业务系统生产环境最近几次部署（即数据中心OPs操作投产上线时点）之间的间隔时长的P80值
• 生产环境用户故事交货时长 = 该业务系统最近几次投产用户故事交货时长（从提交第一行代码到成功投产上线之间的时长）的P80值
• 生产环境业务系统严重故障修复时长 = 该业务系统最近几次必须尽快修复的严重故障的修复时长（从故障出现到成功修复或回滚之间的时长）的P80值
• 迭代变更率 = 迭代内变更（迭代内经过了开卡且已经提交代码库的故事，发生了必须在本迭代完成的变更，且变更总量超过原故事20%的故事点数）的用户故事总点数 / 迭代内全部用户故事点数
• 迭代完成率 = 迭代内状态为"测试完成"的用户故事总点数 / 迭代内全部用户故事点数
• 迭代速率 = 迭代内状态为测试完成的用户故事总点数
• 燃起图/燃尽图

度量质量好的指标

• 生产环境业务系统发布用户故事的故障率 = 该业务系统最近几次投产的用户故事中无法正常使用的比例的P80值

用户故事

• 用户故事细粒度验收条件编写比例 = 最近几次迭代编写了细粒度验收条件的用户故事占比的P80值
• 开卡率 = 最近几个迭代用户故事开卡率的P80值
• 验卡率 = 最近几个迭代用户故事验卡率的P80值

编码

• 代码重复率 = sonarqube扫描出的重复代码比例及变化趋势
• 代码复杂度 = sonarqube扫描出的代码圈复杂度及变化趋势
• 流水线构建失败修复时长 = 该业务系统流水线最近几次必须尽快修复的严重故障的修复时长（从故障出现到成功修复或回滚之间的时长）的P80值

测试

• 用户故事SIT测试首次良品率 = 最近几个迭代SIT测试阶段能首次测试通过的用户故事占比的P80值
• 业务主流程迭代回归测试案例执行率 = 本迭代业务主流程回归测试案例执行（无论是否手工或自动化）占比的P80值
• 业务主流程迭代回归测试执行时长 = 最近几次迭代业务主流程回归测试案例执行（无论是否手工或自动化）时长的P80值

绘制价值流图

SM可以先按图例，绘制价值流图，然后与BA、QA、TL一起讨论，修改其中瑕疵

价值流图

误区

• 片面提升局部指标，而忽视全局性指标
• 指标与个人绩效挂钩，导致数字游戏
• 将某一指标的绝对值用于团队间横向对比，导致数字游戏
• 指标过多，且不明确北极星指标，导致收集成本过高，指标无人问津，造成浪费
• 还在收集已经无法指导改进的指标
• “交付的需求数越多，则交付的价值数越多。”需求拆分粒度各异，难以用数量衡量价值数
• “交付质量可以用缺陷密度、缺陷数/案例数、缺陷数/需求数、千行bug率来衡量。”案例数和需求数的拆分粒度各异，难以评判；同样的功能，同样的bug数，代码写得更长的人千行bug率更低。