黑马前端气温案例_黑马指标使用吞吐量的案例

黑马前端气温案例

I’ve not come across many teams that use, let alone know that much about throughput. For the most part, velocity rules the roost when it comes to capacity planning, however, throughput can be just as useful (and you don’t need to estimate with story points… or at all… if that’s your thing.)

我没有遇到很多使用过的团队，更不用说对吞吐量有太多了解了。 在大多数情况下，速度是容量规划的关键，但是，吞吐量同样有用(并且您不需要估算故事点…或根本不需要……如果那是您的事。)

速度与吞吐量 (Velocity vs Throughput)

Similar to how Fahrenheit and Celsius both measure temperature, throughput and velocity are different measures for a team’s capacity.

类似于华氏温度和摄氏温度如何测量温度，吞吐量和速度，这是衡量团队能力的不同方法。

Velocity tells us capacity via the amount of completed effort (as estimated in story points). Throughput tells us capacity via the amount of completed tasks.

速度通过完成的工作量(以故事点数估算)告诉我们能力。 吞吐量通过完成的任务量告诉我们容量。

Both are used in pretty much the same way, e.g. during sprint planning, the team will look back at their average (or their average range) of completed tickets to get a feel for roughly how many they can pull into the next sprint.

两者的使用方式几乎相同，例如，在冲刺计划期间，团队将回顾其已完成门票的平均(或平均范围)，以大致了解可以拉入下一个冲刺的数量。

速度问题 (The problem with velocity)

The biggest issue I usually encounter with velocity, is that it is based off an arbitrary measurement system (story points) that has a tendency to cause confusion. This confusion generates debate and discussion around “frequently asked questions” such as “Shouldn’t we estimate spikes and bugs? Otherwise it’s work that won’t show in our velocity.” or “Shouldn’t we re-estimate the story points of unfinished stories? Otherwise it feels like the work we did doesn’t matter.” or “What do you mean a story point equates to effort? Effort means what?” While normally I would consider debate and discussion a good thing, we need to be mindful of the fact that dwelling on how to estimate and getting lost in velocity is time not spent delivering value to our customer.

我通常遇到的最大问题是速度是基于任意测量系统(理论点)的，这容易引起混淆。 这种困惑引发了围绕“常见问题”(例如“我们不应该估计峰值和错误吗？ 否则，这项工作就不会以我们的速度展现出来。” 还是“我们不应该重新估计未完成故事的故事点吗？ 否则，感觉就像我们所做的工作没关系。” 或“故事点等于努力是什么意思？ 努力意味着什么？” 通常，我认为辩论和讨论是一件好事，但我们需要谨记这样一个事实，即专注于如何估计和迷失速度是没有花时间为客户提供价值。

When it comes to process we want to be as lean as possible. By simply tracking the completed tasks (regardless of type), throughput can eliminate confusion and complications that are so common with velocity and story pointing. That being said, throughput is also not perfect.

当涉及到流程时，我们希望尽可能精简。 通过简单地跟踪已完成的任务(与类型无关)，吞吐量可以消除速度和故事指向中常见的混乱和复杂情况。 话虽如此，吞吐量也不是完美的。

使用吞吐量 (Using Throughput)

Perhaps throughput’s main “quirk” is that while effort is inherently captured within the number of completed tasks, it is not explicit and this can be misleading.

吞吐量的主要“怪癖”也许是，尽管内在地将精力集中在已完成任务的数量之内，但它并不明确，这可能会产生误导。

Task count might be a predictable indicator in an environment where work items are somewhat homogenous or repetitive, like number of car doors fitted or turkey sandwiches packed, but when we are not certain about the effort involved in each individual task we cannot be certain about the overall effort that throughput represents.

在工作项目有些同质或重复的环境中(例如安装的车门数量或包装的火鸡肉三明治)，任务计数可能是可预测的指标，但是当我们不确定每个任务所涉及的工作量时，我们就无法确定吞吐量代表的总体努力。

Why is this a problem? Imagine if your team completed only 5 tasks in sprint A, and then 20 tasks in sprint B. This looks like quite a large variation in capacity on the face of things. However if you knew that the 5 tasks were actually all rather large, and the 20 were mostly small, then actually they might end up equating around the same amount of overall effort. How then are you supposed to know how many tickets to plan for?

为什么这是个问题？ 想象一下，如果您的团队在sprint中仅完成了5个任务，然后在sprint B中完成了20个任务。从表面上看，这似乎是功能上的很大差异。 但是，如果您知道这5个任务实际上都是相当大的，而20个任务几乎都是很小的，那么实际上它们最终可能会花费大约相同的总精力。 那您应该如何知道要计划多少张票？

When using throughput in a complex and therefore uncertain environment, it can be particularly helpful to try to minimize the variation of effort in your tasks.

在复杂且不确定的环境中使用吞吐量时，尝试最大程度地减少工作量的变化可能特别有帮助。

The best way to do this is to continue estimating — but you don’t need to use story points. It can be t-shirt sizes, animals or any other relative scale. Estimating will help your team break up the larger work items that could otherwise increase your variance. However, this is not something that should be considered as ‘extra work’ just because you use throughput. I would recommend estimating regardless of whether you use velocity or throughput, not only for consistency but for reducing (known) risk.

最好的方法是继续估算-但您不需要使用故事点。 它可以是T恤尺寸，动物或任何其他相对比例。 估算将帮助您的团队分解较大的工作项目，否则可能会增加差异。 但是，这并不是仅仅因为您使用吞吐量就应该被视为“额外工作”。 无论是使用速度还是通过吞吐量，我都建议进行估计，这不仅是为了保持一致性，而且是为了降低(已知)风险。

Note: Estimating and breaking down work items is not something to get obsessed with. For the most part your team is likely to find a rhythm, i.e. a standard task size that it tends to break most stories into. But even then sizing is an estimation activity — you’re probably going to be wrong more than you’d like. You’re never going to be perfect in this, so don’t try too hard.

注意：估算和分解工作项并不是一件容易的事。 在大多数情况下，您的团队很可能会发现一种节奏，即一种标准的任务规模，倾向于将大多数故事分解为节奏。 但是，即使如此，调整大小仍是一项估算活动-您可能会犯错的程度超出了您的期望。 您永远不会在这方面做到完美，所以不要太努力。

Remember that peaks and troughs are normal in complex environments. We just want to try to keep the variation between them down as much as is reasonably possible and focus instead on the average (or average range) that starts to emerge rather than individual sprint throughput (like that 5 or 20).

请记住，在复杂的环境中峰谷是正常现象。 我们只想尝试尽可能地减小它们之间的差异，而将注意力集中在开始出现的平均值(或平均范围)上，而不是单独的sprint吞吐量(例如5或20)。

Unlike velocity that relies on estimating in story points, even if you don’t estimate at all, tracking throughput over a period of time will still reveal trends that can inform your team and stakeholders of your probably capacity (as we will see below).

与依赖于故事点估计的速度不同，即使您根本不估计，跟踪一段时间内的吞吐量仍会显示出趋势，这些趋势可以使您的团队和利益相关者了解您的能力(如下所示)。

如果有时间，请查看您的方差系数。 (If you’ve time, look at your coefficient of variance.)

Without making this too complicated and time consuming— the coefficient of variance is essentially the average variance of data points around the mean. Very simply, the higher this number, the higher your variance, and the less ‘reliable’ your throughput is likely to be as an indicator for capacity. There is no ‘magic’ number here, however I very loosely would say that the higher your average and the higher your CoV the more likely a little investigation could be warranted. For example, if your average throughput is 9, and your coefficient of variance is 100%, that means that your average range is 0–18 (which you might consider as quite significant).

不必使它变得过于复杂和耗时-方差系数本质上是平均值附近数据点的平均方差。 简而言之，此数字越高，您的差异就越大，吞吐量就越不可能成为可靠​​性指标。 这里没有“不可思议”的数字，但是我很松散地说，您的平均值越高，您的CoV越高，就越有可能需要进行一点调查。 例如，如果您的平均吞吐量是9，而方差系数是100％，则意味着您的平均范围是0–18(您可能会认为这是非常重要的)。

使用吞吐量的示例 (Examples of using throughput)

Below I’ve shared a few graphs of how throughput can still be used for many of the same things you might traditionally use velocity and story points for. This data is taken from a real team that doesn’t estimate, yet as mentioned above, hopefully these visuals show that by tracking throughput we can still obtain valuable insights to start discussions.

在下面，我分享了一些图表，这些图表显示了吞吐量如何仍可以用于许多您可能传统上使用速度和故事点的事物。 该数据来自未估算的真实团队，但如上所述，希望这些视觉效果表明，通过跟踪吞吐量，我们仍然可以获得有价值的见解以开始讨论。

A typical line graph showing the distribution of throughput over the course of 17 sprints reveals:

一个典型的线形图显示了17个冲刺过程中的吞吐量分布，该线形图显示：

• The emerging average is about 9 tickets, which can be used as a starting point for planning.
  新兴平均水平约为9张门票，可以用作计划的起点。
• However their CoV, or average throughput range, is around 5–13 tickets, which probably could be tightened a bit.
  但是，它们的CoV或平均吞吐量范围约为5–13张票，可能会收紧一点。
• We do notice a trend of increasing throughput, however whether this is due to a larger number of smaller tasks in the sprints, or simply more work/ effort being completed is something that would need to be investigated.
  我们确实注意到吞吐量增加的趋势，但是，这是由于sprint中的大量较小任务造成的，还是仅仅是完成更多工作/努力所导致的，需要进行调查。

You can also go further and retrieve stats on how many unplanned vs planned tickets make up the throughput. In this graph we can clearly see scope creep in nearly every single sprint — 31% on average. This again might be something to look into.

您还可以走得更远，以获取有关构成吞吐量的计划外票与计划票的统计信息。 在此图中，我们可以清楚地看到几乎每个单冲刺的范围都在蠕变-平均为31％。 这可能再次值得关注。

Another graph that looks at the ratio of throughput (completed tickets) vs not completed tickets essentially shows the extent of over-commitment. This team is, on average, only completing about 45% of what they thought they would. This could be due to not understanding the effort involved and again might need to be checked out.

另一个查看吞吐量(已完成票证)与未完成票证之比的图表实质上显示了超额承诺的程度。 该团队平均只能完成他们认为的目标的45％。 这可能是由于不了解所涉及的工作，因此可能需要再次检查。

吞吐量是有帮助的，但不是目标。 (Throughput is helpful, but not the goal.)

Because velocity is a product of story pointing and story point itself is frequently misunderstood — you might want to choose your battles. You can either try to invest more time in training and gaining experience in the use of story points, but as long as you feel you gave it a good go, there is no shame in cutting your losses and trying throughput. While not perfect, it can make your development process leaner by cutting out some unnecessary discussion and worry. However, take note that regardless of how you measure it, capacity is a measure of output not outcomes.

因为速度是故事指向的产物，而且故事指向本身经常被误解-您可能希望选择自己的战斗。 您可以尝试花费更多的时间在培训上，并在使用故事点上获得经验，但是只要您觉得自己做得很好，就可以减少损失并尝试提高吞吐量。 尽管不完美，但它可以消除不必要的讨论和烦恼，从而使您的开发过程更加精简。 但是，请注意，无论如何衡量，能力都是衡量产出而不是结果的手段。

翻译自: https://medium.com/swlh/the-dark-horse-metric-a-case-for-using-throughput-c486094913a0

黑马前端气温案例