你的团队应该关注的 17 个重要的敏捷指标

度量标准一直是敏捷专家争论的焦点。

尽管由于高质量软件的持续交付，敏捷开发是经验性的，但 PMO 办公室、项目经理和客户仍然需要详细的状态报告，就像他们对任何基于瀑布的项目一样。 尽管业务需求是监督的一个原因，但敏捷开发本身会导致一些人总是想要确定的不确定性水平。

为了扭转这一趋势，许多敏捷主义者认为根本不应该使用度量，只有软件本身的生产才能被视为成功的衡量标准。 这种方法的支持者认为，开发团队和项目经理会本能地通过操纵用户故事和估计来博弈系统，以产生高效率的表象并隐藏真正的问题。 然而，有一句格言说明了什么是被衡量的，什么是被完成的。

这种博弈发生的主要原因是组织过于依赖一两个指标，而不是拥有一个全面的指标解决方案。 在本文中，我们将讨论已证明可以在团队绩效、质量、价值甚至敏捷性方面产生最佳情报的指标。 我们甚至会根据最新研究和最具创新性的案例研究，讨论一些您可能从未听说过的指标。

敏捷指标有什么用？

敏捷指标用于跟踪状态、质量、生产力、效率、价值，甚至是敏捷本身。 最重要的是，它们用于为业务决策提供信息。 无论您从事哪种项目，报告对外部和内部利益相关者都非常重要。 指标可以影响从产品管理到人员管理的各个级别的决策，因此，它们需要准确、信息丰富且公正。 在深入研究指标之前，我们首先需要建立所有此类测量所依据的基础。

铁三角与敏捷三角

在基于计划的方法中，测量是基于范围、进度和成本的旧“铁三角”。 大多数指标都属于这三个类别之一。 在敏捷世界中，这个三角形被颠倒了。 项目是通过在一定的约束条件下交付价值和质量来定义的。 预算或成本只是这些限制之一，而不是交付的主要焦点。

这里重要的是要了解价值和质量之间的关系。 许多人都在为价值定义而苦苦挣扎。 首先，有两种类型的质量：内在的和外在的。

• 内在质量与开发、测试和管理团队对产品的内部认知有关。 它通常用缺陷度量来说明，我们稍后会描述。
• 外在质量是最终用户感知到的产品质量。 产品如何满足他们的需求并满足期望。 这种外在品质的另一个术语是价值。

因此，重要的是要了解敏捷三角形中描述的质量是从开发的角度来看的内在或内部质量，而三角形中的价值实际上是外在质量的一种形式。 了解这种关系对于开发良好的敏捷度量很重要。

需要跟踪的 17 个关键敏捷指标

以下 17 个指标列表将最常用和历史悠久的敏捷指标与基于最近研究的新指标相结合。 这里的关键点是任何敏捷指标解决方案都应该是全面的。

仅仅依靠一两个并不能提供正在发生的事情的完整画面。 许多经理犯的最大错误是过分关注两个或三个，或者整个项目只关注一个指标。 一些组织只使用速度或燃尽图。

信不信由你，它发生了。 一个好的指标解决方案应该涵盖敏捷三角形的所有三个点。 这 17 个将为您提供执行此操作的工具以及更多功能。

阻塞时间

阻塞时间定义为特定用户故事（有时是任务）被阻塞的时间量。 解决障碍对于促进敏捷环境中的工作流程至关重要，该指标可以帮助衡量他们解决问题所需的时间。 阻滞剂应尽快解决。

阻塞时间的增加可能意味着用户故事没有正确分解，或者依赖于计划外的外部资源。 通过更仔细的用户故事分解、优先级和冲刺计划，可以减少阻塞时间。

业务势头

这里讨论的许多指标已经存在了很长一段时间。 大多数都集中在项目、团队或 WIP（进行中的工作）级别。 然而，随着技术更多地融入我们的日常生活，并且这些产品的市场变得超加速，组织正在寻求更复杂的指标，以识别市场趋势、衡量流程改进、预测竞争，并从本质上衡量敏捷性。 商业动力就是其中之一。 在这种情况下，动量可以表示为发布的总故事点乘以其时间线。

随着组织变得更加敏捷，每次发布都会获得动力。 周期时间往往会缩短，对交付的期望也会增加。 业务动量可用于市场时机，或作为特定产品线或程序健康状况的标志。 如果势头开始减弱，这向管理层表明特定市场开始发挥作用，需要开发新的产品线。 敏捷组织必须不断寻找新市场以保持竞争力。

代码覆盖率

代码覆盖率是测试期间实际执行了多少代码的度量。 这通常作为自动化测试策略的一部分进行检测和计算。 该指标应提供在每个测试阶段（单元、系统等）以及所有阶段的总数中执行的代码的总体百分比。

不应将代码覆盖率误用作产品测试效果的标志。 相反，该指标的目标是促进测试自动化和监控持续交付。 质量保证测量应该包括各种指标，其中最重要的是稍后讨论的缺陷发生率。

控制图

有时称为过程行为图或 Shewhart 图，控制图监控过程的性能以确定它是受控还是失控 - 取决于已设置的上限、下限和平均控制限制。

这些限制是通过估计样本数据的标准偏差，将该偏差乘以三，然后将其添加到平均值来创建上限，然后从平均值中减去它来创建下限来计算的。 图表的 Y 轴是特定样本中出现或问题的数量，而 X 轴枚举每个样本。 控制图起源于制造业，是一种质量控制形式，已经存在了近 100 年。

受六西格玛门徒欢迎，控制图可以衡量质量控制或其他制造过程的失败或成功。 虽然在敏捷世界中没有普及，但控制图可用于测量每次迭代或发布时发现的缺陷，以识别 QA 测试问题，或衡量一系列发布的周期时间，以确保它们在可接受的范围内。

累积流程图

累积流程图说明了随着时间的推移分配给团队的工作量，按类型划分。 其目的是监控整个系统中工作的流动情况。 在此图中，工作分为不同的类型，例如：待办事项、进行中和已完成。 它还可以分为需求、开发、测试等。 然而，它是分段的，累积流程图显示了每种工作类型的一条线，Y 轴和 X 轴上的工作项数量是时间的函数。

所有这些并行运行的线路都说明了良好的流程。 如果其中一条线急剧上升，或与另一条线交叉，这可能表明存在瓶颈。 实现良好的流程是看板背后的核心概念。 累积流程图有助于识别瓶颈以促进连续流动，并确保 WIP 在系统中的任何一点都不会失控。

周期

周期时间可以定义为从概念到完成制作软件版本所需的时间。 除了提前期和速度，周期时间是敏捷健康和敏捷转型成功的一个非常好的高级指标。 随着组织在其敏捷之旅中的进展，周期时间应逐渐减少，通常为六个月或更短。 周期时间的增加，尤其是在一两个版本中持续观察到的情况下，应该引起关注和审查。

史诗和发布燃尽

史诗和发布燃尽图类似于下面讨论的流行的冲刺燃尽图。 燃尽图说明了给定时间段内剩余的工作量，或者在这个例子中，对于特定的史诗。 在敏捷开发中，史诗是由较小的用户故事或工作块组成的较大的用户故事。

随着工作的完成，史诗中的用户故事数量逐渐减少，直到达到零。 这在必须达到里程碑以满足合同要求并向客户收费的情况下非常有用。 同样，发布燃尽图可以跟踪为特定发布提交的工作进度。 这可用于帮助确保按时交付或确定需要提前更改截止日期。

失败的部署

失败的部署会导致以下任一情况：

• 服务影响中断
• 未能满足客户期望，通常导致发布被拒绝。
• 严重影响产品的可用性、操作或用户体验。
• 导致回滚到以前的版本。

显然，失败的部署率（显示为总部署的百分比）应保持在最低水平。 该指标的任何峰值都应引起关注。 应审查变更率和缺陷发生率以找出根本原因。

交货时间

提前期衡量完成任务所需的时间，从创建到完成的那一刻。 简而言之，它确定完成工作需要多长时间。 这个指标在看板从业者中很受欢迎，它可以帮助确定效率，以更快地通过系统移动任务。 它还可以用作确定持续交付工作情况的高级指标。 交货时间、周期时间和速度可以一起使用，以提供交付绩效的整体视图。

净推荐值 (NPS)

净推荐值旨在帮助评估客户满意度。 它通常是根据通过调查获得的数据计算得出的。 目标是找出有多少客户会推荐您的产品。 从“是”选民中减去投“否”的受访者百分比以创建分数。

除了衡量客户满意度之外，净推荐值还可以帮助确定更愿意在未来发布的创新产品或技术上合作的客户。 这些客户可以成为竞争优势，因为他们的反馈和支持可以帮助公司在竞争之前将新产品推向市场。

质量情报

在文章的开头，我们讨论了敏捷三角形和质量在其中发挥的作用。 质量情报可以采取多种形式，但它通常由各种缺陷跟踪指标组成。 可以根据缺陷发生的地点和时间、频率和严重程度来监控缺陷。

最流行的一种是缺陷逃逸率，它是客户端发现的缺陷与发布中发现的缺陷总数的比率。 尽管无论如何发现大量缺陷都应该引起关注，但最好在客户发现之前发现它们。

冲刺燃尽

Sprint 燃尽图提供了对已完成工作以及给定 sprint 中仍有待完成的工作的每日度量。 它将完成的工作量与最初的估计进行比较。 由于敏捷开发的经验性质，燃尽图的价值非常有限。

尽管它很受欢迎，但许多敏捷教练正在不再像以前那样使用它。 它可以作为开发团队违背承诺的良好指南或状态点，但它应该与其他指标一起使用，以全面了解正在发生的事情。

吞吐量

每单位时间交付给客户的产品数量（工作项目的数量）称为吞吐量。 这可以每月、每季度、每个版本、迭代等进行测量。 该指标的价值在于它可用于确定在特定时间范围内可以交付多少软件。 它还可用于从团队和组织的角度跟踪交付的一致性。

历史数据的实证分析可用于预测交付绩效。 可用的历史数据越多，预测可能就越准确。 最关键的是，鉴于交付的功能功能的价值在财务方面得到了很好的理解，这个指标也可以用来预测收入。 为了使这个指标起作用，“完成”的定义必须明确。 只有交付给客户的软件才能满足此要求。

交付的价值

在文章的开头，我们讨论了价值如何由外在质量或最终用户对产品的感知构成。 产品如何影响客户的业务？ 良好的敏捷指标基于结果，在商业世界中，这通常转化为美元和美分。 正如我们将故事点分配给每个用户故事以作为估算其工作量的一种方式一样，我们也可以添加价值点作为相对衡量标准，以表明最终用户在完成工作后得到了什么。

一种方法是使用燃尽图来说明每个故事完成时累积的价值点数。 在创建验收标准时，可以根据客户的感知为每个故事或功能分配价值点。 客户在项目上的预期收入（或节省的钱）可以除以发布中的价值点总数。

例如，如果一个项目中有 200 个价值点，并且预计客户将获得 100 万美元的收入，那么每个价值点价值 5,000 美元。 每个故事的总和及其累积值可以在燃尽图中说明。 尽管该产品的实际影响在发布之前可能并不明显，但这种方法可以为管理层和客户提供令人信服的财务情报。

速度

速度可能是我们大多数人在被引入敏捷开发后听到的第一个指标。 虽然可以说是最流行的敏捷指标，但它也是最被滥用的。 Sprint 团队因游戏速度而臭名昭著，因为它非常依赖于报告他们的表现。 速度定义为每次迭代或冲刺中产生的软件数量。 这个数量通常表示为故事点，并且生成的软件必须是功能性生产就绪的代码片段。

团队经常通过操纵用户故事的大小和估计，或者通过水平分解工作而不是垂直分解工作，通过为数据库更改、前端工作、中间件等创建故事来提高速度。 消除对他人的依赖并因完成工作而获得荣誉。 这种方法的问题在于，这些类型的用户故事实际上是任务，尽管团队获得了荣誉，但客户的商业价值尚未交付。

可以通过使用许多其他指标作为相互制衡来防止游戏速度。 很多时候，组织仅依靠速度或一组非常小的指标而不是更大的测量套件来形成 PPM、计划和项目管理解决方案。

涡流（敏捷）

许多敏捷专家和项目经理都在努力解决的一个问题是“我们有多敏捷？” 事实上，寻找衡量敏捷性本身的答案一直是各地敏捷者的圣杯。 敏捷涡度是一种新的测量方法。 基于 10 多年的案例研究，敏捷涡度是通过一种称为扎根理论的复杂定性方法开发的。

使用一套全面的衡量标准，可以相互衡量市场和组织流程的敏捷性，以确定它们的漩涡度或它们的收敛点。 零涡度意味着组织的敏捷性与市场相匹配。 高涡度意味着市场的发展速度比您的组织或团队快得多，因此有很多工作要做。 下面的信息图通过漩涡思想实验展示了这种关系，以说明当今超加速的市场。

工作项年龄

一个工作项可以被定义为一个工作包、可用的特性，或者就像在大多数敏捷环境中一样，一个用户故事。 工作项一经构思，时钟就开始计时。 跟踪工作项的年龄，无论它们是在进行中还是在积压中，都可以帮助识别需求问题。

如果一个工作项似乎比它的亲属更老，因为它被从一个冲刺推到下一个冲刺，那么分解可能存在问题。 也许它需要重新定义或更好地理解？ 长期积压的工作项目可能需要剔除或重新定义。

持续的待办事项梳理对于 sprint 计划和优先级排序至关重要。 积压中越来越多的老化需求可能意味着需求的开发和分解方式存在问题。 糟糕的需求管理是敏捷转型失败的主要原因之一。

写得不好的需求会使优先级和估计变得极其困难，导致失控的技术债务、低功能利用率和财务损失。 开发易于理解的、优先考虑的、高价值的需求在很大程度上是一种艺术形式，即使是最优秀的敏捷者也很难理解。 事实上，它可以说是敏捷转型成功的最大障碍之一。

结论

在本文中，我们建立了敏捷指标的基础、对综合解决方案的需求以及构建解决方案的 17 条建议。 无论您使用讨论的所有测量值还是仅使用一个子集，任何解决方案都必须考虑数据的受众。 一些指标，例如速度，最好保留在 Scrum 团队中。 其他指标，如敏捷漩涡和业务动力，分别是为执行或产品管理设计的。

始终确保完全理解和准确传达指标的含义，并遵循数据的导向。 推动和支持良好指标的一种方法是使用健壮的敏捷框架。