在过去的几十年里，敏捷开发模式已经在全球的软件开发行业被广泛应用。每个科技企业要么已经使用敏捷模式，要么正处于向敏捷模式转型的过程。传统的项目管理指标，如生产率、进度偏差、成本偏差等，在敏捷体系中可能并不适用。甚至，这些指标可能起到适得其反的效果。
敏捷体系同样存在着众多的度量指标。所以每个敏捷团队都会遇到这个问题——其中哪些指标是关键？以下是一个实用的分享：一组在大多数场景和组织中都有用的敏捷指标，并且为了易于使用，我们将这些指标分为以下三个类别——生产力、稳定性和质量，具体如下。
一、生产力
以下关于有效利用资源以实现某些成果的关键指标。
1.OKR（目标）贡献
衡量团队为实现组织或业务部门的战略目标付出了多少努力非常重要。例如，该指标可能显示，在每个冲刺（Sprint）周期中，团队平均有60%的工作精力用于实现OKR。理想情况下，50%或以上的努力应该用于公司的OKR或战略目标。
2.价值交付
该指标有助于衡量每个冲刺周期交付的价值。在以产品为核心的组织结构中，这一度量更为直观，因为优先级的计算公式或评估矩阵，通常会以与开发团队评估故事点（用以量化工作量）相同的方式来估算价值。例如，WSJF（加权短作业优先）的优先级评估方法会依据商业价值、风险降低、时间敏捷性以及机会激活等因素来计算价值点数。而RICE方法则是基于覆盖范围和潜在影响力来进行价值点的估算。
3.燃尽图
燃尽图是一种简单的方式，用以实时追踪一组明确任务随时间的完成进度。其中，X轴代表时间框架内的任务集合，而Y轴则标示出该时间框架内的递增时间单位。燃尽图广泛应用于监测整个发布周期、史诗以及冲刺阶段的任务完成状况。强烈建议采用冲刺燃尽图，因其能有效地协助团队在冲刺阶段内每日保持在预定的执行轨迹之上。
（来源：PingCode燃尽图）
4.速度
从宏观角度来看，敏捷速度象征着每个冲刺周期内完成的故事点数。这一度量有助于预估完成一整批以故事点数计量的工作所需的冲刺周期数量。速度这一概念有多个不同的变体，包括最大速度、平均速度以及最佳速度。最理想的选择是最佳速度，即在每个冲刺周期内，根据验收标准完成一批工作所需的平均故事点数，同时没有任何悬而未决的缺陷。
5.前置时间
前置时间用以量化从工作项（无论是故事、功能还是史诗）的创建到其最终完成所需的时间跨度。这一指标是评估团队执行效率的优良标准。前置时间越短，团队在将创意或未解决的需求转化为实用软件方面的效率就越高。
6.周期时间
周期时间用于量化从开始着手工作项（无论是故事、功能还是史诗）到该项工作完成所需的时间长度。这一度量标准是一个有效的指标，用于评估团队在开发、测试和发布流程方面的效率。周期时间越短，团队在这些流程中的效率便越高。
7.累积流程图（CFD）
累积流程图为你展示了从项目启动到完成整个流程——包括接收、开发、测试和发布环节的瞬时概览。这是一种简洁的可视化手段，能让您迅速地识别并定位流程中的瓶颈环节。
（图片来源：PingCode看板）
8.净推荐值（NPS）
净推荐值（Net Promoter Score，NPS）是衡量推荐者与批评者之间差异的百分比指标。客户会被询问一个问题：“您有多大可能性会向其他人推荐这个产品？”并需在1到10的范围内给出评分。在这其中，给出9和10分的被视为推荐者，8和9分的为中性评价者，而6分或更低的则是批评者。更多相关信息可在此处找到。可以说，NPS是所有度量标准中最为关键的一个，因为客户是最能准确判断团队是否为其提供了有价值产品或服务的利益相关方。
二、稳定性
以下是有助于团队确保交付过程（包括开发、测试和部署）以稳定、可预测和可持续的方式运行的指标。
1.计划完成比率
计划完成比率用以表示在一个时间框架结束时，按照预定计划成功完成的任务或工作项所占的百分比。这一指标反映了团队在准确估算任务、解决潜在障碍、弥补技能差距，以及显然，按时完成交付方面的能力。目标完成比率应设定在80%或更高。对这一指标的持续关注将有助于确保团队在长期内达到更高的可预测性。
2.在制品（WIP）
在制品或者说进行中的工作（Work In Progress，WIP）是源自看板（Kanban）的一项核心度量标准，同时也在Scrum与Kanban的混合模式（Scrumban）中有所应用。WIP指的是当前正在活跃处理中的工作项的数量。该指标的目标在于限制进行中的任务数量，以减少频繁的上下文切换，并确保团队能够及时解决出现的障碍。在理想情况下，每名敏捷团队成员一次应只处理1-2个任务。
（图片来源：PingCode看板）
3.准时发布率
该数值代表了按照预定发布日期成功完成的发布所占的百分比。这一指标象征着按时完成发布活动的可预测性水平。该数值越高，重新规划和组织调整的需求就越少，从而能显著减少团队资源的浪费。
4.部署失败次数
该数值展示了在特定时间范围内发生的失败部署次数。这一度量不仅适用于生产环境的部署，也适用于次要或较低环境的部署。它是代码稳定性的一个重要指标，同时也反映了开发团队在冲刺周期结束时是否真正拥有可供发布的成熟代码。此外，该指标也是衡量各个运行环境稳定性的一个准则。
5.团队流失率
这是关于稳定性最为关键的指标之一。流失率用以表示敏捷团队成员离队并被替代的频率。人员流失带来的成本是相当高昂的，包括招聘成本、新员工的熟悉周期，以及机构知识的流失，仅此几例。虽然一定程度的人员流失是不可避免的，但如果流失率超过行业平均水平，团队便需要认真对待并解决这一问题。
通常来说，科技行业的年流失率在10%至15%之间。最主要的流失原因包括薪资水平、职业发展机会以及工作环境。因此，如果您的团队流失率偏高，您应已明了需要采取何种措施。
6.幸福指数
与客户满意度评分（CSAT）相似，幸福指数通常是基于五点量表来评估团队成员的平均幸福感。这一调查通常作为冲刺回顾的一部分进行，并会随时间进行持续跟踪，以便监控各个冲刺周期间的变化。值得注意的是，幸福指数与流失率有着直接的相关性。两者呈反比关系：幸福指数越高，流失率则越低。
三、质量
以下是一些关键指标，有助于团队确保发布的代码具有可接受的质量。
1.缺陷解决时间
缺陷解决时间（Defect Resolution Time，DRT）或平均解决时间（Mean Time To Resolution，MTTR）是衡量开发团队解决单一缺陷所需的平均时间。理论上，这一时间越短越好。
通常，会对所有运行环境中的缺陷进行平均DRT或MTTR的跟踪。DRT的服务级别协议（SLA）会根据不同的组织和团队而有所不同。一般来说，团队应当设定关键性缺陷的最大DRT为1天，高级缺陷为1-2天，中级缺陷为5-7天，以及低级缺陷为10-14天。值得注意的是，MTTR与客户满意度呈反比关系，因此其重要性不言而喻。我们可以使用PingCode这类工具来自动生成缺陷统计报表。
2.代码覆盖率
代码覆盖率是指单元测试所覆盖的代码行所占的百分比。理论上，这一比率越高越好，目标覆盖率通常应设定为超过80%。每次构建过程中都可以运行代码覆盖率的计算，以确保团队不会部署尚未达到就绪状态的代码。然而，需要注意的是，这一指标并不包括其他形式的测试。因此，高代码覆盖率并不必然等同于高代码质量。
3.测试覆盖率
测试覆盖率与代码覆盖率虽然有时被交替使用，但实际上它们是两个不同的概念。
代码覆盖率主要衡量编写的代码是否得到了测试的覆盖，而测试覆盖率则是用来衡量功能需求是否被现有的测试用例集全面覆盖的。目标覆盖率通常应设置在70-80%的范围内。为了更细致的分析，该指标的子组件还包括需求覆盖率、产品覆盖率、风险覆盖率以及边界覆盖率。这一度量标准确保了软件功能不仅满足了需求，而且仅仅是满足了需求。
4.缺陷逃逸率
这是指在生产环境部署后被识别出的缺陷数量，它是一种对软件质量的初步而直接的衡量。在理想情况下，这一数字应为零。如果不是零，团队应当重新审视其质量保证和部署流程，以目标将该数字降至零。
值得注意的是，缺陷在开发周期中被识别得越晚，其修复成本就越高。因此，这无疑是敏捷团队应当密切跟踪的关键性指标之一。
总结
当然，敏捷方法论是一种经过时间考验的、能够最大化客户价值的软件交付模式。环绕这一流程，存在着数不胜数的度量标准和观点。如果我们将所有度量标准都视为同等重要，那么实际上没有任何一个度量标准会显得特别重要。关键在于精选一套适合您团队的核心度量标准。毋庸置疑，没有实际执行，任何理念都是空洞的。诚然，初尝其味可能会觉得艰难，甚至在某些时刻会感到痛苦和不耐烦。然而，一旦团队逐渐成熟，掌握了如何遵循基础流程并跟踪关键度量标准，那么所带来的成果将会是无比宝贵的。
本文的目的并非让大家达成共识，而是希望你在了解这些度量标准及其背后的逻辑后，能为自己做出决策。我期望其中一些度量标准和背后的推理对您将会有所裨益。
