敏捷度量：可预测性的敏捷健康指标
主导使用敏捷指标来展示我们的流程改进努力的结果，并确定需要进一步改进的领域。我们有许多内部文件描述了我们与客户分享的方法，但对我的惊喜，似乎我们从未留下过它。这是我们经常从中开始的敏捷度量的高级视图。
在决定测量什么时，开始的地方是一个目标。首先，问问自己你想要什么结果，你的目标。然后考虑需要什么来实现这些目标。最后，什么敏捷度量表明您是否拥有您所需要的。你可能会认为这是目标质疑指标方法。
我们的客户倾向于关心可预测性，早期投资回报率，提高质量或更低的成本。可预测性似乎是至关重要的。他们希望团队能够善于制作和保持承诺，一致地在每个Sprint末尾提供工作，测试的，经过测试的修复代码。一个不可预测的团队不是“坏” - 但他们不是可预测的。如果没有稳定的可预测团队，我们就无法具有稳定的可预测程序，特别是当团队之间存在多种依赖项时。
这篇文章侧重于敏捷指标可预测性。然后，目标是：
团队可以计划，协调和提供足够的可预测，以发出释放级别承诺。
以下是我们的分析方法;的团队:
- 提供每个冲刺的功能？
- 经常提供工作，测试，修复代码？
- 有一切预期每个冲刺都能执行工作吗？
- 有信心，他们将提供预期的释放功能吗？
- 团队是否建立了稳定的速度？
我们通过以下敏捷度量回答这些问题：
敏捷度量:故事和点完成率
- 交付的承诺故事数/承诺故事数
- 提供的承诺点数/承诺点数
此度量标准可帮助团队在估算和冲刺规划方面变得可预测。它鼓励较小的故事和更多努力在冲刺之前准备工作。我们希望看到交付的积分和故事，以占承诺的10％。
敏捷度量：速度和吞吐量变化
- 近期速度/平均速度
- 最近吞吐量/平均吞吐量
此度量标准帮助团队在其表现中变得稳定。这将鼓励管理在Sprint之前的风险和依赖性，而不是在Sprint内征服。我们喜欢看到最近的速度在平均水平的20％内。我们还希望看到速度随时间的标准偏差减少。
敏捷度量:交货期
- WIP到吞吐率比
构建大量未测试代码通常会增加与修复缺陷相关的成本和时间。这反过来又增加了与版本控制、依赖关系管理和交付可工作的、经过测试的、修正的代码相关的成本和挑战。我们的目标是改善交货期和频繁交付。从“准备好”到“交付”，一个团队的活跃吞吐量不应该超过4周。越少越好。我们希望在两周或更短的时间内看到。
敏捷度量：团队成员可用性比率
- Headcount可用/ Headcount预期
当计划的团队成员不在时，我们需要一个指示。稳定性对于团队能够做出和保持发布承诺至关重要。当人们被拉到多个团队中时——或者不能按照计划使用时——团队不太可能能够实现可预测的交付。我们希望这在计划的10%之内。
敏捷度量：释放信心
使用团队的洞察力和性能记录来评估团队对发布目标能够实现的信心。这个指标对于计划和承诺的目的是有用的。“释放信心”是一种共识投票，其中1人表示没有信心，5人表示非常有信心。如果一个团队有严重的依赖关系，他们应该包括处理依赖关系的团队的敏捷项目经理的投票。如果团队缺少一项技能或者一个角色没有被填补，团队应该考虑对发布成功可能产生的影响。用发布燃耗来支持这个指标。
其他敏捷度量
这只是我们用于预测性的敏捷度量的味道。我们还使用质量指标，如构建频率，破碎的构建，代码覆盖，缺陷率或技术债务。同样，对于产品所有者来说，我们对主要计划的东西感兴趣，剩余功能，发布的功能，发布周期的大小等等。对于价值而言，我们对数量的东西感兴趣。
负责任地使用敏捷度量可以为整个组织提供洞察，以理解组织满足期望的能力。这些敏捷度量有助于建立对团队各自能力的共享理解，并指导改进工作。
评论（10）
戴夫斑点
你能举例说明在制品和吞吐量比是如何计算的吗?谢谢。
嘿戴夫。谢谢你的问题。度量标准在纸上很简单，但将它们放入实践需要一些思想。你必须随着时间的推移改变它们。
我们在这里显然谈论小的法律，所以你问题的简单答案可能是：
提前时间= WIP /吞吐量
开发周期= 2个故事/每周5个故事= 0.4周
牵长时间=每小时20个故事点/ 20个故事点= 1冲刺
对于迭代过程，吞吐量是平均速度（对于迭代时间的单位），WIP是尚未传递的故事中的点数。替代地，您可以使用一系列故事：平均，我们每一个周提供多少个故事，以及我们开始的故事，但尚未交付？
您的具体情况会影响您使用此度量的方式，并记住我们测量以获取信息，以便我们可以做出明智的改进 - 不适合奖励或作为一些绝对目标。我会给一些例子......
假设我们在4个故事中的冲刺期间有一个有8个人的储备速溶了8人，而且没有完成，没有转移到下一个冲刺和16个故事中的Sprint Backlog和16个故事。这支球队的平均速度doesn’t need this metric to inform them about their in-sprint WIP.
对于一个能够频繁部署到生产环境的非常成熟的团队，您可能会对未部署的工作量(将未部署的工作作为您的WIP，您的交付定义)更感兴趣。如果我部署的事例的吞吐量是每周5个，但是我有30个正在处理的事例，也就是说，尚未交付(而且趋势是稳定的或恶化的)，那么也许我应该研究一下如何减少WIP，增加吞吐量，缩短交付时间。
However, consider a struggling team in which test can’t keep up with development — perhaps QA can do 10 stories/week but dev can do 11. At the end of week 1 they have 1 untested story and a throughput of 10 stories/week (fully tested) — they have a little WIP hanging out compared to their throughput. But by the end of week 10 that carryover has grown to 10 and their throughput (through QA) is also still 10. The trend was bad from the start, which I could see from week 2. That’s why I always also look at the trends of these metrics, not just the absolute number. If week 10 is the end of the release and we have 10 stories not tested, we could catch up pretty quickly if we stop developing for a bit, or increase swarming, or change how we test, or have increased quality, or whatever. But if I’ve got 4 weeks worth of un-tested stuff, then I’ve got a much bigger problem.
在这种情况下，我对交付的定义可能只是测试故事，尚未包装成释放，或者尚未部署到生产中。一旦该团队解决了当前问题并频繁地部署到生产，他们将需要更改此度量标准。
我在迭代团队中看到了同样的开发出QA情况。在为迭代团队执行数学时，您需要知道该团队是否正在计算其速度的未经测试的故事。他们/不应该/，但如果你要重新使用他们的测量，他们/应该做的/应该做/是无关紧要的。他们/实际计算/事项是什么。
这有帮助吗？
戴夫斑点
是的，谢谢
Paul Booos（@Paul_Boos）
这套剩下一些重要的指标;这些指标仅与正在生产的软件的实际可靠性一样好。与上述可靠性相关的唯一度量是共识投票，即主观。虽然这有点有用，但我希望一支球队正在使用客观措施来基准这一点，如果原因如此，那么可以使用这些，而不是一个主观的团队衡量达成的共识。
测试覆盖范围和在该测试覆盖范围内的测试数量（以及测试的关键性）将在那里迈出一步。了解循环复杂性将为未来问题提供有用的指标。
I’d hypothesize that without these (and probably others, this is only about 5 minutes of thought) that any predictability metric would be meaningless, In fact, I imagine that one could find some form of ratio of features being produced to some aggregate of these code health metrics that could be monitored like an EKG, the periodicity of these could be monitored to determine when to release.
保罗
安德鲁芙乐
嗨,保罗。非常感谢你的阅读和评论。我荣幸!
关于可靠性，我假设你的意思是，例如，软件在不破坏数据或崩溃的情况下做它应该做的事情，它有足够的质量。在我的第二至最后一段中，我陈述了对质量指标的需求。
Regarding your premise that “these metrics are only as good as the actual reliability of the software being produced”: If my team cannot meet their sprint commitments because they don’t have a stable team, or they get interrupted, or they are accepting ambiguous work into the sprint, or they are writing poor quality (unreliable) software, then the team isn’t going to be predictable and the project isn’t going to be predictable. These metrics will help us see that. These metrics in this post are about project predictability. That’s the value of these metrics, particularly in a context in which teams aren’t yet where they should be. If you have well running agile organizations with predictable teams, then, no, these metrics wouldn’t be useful. They are incredibly useful where you don’t have that.
我很惊讶你说发布信任共识投票与(软件)可靠性有关。当我向一个组织介绍这个指标时，我解释说，这是关于他们对可预见地满足发布日期或项目承诺的能力的信心。告知这一点的一些客观度量是故事完成率(团队能否满足sprint承诺)、团队成员可用性(人们是否在移动)、速度变化、速度图，以及发布和sprint燃尽图。这启发了我们的直觉。其他的东西也会影响我们的直觉。例如，我可能会认为我们的一个关键团队成员有潜逃风险。我们阅读这些客观的图表，解释它们，考虑我们知道、怀疑或感觉的其他事情，然后打一个电话——我们会成功吗?你的男人会告诉你是/可能或不可能。这就是为什么我们要包括客观测量和问主观问题。
也许我错过了你的观点，保罗？
安德鲁
Paul Booos（@Paul_Boos）
我看到我错过了这个词，并把这一词作为在准备释放时被问到的东西，而不是听起来像发布规划的东西。无论如何，你可以将其归因于误解（而不是足够的咖啡因）。
无论如何，我的要点是，如果您可以将它们绑定到质量指标，我认为您可以消除这些项目可预测性指标，并让质量指标决定您的发布时;除非你工作真的很小，否则不会有效。批次大小越大，可预测性度量的需要越多，并且从质量指标都有更多的去耦的任何可预测性度量。
干杯，
保罗
啊，是的，我现在完全得到了误解。右...通过发布承诺信心，我谈论可能是几个月的计划发布。是的，我在谈论刚刚开始过渡到更自适应的规划方法的大型组织，仍然有大量的释放，并且尚未有能力经常以小批次测试和释放。
再次感谢讨论，保罗。