度量就是为了辨认代价流最大瓶颈

程序员 · 2024-10-3 04:29:09

要疏通一个车流量拥堵的门路，加宽堵塞点上游的门路，只会加重拥堵；让堵塞点卑鄙的司机换道行驶，对于缓解堵塞点无济于事。只有辨认并办理了最大的堵塞点的拥堵，才华改善全局的流速。
在灵敏IT研发交付中，度量的作用，就比如是在辨认代价流中最大的堵塞点，以便在“代价准、流速快、质量好”这3个维度中，辨认端到端代价流最大瓶颈（以及方向错误），并将其作为下一步改进点举行改进，以最大化改进成效。
原则

有用的度量，须要具备以下原则：

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

脚色

在研发团队中，谁来关注度量呢？
SM（ScrumMaster）可以牵头，驱动QA（Quality Analyst）、TL（Tech Lead）、BA（Business Analyst）、Architect举行度量和改进。
QA、TL和BA可以通太过量数据，辨认“代价准、流速快、质量好”的瓶颈。
Architect可以通太过量数据，辨认代价流中架构题目所导致的瓶颈。
SM从上面所辨认的“代价准、流速快、质量好”和架构题目所导致的瓶颈中，辨认当前最大瓶颈，并作为下一步改进点举行改进。
机遇

度量贯穿整个迭代过程。指标须要尽早、频仍、小批地搜集。
工具

如果工具平台暂不支持自动网络，可以每个迭代用手工举行统计。由于工作量较大，只能手工网络少量的数据。
须要渐渐让流水线等工具平台，实现度量数据的自动网络。
输入

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

绘制端到端代价流图
辨认指标：SM调集QA、TL、BA和Architect辨认实用的度量指标，选出北极星指标，并做度量网络分工，然后从下个迭代开始连续网络
迭代网络：SM驱动各脚色每个迭代连续网络度量指标，并可视化变化趋势
分析回首：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率更低。

度量就是为了辨认代价流最大瓶颈

所属分类: 问答交流

新帖推荐: 30日

推荐作品