敏捷团队需要选取一些关键指标对生产力、开发流程、产品质量进行度量，从而不断优化开发过程，提升团队效率。原文: Agile Metrics — What Matters and Why?

敏捷已经在几十年内占领了软件开发行业，每个技术组织要么是敏捷的，要么是在向敏捷转型的过程中，可以将它们统称为"敏捷组织"！传统项目管理指标，如生产力、进度差异、成本差异等，在敏捷系统中不但没用，而且事实上可能适得其反。

有很多指标适用于敏捷系统。问题是，哪些指标才是真正重要的？下面将介绍如何选择一个对大多数环境和组织都有用的敏捷度量子集。

为简单起见，我们将度量标准分为以下三类: 生产率、稳定性和质量，如下所示。

生产力(Productivity)

以下是有关有效利用资源以交付结果的关键指标。

OKR(目标)贡献

重要的一点是如何衡量团队为实现组织或业务单元的战略目标付出了多少努力。例如，在每个Sprint中，平均60%的团队能力用于OKR。理想情况下，50%或更多的努力应该用于OKR或公司战略目标。

价值传递(Value Delivered)

这个指标有助于度量每个Sprint交付的价值。在以产品为主导的组织中，优先级公式或矩阵以与开发团队评估工作故事点相同的方式实现价值评估。例如，WSJF(Weighted Short Job First, 加权短作业优先)优先排序方法根据业务、风险降低、时间关键性和机会实现来评估价值点。RICE方法估算跨越范围和影响的价值点。

燃尽图(Burndown)

燃尽图是一种简单的对一组任务所取得进展进行可视化的方法。X轴表示时间盒的任务集，Y轴表示时间盒内的增量时间单位。燃尽图用于监控整个release、epic和sprint任务的超时完成情况。强烈推荐sprint燃尽图，它有助于在sprint期间保持团队每天的工作进度。

流速(Velocity)

广义上讲，敏捷流速表示每个sprint中完成的故事点。这有助于基于故事点估算完成工作主体所需的sprint次数。流速有许多变体: 最大流速、平均流速和最佳流速。最好选择最佳流速，即根据验收标准，在没有任何未修复缺陷的情况下，每个sprint交付工作主体的平均故事点数量。

前置时间(Lead Time)

前置时间表示从创建工作项(Story, Feature或Epic)到完成所花费的时间。这是一个很好的衡量团队效率的标准。交付时间越短，团队将想法或未完成的请求转化为可工作软件的效率就越高。

周期时间(Cycle Time)

周期时间表示从工作项(Story, Feature或Epic)开始到完成所花费的时间。这是衡量团队开发、测试和发布过程效率的好方法。周期时间越短，团队的开发、测试和发布过程就越高效。

累积流程图(CFD, Cumulative Flow Diagram)

累积流程图提供了从开始到结束的整个启动、开发、测试和发布过程的快照，是一个简单的可视化工具，可以让我们立即识别瓶颈。

净推荐值(Net Promoter Score)

净推荐值是推荐者和诋毁者之间差异的百分比分数。顾客被要求给出一个从1到10的分数，表示他们向其他人推荐产品的可能性有多大。9分和10分是积极者，8分和9分是被动者，6分及以下是诋毁者。NPS可以说是所有指标中最重要的，因为客户是决定团队是否交付了任何有价值的东西的最佳利益相关者。

稳定性(Stability)

以下是将帮助团队确保交付过程(包括开发、测试和部署)以稳定、可预测和可持续的方式运行的度量指标。

计划完成比(Planned to Done Ratio)

计划完成比表示在时间框结束时按计划完成的任务或工作项的百分比，可以让我们了解团队正确评估任务、解决障碍、技能差距以及及时交付的能力，目标是超过80%。密切关注这一指标将确保在长期内具有更高的可预测性。

在制品(Work In Progress, WIP)

在制品是看板中的关键指标，也可以在Scrum中看到它。WIP是正在处理的工作项的数量，其目的是限制正在进行的工作，以减少上下文切换，使团队及时解决阻塞。理想情况下，我们的目标应该是每个Scrum团队成员一次完成1-2个任务。

准时发布率(On-time Release Rate)

这是在发布日期按计划完成发布的百分比，表示团队在按时完成发布方面的可预测性。数字越高，重新规划和重组的需求就越低，而这些会导致团队能力的严重浪费。

失败部署(Failed Deployments)

表示在给定时间范围内失败的部署数量，涉及生产部署和低级环境的部署，是对代码稳定性的度量，并显示开发团队是否在Sprint结束时准备好了潜在的可发布代码，也是对环境稳定性的一种衡量。

团队流动率(Team Turnover Rate)

当涉及到稳定性时，这是最重要的指标之一。离职率表示敏捷团队成员离开团队和被替换的比率。团队成员流动的成本很高，招聘、提升技能、团队知识的流失等等都是成本。一定程度的流失不可避免，但如果超出了行业水平，就应该设法解决。一般来说，科技行业的人员流动率在每年10%到15%之间。员工流失的三大原因是: 薪酬、职业发展机会和工作条件。所以你知道如果人员流动率很高该怎么做了吧。

幸福指数(Happiness Score)

与CSAT(客户满意度评分, Customer Satisfaction Score)类似，通常以5分的标准对团队平均幸福感进行评分。该调查通常作为Sprint回顾的一部分进行，并随着时间的推移进行跟踪，以监视一个又一个Sprint的偏差。幸福指数与离职率直接相关，幸福指数与离职率成反比，幸福指数越高，离职率越低！

质量(Quality)

下面给出了一些关键指标，帮助团队确保交付的代码具有可接受的质量。

缺陷解决时间(Defect Resolution Time)

缺陷解决时间(DRT, Defect Resolution Time)或平均解决时间(MTTR, Mean Time To Resolution)是开发团队解决缺陷所需的平均时间，越短越好。平均DRT或MTTR通常跟踪所有环境中的缺陷。DRT的SLA因组织和团队而异，一般来说，团队应该将最大DRT的目标定为关键缺陷1天，高缺陷1-2天，中等缺陷5-7天，低缺陷10-14天。MTTR与客户满意度呈负相关，因此很重要。

代码覆盖率(Code Coverage)

代码覆盖率是单元测试所覆盖的代码行所占的百分比，越高越好，目标是覆盖率超过80%。可以为每个构建都执行代码覆盖率检查，确保团队不会部署未准备好的代码。但代码覆盖率并不包括其他类型的测试，因此高代码覆盖率并不一定意味着代码质量高。

测试覆盖率(Test Coverage)

有时，术语"测试覆盖率"与"代码覆盖率"可以互换使用，但并不相同。当代码覆盖率度量编写的代码是否被测试覆盖时，测试覆盖率度量功能需求是否被现有测试用例集所覆盖。目标是70-80%的覆盖率。子组件包括需求覆盖、产品覆盖、风险覆盖和边界覆盖。这个度量确保功能满足并且只满足需求。

逃逸缺陷(Escaped Defects)

这是在生产部署之后发现的缺陷数量，是对软件质量的粗略度量。理想情况下，这个数字应该是零，如果不是零，团队应该重新评估其QA和部署流程，将其降低到零。

在开发周期中发现缺陷越晚，修复成本就越高。因此，这是敏捷团队应该跟踪的关键指标之一。

综合度量

敏捷是经过时间考验的软件交付方式，可以最大限度为客户带来价值。在这个过程中有几十甚至上百个指标，如果我们认为所有指标都很重要，那就没有一个指标是真正重要的。关键是要选择适合团队的核心指标。不用说，如果没有执行的话，想法将毫无价值。是的，说起来容易做起来难。一开始会很困难，有时很痛苦。但一旦团队成熟并知道如何坚持基本流程并跟踪关键指标，结果就会物超所值。

你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！