概要
无论你对度量标准有什么看法，公司都会期望以此来评估你的团队。你不想只衡量一个方面而忽略其他信息，但你也不希望评估太多的东西，以至于分散了团队的焦点。以下四个指标可以均衡地评估敏捷团队的生产力，工作质量，可预测性和健康状况。
评估项目的指标数量与构建项目的指标数量一样多。不幸的是，这些指标中的很多都没有用。埃里克里斯称他们为“虚荣指标”，因为他们看起来不错，让你感觉良好，但没有可操作性。
无论你你对度量标准有何看法，在（项目）结束那天，企业都会期望获得评估结果。以“帮助团队自我反思和提高”为标准，并提醒你“你的里程可能会有所不同”，以下是我对敏捷团队的四项指标，以及一些有效经验。
1四个联锁小组度量
为什么有四个？如果你只是衡量一个指标的话，就很容易陷入到狭窄的认知中。无论是团队专注于制定指标（通常是通过改变原有体系）还是管理层使用这些措施来推动所有决策，你最终只能得到一个看起来不错，但实际上已经处于悬崖边上的产品或组织。
同样，有多达10个指标，更可能导致团队的不同部分聚焦不同的指标，从而影响团队的架构。人类最好每次处理三到五个概念，因此四个主要度量标准看起来就像是最佳的仪表板。
周期时间
周期时间是你与生产力的直接联系。周期时间越短，给定时间盒中的事情越多。
你可以从工作开始到功能完成时进行测量。在软件开发的背景下，我更想把这个时间看做是大家实际工作在软件开发上的时间。测量周期时间最好是通过你选择的敏捷生命周期工具自动完成，即使使用物理任务板进行度量也能为你提供有用的数据。
缺陷逃逸
这项措施是客户满意度与团队之间的联系。缺陷率越低，客户对该产品的满意度越高。缺陷率很高，即使是最棒的产品也会有很多不满意的客户。
你可以通过产品发送给用户后发现的问题（bug，缺陷等）数量来衡量。在一个故事完成之前，它仍在进行中，所以关注故事的执行比追踪正在进行的缺陷更可取。
计划与完成比率
此度量标准是衡量可预测性的一种方式。如果一个团队承诺30个故事并且只交付了9个故事，那么PO就有30％的机会获得他们想要的东西。另一方面，如果团队承诺10个故事并交付9个，则PO有大概90％的机会获得他们想要的东西。
衡量是一个简单的运用，记录团队在sprint开始时承诺的工作量，以及结束时他们完成的工作量。
幸福感
这是团队的“健康”指标。它创造了将其他三个指标置于更好环境中的意识。如果其他指标都是完美的，而幸福感很低，那么团队可能会很快就筋疲力尽了。
把它建立到你的sprint回顾中。在每次回顾会上（无论规模）都让大家协商自己的幸福指数。从一个sprint到另一个sprint的过程中观察这些数据的趋势。
2为什么选择这些指标？
周期时间和缺陷逃逸是高度量化的，并且在各个行业都很好理解。较小的数字意味着你可以更快地提供更高质量的产品。我原本增加了计划完成比率，主要是因为这是团队可以立即产生实际影响的因素，所以这实现了“早期获胜”的想法。它在绘制可预测性方面长期有用。幸福指标是“人为因素”，它让我们衡量整个团队的健康状况。
前三项措施形成一个自我支撑的三角形。如果你的周期时间缩短，那么缺陷几乎肯定会增加。高计划完成比例可能非常好，除非周期时间已经过去了，这表明在每次sprint中团队完成得很少。最后，通过将幸福感与其他人分享，你可以看到等式中的人的一面。低幸福分数几乎总是潜在问题的标志，并且可能是其他事物的主要指标。
你可能想知道速率。我也跟踪速率，但我认为它有一个非常具体的地方。这四个指标是为了让团队在回顾中进行反思并关注改进的。
另一方面，速率是团队在sprint计划中使用的度量。它的唯一用处是粗略衡量下一次sprint需要做多少工作。如果分享管理链，它也可能被误用 - 有更好的方法可以预测一个团队何时完成或者其效果如何。
测量速度时，我测量故事点和故事计数速度。通过这样做，我发现该团队已经对其工作负载进行了内置的检查和平衡。举例来说，假设团队有三个sprint平均50个故事点和10个故事。如果他们的下一次sprint是48个点和9个故事，那么他们可能会完成所有的工作。如果他们超过了其中一个数字 - 比如说，做48个点但是20个故事（一堆小的） - 那么sprint可能会有风险，因为这是很多情境切换。如果他们超过这两个数字 - 比如说，达到70个点和15个故事 - 那么这是一个明确的警告标志，而一位优秀的教练可能希望与团队保持联系，以确保他们相信自己能比平均成绩好。
3行动中的指标
这些图表基于真实数据，并且是敏捷转型18个月左右的写照。我倾向于坚持1个为期六个月的滚动窗口，因为如果你远远超出这个范围，事情就会发生改变，并且与团队正在做的事情无关。
周期时间
峰值代表团队转向一个新项目，并且随着一系列组织变更，他们也快速的适应了新项目的工作。
缺陷逃逸
此图显示了一个相当典型的，已转移到跨职能角色和自动化测试团队的曲线。由于团队中的每个人都对故事和质量负有共同责任，并更加关注测试自动化，我们发现产品发布后的缺陷急剧下降。
计划到完成率
这个团队失去了ScrumMaster，这影响了它的整体性能，如第一个sprint的数据所反映的那样。在第二次冲刺中，有经验的ScrumMaster进来帮忙。早期的下跌代表团队习惯了一套新的规范，后来的下降是由于程序变化导致团队积压清晰度降低的结果。
幸福感
这些数据显示了ScrumMaster的支持如何改善了团队的整体健康状况。该图还反映了产品和组织的流失影响了团队以后的幸福感。
根据这些图表，我计划的第一件事就是与团队进行交流，并听取前几次sprint中发生的事情。计划完成率和幸福指标的下降足以告诉我可能会发生一些事情。低周期时间和缺陷逃逸会让我怀疑问题是团队外部因素造成的。
真正的挑战来自混乱的产品战略，这导致团队在优先级事项中来回切换。积压变化的波动导致低质量的故事。当他们挖掘出一个他们不明白的故事并转向他们所做的工作时，该团队的发展足够让他们停下来。这降低了计划完成比，因为并非所有承诺的工作都可以完成，而周期时间很短，因为他们处理了他们已经很好理解的事情。
试一试这些指标
我很幸运的使用了这些度量团队的指标。他们之间的内在关系使得可以在不改变其他条件的情况下实施这个度量。他们为团队提供有用的数据进行回顾性改进，对领导力和预测有帮助。
如果你有兴趣试用这些指标，则可以在下载我在Google文档中创建的团队信息中心套件。网址是https://docs.google.com/document/d/1Ecm8aDeec0txwyd0z1HNWKQsVeh2CN7gEhIOWXLadHI/edit
本文原文作者：Joel Bancroft-Connors
原文链接：https://www.agileconnection.com/article/4-balanced-metrics-tracking-agile-teams