敏捷估算 视频_敏捷估算您回答的所有问题

敏捷估算 视频

I’ve had a few people asking questions about estimation when doing agile software development so I decided I would write down some ideas in the hope that others may find it helpful.

我有几个人在进行敏捷软件开发时询问有关估计的问题，所以我决定写下一些想法，希望其他人会发现它对您有所帮助。

为什么？ (Why?)

Firstly, there are many who argue that estimation is not a good practice to apply in software development since it often doesn’t end up affecting prioritisation, moves the focus away from iteration, and is essentially guesswork applied to unpredictable and non-repetitive work and more. The key point is that not only does estimation not offer a good return on investment but that by doing it, the team shifts the focus away from better practices. Therefore, the very first question to ask is, “should we actually be estimating?”

首先，有许多人认为估算不是在软件开发中应用的好方法，因为估算通常不会最终影响优先级，将重点从迭代中移开，并且本质上是将猜测工作应用于不可预测和非重复的工作，并且更多。 关键在于，不仅估算不能提供良好的投资回报，而且通过这样做，团队将重点从更好的实践中转移了出来。 因此，第一个要问的问题是：“我们实际上应该进行估算吗？”

Although the answer to this question may often be “no”, the perceived need for it may be too high in your organisation to not do it, or simply not a battle that you want to fight. If you do decide to use estimation, the key is to ensure the process is as valuable as possible. To understand that, let’s examine what parts of estimation are less valuable or not valuable at all.

尽管对这个问题的答案通常是“否”，但您认为组织中对此问题的需求过高而无法做到，或者根本就不是您想打的仗。 如果您决定使用估算，则关键是确保过程尽可能有价值。 为了理解这一点，让我们检查一下估计的哪些部分价值不高或根本没有价值。

• Not valuable: time spent estimating things that never get done. Time spent estimating things that are less likely to get done (a long way in the future, or are extremely low priority) is wasteful.

  没有价值：花费时间来评估无法完成的事情。 花费时间估计不太可能完成的事情(在未来很长的时间，或者优先级极低)，这是浪费时间。

• Not valuable: Time spent arguing about a number. There are some valuable parts of the estimation discussion, but the part where people are just debating about numbers, and not clarifying scope or understanding, is just wasteful.

  没有价值：花时间讨论数字。 估算讨论中有一些有价值的部分，但是人们只是在争论数字而不澄清范围或理解的那部分只是浪费。

Ok, but what is valuable?

好的，但是什么有价值呢？

• Valuable: Refining, clarifying and getting a common understanding of the scope of a piece of work (that is likely to be done).

  有价值：完善 ，澄清并获得对工作范围(可能会完成)的共识。

• Valuable: Uncovering that a piece of work is too big and then splitting it up into smaller increments, each of which delivers customer or business value. “Too big” is something that gets refined over time, and initially starts at “bigger than one sprint” and slowly reduces to “small enough that we don’t have wild variation when implementing stories of that size” and ideally reduces to “all our stories are roughly the same size when we implement them”.

  有价值：发现一件作品太大，然后将其分成较小的增量，每个增量都能带来客户或业务价值。 “太大”是指随着时间的流逝而逐渐完善的东西，最初从“大于一个冲刺”开始，然后逐渐减小为“足够小，以至于在实现该大小的故事时我们不会产生疯狂的变化”，理想情况下，减小为“全部”当我们执行它们时，我们的故事大小大致相同。”

• Valuable: Providing sizing information that affects the priority of work, and hence what work can be deferred.

  有价值：提供影响工作优先级的大小信息，从而影响到哪些工作可以推迟。

But what about other reasons? Well there are other reasons that people use to argue for estimation, but whether or not they add value is less clear:

但是其他原因呢？ 人们还有其他理由争辩估计，但是他们是否增加价值还不清楚：

• Debatable: Planning the timing of a roadmap or releases. Unfortunately doing this often shifts the focus away from iteration. That is, the more the business focuses on dates and deadlines of features, the less likely they are to iterate over those features (return to those features and refine them) as doing that affects future deadlines that have been set.

  有争议的：规划路线图或发布的时间。 不幸的是，这样做通常会使焦点从迭代转移开。 也就是说，业务越关注功能的日期和截止日期，就越不可能迭代这些功能(返回并完善这些功能)，因为这样做会影响已设置的未来截止时间。

• Debatable: Determining how much should go in a sprint. Does this give us a lot? I’ve seen many places where teams just keep working and finish as much as they can in a sprint, regardless of how much they forecast could be done in the sprint. Also, ideas like Kanban don’t even have a timeboxed time.

  值得商：的：确定短跑应该走多少。 这会给我们很多吗？ 我已经看到了很多地方，团队只是在冲刺中尽力而为地保持工作并完成尽可能多的任务，而不管他们预测在冲刺中可以完成多少任务。 同样，看板之类的想法甚至没有时间限制。

Therefore if you decide to estimate, it is important to focus on the value-add parts of the process.

因此，如果您决定进行估算，那么将重点放在流程的增值部分上就很重要。

什么时候？ (When?)

So now, understanding what is valuable and not valuable about estimation, when do we actually estimate? Should we estimate things in the current sprint, things one sprint ahead, the whole backlog?

因此，现在，了解估算的价值是什么，而不是有价值，我们什么时候才能真正估算？ 我们是否应该估计当前冲刺中的情况，向前冲刺的情况以及整个待办事项？

There is a general concept usually applied: “Boulders, rocks, pebbles”. The idea is that things that are a long way in the future (therefore less likely to be worked on), should be left as a boulder size estimate — a larger and unrefined estimate since you don’t want to spend much time on it. Things that are not as far in the future, should be estimated at rock sizes. And things that will be done (current sprint or so), should be well defined and understood, and hence estimated at the size of a pebble. Distant future work should not be refined to pebble level of estimates, and boulders shouldn’t be attempted in a current sprint because the work is unlikely to be clearly understood.

通常有一个通用的概念：“巨石，岩石，鹅卵石”。 这个想法是，将来还有很长一段路要走(因此不太可能进行处理)，应将其作为巨石大小估算值使用-较大且未经改进的估算值，因为您不想花很多时间在上面。 未来的事情应该以岩石大小来估算。 并且将要进行的操作(当前的sprint左右)应该得到很好的定义和理解，并因此根据小卵石的大小进行估算。 不应将遥远的将来的工作细化到估计的小数目，并且不应在当前的冲刺中尝试巨石，因为不太可能清楚地理解工作。

什么？ (What?)

So what should we estimate? Absolute metrics like duration or effort? Or relative estimates (tasks relative to other tasks)?

那么，我们应该估计什么呢？ 持续时间或精力等绝对指标吗？ 还是相对估计(相对于其他任务的任务)？

Generally, teams tend to be more successful with relative estimates because it can be done quicker than absolute estimates, people tend to be better at estimating relatively, and it is more team focussed. The example often given is if you have a group of people estimate the height of a building in metres, they will often be wildly off, but if you have them estimate the height of one building relative to another, they tend to be much more accurate.

通常，团队使用相对估计会更成功，因为它可以比绝对估计更快地完成，人们相对估计的能力更强，并且团队更加专注。 经常给出的示例是，如果您有一群人以米为单位估算建筑物的高度，他们通常会大相径庭，但是如果您有他们估算一栋建筑物相对于另一栋建筑物的高度，则他们往往更准确。

So what are we actually estimating? It’s not just about the effort (or how long it will take), it’s a combination of complexity, risk (uncertainty) and effort. All of those need to be factored in when estimating. For example, if something is a very minor change, but may catastrophically break your system, it will require significant testing and planning, making it a high relative estimate.

那么，我们实际上在估计什么呢？ 这不仅仅是努力(或需要花费多长时间)，还包括复杂性，风险(不确定性)和努力。 所有这些都需要在估算时考虑在内。 例如，如果某项更改很小，但可能会灾难性地破坏您的系统，则将需要进行大量的测试和计划，因此需要进行较高的相对估算。

For more information, have a look at this article by Mike Cohn and this article by Ryan Key.

有关更多信息，请参阅Mike Cohn的 这篇文章和Ryan Key的这篇文章 。

Then there’s the measurement. Often this is done in “velocity”, which is the number of story points per sprint. It is one of those unfortunately named things in Agile. A better name for it is stability. The goal is to get that number to be as stable as possible. If you can get that number to be fairly constant, then you are better able to predict your work. It is not something that you want to try to increase or use to measure productivity or compare between teams.

然后是测量。 通常，这是通过“速度”完成的，即每个冲刺的故事点数。 它是敏捷中那些不幸的事物之一。 更好的名称是稳定性。 目的是使该数字尽可能稳定。 如果您可以使该数字相当恒定，则可以更好地预测工作。 您不想尝试增加或用于衡量生产力或在团队之间进行比较。

怎么样？ (How?)

Prior to doing any relative estimation, a baseline needs to be established (what are we estimating relative to). Usually, that involves picking a story which is clearly defined and assigning it a 2, then picking another story, which is approximately 4 times the size of the first story, and assigning it an 8. Those two will be the baseline stories against which others are estimated.

在进行任何相对估算之前，需要建立一个基准线(我们相对于估算值)。 通常，这涉及到选择一个定义明确的故事并将其分配为2，然后选择另一个故事(其大小约为第一个故事的大小的4倍)，并为其分配一个8。这两个故事将是其他参与者针对的基线故事估计。

One way to do the estimation is to use a technique called planning poker. This is where each person in the team will silently declare their estimate for a story, and then if everyone estimates the same or similar number move onto the next story. But if estimates differ between people, a discussion is had to help clarify the scope, before more silent estimation occurs.

一种估算方法是使用一种称为“ 计划扑克”的技术。 在这里，团队中的每个人都将默默地声明他们对一个故事的估计，然后如果每个人都估计相同或相似的数字，则转到下一个故事。 但是，如果人与人之间的估算值不同，则必须进行讨论以澄清范围，然后再进行更安静的估算。

Another way to estimate, which is particularly effective when there are a significant number of stories to estimate is to use Affinity Estimation. This is where the team tries to quickly group many stories into buckets all at once, rather than focusing on each story at a time.

另一种估计方法(当有大量故事需要估计时特别有效)是使用相似性估计 。 在这里，团队尝试将多个故事快速地一次分组，而不是一次专注于每个故事。

WHO？ (Who?)

The people involved in taking the work and implementing it. But who exactly is that? Does it include product managers, product designers, etc. That usually depends on your entry criteria or “Definition of Ready”. If your Definition of Ready states that a story must have its scope clearly defined, designs complete, and Acceptance Criteria written, then the estimate applies to just the developers, testers, etc who will take the story from that point to delivery (or whatever your “Definition of Done” is). If your Definition of Done does not include the design, then whoever is involved in iterating that design should be included in that estimation. Rarely should the Product Manager be involved in estimation. Their goal should be to provide as much clarification as needed for the rest of the team to estimate.

参与并执行工作的人员。 但是那到底是谁？ 它包括产品经理，产品设计师等吗？通常取决于您的输入条件或“就绪定义”。 如果您的“准备就绪定义”规定必须明确定义故事的范围，完成设计并编写验收标准，则估算仅适用于将故事从该点传送到交付的开发人员，测试人员等(或“完成的定义”是)。 如果您的“完成的定义”中不包含设计，则涉及迭代该设计的任何人都应包括在该估算中。 产品经理很少参与估算。 他们的目标应该是为团队其他成员提供所需的澄清。

The other part of the who should do the estimation is the team that does the actual work. It is generally not useful to try to standardise across multiple teams. This tends to be very time consuming and usually slowly gets out of sync. Also, often each team will be doing different types of work in different contexts, which means there is little value to standardising between teams.

谁应该进行估算的另一部分是进行实际工作的团队。 尝试在多个团队之间进行标准化通常是没有用的。 这往往非常耗时，并且通常会慢慢失去同步。 而且，每个团队通常会在不同的环境下进行不同类型的工作，这意味着标准化团队之间的价值很小。

结论 (Conclusion)

Firstly, consider If you should be estimating at all. If you do decide to estimate (or cannot win the argument not to estimate), focus on the value-adding aspects of estimation which is about helping clarify the scope of work, and splitting up work into smaller increments. Then focus on a short time horizon and use relative estimates to size those stories.

首先，考虑是否应该进行估算。 如果您确实决定估算(或无法赢得不估算的论点)，则应着重于估算的增值方面，这将有助于澄清工作范围，并将工作分成较小的增量。 然后将重点放在较短的时间范围内，并使用相对估计来确定这些故事的大小。

翻译自: https://medium.com/@mgrebler/agile-estimation-all-your-questions-answered-8e8c157576e

敏捷估算 视频