在最近一次迭代回顾会上，我看了下I项目里开发的一些度量指标。之所以从系统上看，是因为从上一迭代开始，团队由物理看板转为电子看板，那度量指标就不用手动操作收集了，目测能节省很多工作量，心里窃喜了一下。
当我查看过几个我关心的度量指标（展现为折线图）后，发现了一个问题：研发时效中统计的用户故事卡24张，交付时效中统计的用户故事卡34张，中间差的10去了哪里？
于是问了团队，以下是交流内容。
通过这次交流，可以看出来团队一些潜在的问题，这让我欣喜，因为只有发现了问题才好对症下药，对这几位回复的同事我是心存感激的。I项目本身是做敏捷研发管理工具的，包括电子看板、需求管理、用户故事、代码管理、发布流水线等，自然也包含项目管理中的一些度量指标的开发。原本以为团队对自身开发的度量指标应该有认同感，可是结果却出乎意料。那问题出在哪里呢？
1、这个团队（可能不是个例）认为度量指标是给领导汇报用的，而作为外部敏捷教练从第三方的角度来看，度量指标应该是辅助团队自身能力提升的一种手段。这些指标到底有没有帮助，团队自己是有话语权的，你自己都觉得没用，为什么要做它呢？这些指标既然做了，那就把它用好，特别是团队的管理者及核心成员要认可并刻意去做才会更有成效。而“领导需要”这个可以作为指标数据出现后的附加价值。
2、电子看板上的卡片拖动不及时：为什么前期在使用物理看板（近3个月的时间）的时候没有这个问题呢？因为物理看板时期养成的好习惯。在使用物理看板开站会时，每个人会对照卡片说自己工作、同时挪动卡片，这相当于给了每个人自己增加了一个潜在的约束：“我承诺的事是要做到的”。而使用电子看板后，站会采用投影仪投射出电子看板，没办法让每个人方便操作、快速移卡，于是就容易变成站会只是说工作，而说的内容也未必会跟卡片对应，站会后其它时间再去移卡，这种情况下，就出现了那“10”张从待开发直接移动到上线，开发时间是0而在度量数据里“消失”的情况，这样统计出来的一些数据自然没办法准确；
3、我们设定一些度量指标的目的是提升团队信心、帮助团队持续成长，最终让团队交付出来的产品能更加满足客户或用户的要求（客户/用户满意度提升）。但指标好不好用是需要团队在实践中体会和探索的，一上来就说这不行、那也不行、没办法做，那请你仔细想想为什么不行？怎样做是可行的？没有实践就没有发言权，想好了、做到了你再说自己的观点，对自己负责，对团队负责。
我们设计度量指标时有几个要点：
1、度量指标是面向团队而非个人的：安全感
2、度量指标是被敏捷团队认可的：认同感
3、度量指标对团队提升有帮助的：有价值
4、度量指标越精简越好：易操作性
以我们目前的研发状况来看，我们建议敏捷试点团队使用的度量指标是四个：研发效率、交付效率、缺陷修复时间、故事吞吐率。我们还设计了其他一些度量指标我在本文暂不赘述，如有需要可联系作者一起讨论。
一、响应力指标
1、研发时效：
指标含义：软件研发耗费时长。
计算方法：从需求澄清后开始计时，到UAT结束。
指标价值：反映研发效率。
推荐指数：★★★★★
2、交付时效：
指标含义：业务需求交付耗费时长。
计算方法：从需求提出后开始计时，到实现需求的软件上线发布结束。
指标价值：反映整体效率。
推荐指数：★★★★★
3、故障修复时长：
指标含义：生产缺陷出现后的修复时间。
计算方法：从生产缺陷被发现（提出）后开始计时，到缺陷修改完毕上线发布结束。单位通常以小时计。
指标价值：反映故障解决效率。
推荐指数：★★★★
二、产能指标
1、故事吞吐率
指标含义：在固定时间内（一个迭代周期）已交付的工作项（用户故事）数量。对于已经开始尚未结束的用户故事不计入其中。
计算方法：一个迭代内完成的用户故事个数。
指标价值：吞吐率反映团队的产能，可用于做计划，团队目标之一是持续改善吞吐率。吞吐率来自于团队交付能力的真实数据，吞吐率的变化反映了故事大小、复杂性、紧急程度和人员技能等因素的影响。
推荐指数：★★★★★
