摘要：敏捷开发指标提供在软件开发生命周期的不同阶段对生产力的洞察。这有助于评估产品的质量和跟踪团队的表现。
指标是一个敏感的话题。
一方面，我们都参与过不跟踪任何数据的项目，很难分辨我们是否按计划发布，或者随着项目进展而提高效率。另一方面，许多人不幸参与过将统计数据用作武器的项目，以进行团队间比拼或证明周末强制加班的合理性。因此，大多数团队与指标有着爱恨交织的关系也就不足为奇了。
然而，不一定需要如此。跟踪和分享健全的敏捷指标可以减少混乱，并且点亮团队在整个开发过程中的进度（和挫折）。具体方法如下。
了解您的业务
“完成”只能讲述一半故事。重点在于，在恰当时间为正确的市场打造合适的产品。在项目群中全程保持正轨，意味着在整个过程中收集和分析相关数据。任何敏捷项目群都离不开跟踪业务指标和敏捷指标。业务指标侧重于解决方案是否满足市场需求，敏捷指标则衡量开发过程的各个方面。
“项目群的业务指标应扎根于其路线图。”
对于路线图中的每项计划，都要包括几个与项目群目标对应的关键绩效指标 (KPI)。此外，还应包括每一产品要求的成功标准，例如最终用户的采用率或自动化测试涵盖的代码百分比。这些成功标准将馈入到项目群的敏捷开发指标中。另外，团队掌握的技能越多，就越能适应和发展。
如何使用敏捷 KPI 指标来优化交付
冲刺燃尽图
Scrum 团队将开发组织成设有时限的冲刺。在冲刺开始时，团队会预测他们在冲刺期间可以完成多少工作。然后，使用冲刺燃尽报告来跟踪整个冲刺期间的工作完成情况。用 x 轴表示时间，y 轴表示剩余待完成工作量，以故事点或小时数来衡量。目标是在冲刺结束前完成所有预测的工作。
团队一贯达到预测是其组织中最有说服力的敏捷性广告。但是，不要让这诱使您捏造数据，在工作真正完成之前宣布完工。从短期来看或许貌似不错，但从长远来看，它只会阻碍学习和进步。
- 团队提前完成每一冲刺，因为他们没有被委派足够的工作。
- 团队在每次冲刺与预测不符，因为他们被委派了太多工作。
- 燃尽线急剧下坠，而不是更为缓和地燃尽，因为工作没有分解成细小的碎片。
- 产品负责人在冲刺过程中添加或更改范围。
长篇故事和版本燃尽图
与冲刺燃尽图相比，长篇故事和发布（或版本）燃尽图可以跟踪更庞大的工作，并指导 Scrum 和看板团队的开发。由于冲刺（对于 Scrum 团队而言）可能包含来自多个长篇故事和版本的工作，因此同时跟踪单个冲刺以及长篇故事和版本的进度非常重要。
“范围蔓延”是在一个先前定义的项目中注入更多要求。例如，如果团队正在为公司交付一个新网站，那么范围蔓延就是在起草最初要求之后索要新的功能。虽然在冲刺期间容忍范围蔓延是不良的做法，但长篇故事和版本中的范围变化是敏捷开发的自然结果。在团队推进项目的过程中，产品负责人可能会根据他们了解的信息来决定承接或移除工作。长篇故事和版本燃尽图可让每个人知道工作在长篇故事和版本内的起伏。
- 长篇故事或版本预测不随团队完成工作而更新。
- 经过几次迭代后没有取得进步。
- 慢性范围蔓延，可能表明产品负责人不完全了解工作内容正在尝试解决的问题。
- 范围蔓延速度超过团队可吸收的速度。
- 在长篇故事发展过程中，团队没有交出增量版本。
速度
速度是 Scrum 团队在冲刺期间完成的平均工作量，以故事点数或小时数来衡量，对于预测非常有用。产品负责人可以使用速度来预测团队处理待办事项的速度，因为报告可跟踪多次迭代中预测和完成的工作，迭代次数越多，预测准确性就越高。
假设产品负责人想要完成待办事项列表中的 500 个故事点。我们知道，开发团队在每次迭代中通常完成 50 个故事点。产品负责人可以合理假设团队需要 10 次迭代（允许些许误差）才能完成所需的工作。
重要的是监控速度如何随时间推移而演变。随着团队优化关系和工作流程，新团队有望在速度方面有所提升。现有团队可以跟踪他们的速度，确保在一段时间内保持一致的绩效，也可确认特定流程变更是否取得了改进。平均速度下降通常表明团队开发过程的某一部分变得效率低下，应当在下一次回顾中提出。
速度长时间起伏不定时，请务必重新审视团队的估算实践。在团队回顾期间提出以下问题：
- 在估算这项工作时，是否没有考虑到任何未预见的开发挑战？怎样才能更好地分解工作来发现其中的一些挑战？
- 是否有外部业务压力将团队推向极限？坚持最佳开发实践是否会因此而受影响？
- 作为一个团队，我们是否太过热衷于预测冲刺？
团队速度各不相同。如果团队 A 的速度为 50，团队 B 的速度为 75，这并不表示队伍 B 的产出更高。每个团队的估算文化独一无二，其速度也是如此。抵制住在团队间比较速度的诱惑。根据每个团队对故事点的独特解读，衡量工作的投入和产出。
控制图
控制图侧重于单个问题的周期时间，即从“进行中”到“已完成”所经历的总时间。周期时间较短的团队可能具有更高的产出，而在许多事务上周期时间一致的团队在工作交付方面更具可预测性。虽然周期时间是看板团队的主要指标，但 Scrum 团队也可从优化的周期时间获益。
衡量周期时间是改进团队流程的一种有效而灵活的方法，因为变化结果几乎可以立即辨别，因此他们能够即可做出进一步的调整。最终目标是保持一致且较短的周期时间，无论工作类型如何（新功能、技术债务等）。
控制图起初可能显得变幻无常。不要太过在意每个异常值，而应寻找趋势。以下是需要留意的两个方面：
- 增加周期时间 – 增加周期时间会削弱团队来之不易的敏捷性。在团队回顾期间，花些时间了解增长情况。一个例外：如果团队对完成的定义已经扩大，周期时间可能也会扩大。
- 周期时间不定 – 目标是让故事点值相似的工作项具有一致的周期时间。在控制图中筛选各个故事点值，以检查一致性。如果小故事点值和大故事点值的周期时间不定，请花些时间在回顾中检查失误并改进未来的估算。
累积流量图
累积流程图应当从左到右看起是平滑的。任何一种颜色有气泡或间隙都表示缺陷和瓶颈，因此当您看到气泡或间隙时，请寻找方法来平滑图表上的色条。
- 阻塞问题会造成流程的某些部分出现资源大量富余，而在其他部分出现资源短缺。
- 待办事项列表随时间推移不加遏制地扩大。这源自于产品负责人没有关闭过时或优先级太低未能解决的事务。
更多指标
良好的指标不限于上文讨论的报告。例如，质量是敏捷团队的重要指标，也有许多适用于敏捷开发的传统指标：
- 发现了多少个缺陷：
- 开发过程中？
- 向客户发布之后？
- 来自团队之外的人？
- 有多少缺陷推迟到将来的版本？
- 传入的客户支持请求有多少？
- 自动化测试覆盖率是多少？
敏捷团队还应考虑发布频率和交付速度。在每个冲刺结束时，团队应将软件发布到生产环境中。实际发生的频率是多少？是否交付了大多数发布版本？同样，团队需要多长时间才能将紧急修复发布到生产中？发布对团队来说比较容易，还是需要英雄事迹？
在上下文中寻找洞察信息
洞察信息是团队在必要时访问指标的绝佳工具：冲刺规划期间、每日短会核查时，或交付优化过程中。您可以在 Jira 的看板、待办事项列表和部署视图的右上角找到洞察信息。
洞察信息提供以下指标的直观快照：
- 冲刺进度
- 事务类型详细信息
- 冲刺承诺
- 部署频率
- 周期时间
使用这些指标来不断优化团队绩效。详细了解洞察信息。
总结...
敏捷指标和 KPI 只是团队文化建设的一个部分。它们提供对团队绩效的定量洞察，并为团队提供可衡量的目标。尽管它们很重要，但不要沉迷其中。在回顾期间听取团队的反馈，对于提高整个团队的信任、产品的质量和整个发布过程的开发速度来说同样重要。使用定量和定性反馈来推动变革。
相关资源
