Scrum，如何处理冲刺中的错误以及如何对错误进行时间估计
我正在参与一个 Scrum 项目，用 C 语言为 ASIC 编写固件代码。
很多时候我们很难找到错误。但我如何估计这些错误的时间呢？
我总是告诉 Scrum Master 我没有能力估计它们，因为我真的很讨厌对错误进行时间估计。
你们在 Scrum 项目中如何处理这个问题？
I'm working in a Scrum project writing firmware code in C for an ASIC.
Every so often we have really hard to find bugs. But how do I time estimate these bugs?
I always tell the Scrum master I do not have the competence to estimate them because I really hate time-estimation of bugs.
How do you guys handle this in your Scrum projects?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（15）
估计错误是一件非常困难的事情。如果你能做到这一点，那么你可能已经有了解决方案，并且它不再是一个真正的错误了:) 因此，我的首选选择是分配一些“错误”，而不是尝试一一估计它们修复时间”并在 Sprint 期间修复最重要的错误。这是尽力而为的策略，您只需在分配的时间内修复尽可能多的问题即可。
Estimating bugs is a really hard thing. If you can do it, then you likely already have the solution and it's not really a bug anymore :) So, instead of trying to estimate them one by one, my preferred option is to allocate some "bug fixing time" during the Sprint and to fix most important bugs during that time. This is a best effort strategy, you just fix as much of them as possible during the allocated time.
对我有用的一种方法是从一开始就不存在错误:)
这种方法的工作方式是，当发现错误时，修复它优先于故事实现。只有当现有功能 100% 运行时才能添加新功能。
当然，我们对错误进行分类。这种停止生产线的方法仅适用于严重错误。不太严重的错误被视为功能增强故事，在即将到来的冲刺中与任何其他故事一样进行估计和计划。
关键错误修复的时间分配最终会反映在您的团队速度中。
One approach that has worked for me is not to have bugs in the first place :)
The way this works is that when a bug is found, fixing it takes priority over story implementation. New features can only be added once the already existing functionality works 100%.
Of course we classify bugs. This stop-the-production-line approach is only applied to critical bugs. Less than critical bugs get treated as feature enhancement stories, estimated and planned in upcoming sprints as any other stories.
Time allocation for critical bug fixing eventually gets reflected in your team velocity.
“很难做出预测——尤其是对未来。”
除非您分析了错误并制定了解决方案，否则无法对其进行估计。这就像在不知道待办事项列表的情况下召开 Scrum 计划会议。
您可以使用较大的估计来传达不确定性。历史数据的价值有限。即使新错误的工作分配相同，它对于手头的一个错误也没有多大帮助。此外，平均而言，新错误可能更容易或更难。
"It's hard to make predictions - especially about the future."
Unless you have analyzed a bug and stetched a solution it cannot be estimated. This is like doing a scrum planning meeting without knowing the backlog.
You can use large estimates to communicate uncertainty. Historic data has some limited value. It does not help a lot for the one bug at hand even when the effort distribution is the same for new bugs. Additionally, new bugs can be easier or harder on average.
我向 Jeff Sutherland 询问了这个问题，他告诉我，在 PatientKeeper，他们固定估计需要半天时间来修复错误。如果你的错误的本质是它们可以相当可预测，这样你就可以找到一个近似的平均值，我想这是一个公平的策略。
然而，在实践中，我发现这并不总是有效。通常很难理解错误是什么，并且分析它可能比解决它需要更长的时间。这通常会使错误高度不可预测且难以估计。冲刺中包含的所有任务都必须进行分析，并且错误通常比其他任务需要更多的分析。
在这种“不可预测”的错误情况下，我们所做的就是分配固定的时间来找出问题所在。例如，我们选择花一天（或 x 点）来深入研究错误并尝试理解它，然后计划解决下一个冲刺的实际修复问题。但是，如果没有足够的时间来解决这个问题，我们不想在当前的冲刺中浪费更多时间，并且必须在下一个冲刺中重新考虑它。在某些情况下，错误可能非常严重，您只能接受不确定的估计。
I asked Jeff Sutherland this, and he told me that at PatientKeeper they have a fixed estimate of half a day to fix a bug. If the nature of your bugs is that they can be rather predictable such that you can find an approximate average I guess this is a fair strategy.
However, in practice I don't find this always to work out. It is often difficult to understand what the bug is, and it might take longer time analyzing it than to solve it. This often makes bugs highly unpredictable and difficult to estimate. All tasks you include in your sprint must be analyzed, and bugs will often require more analyzis than other tasks.
What we've done in such cases of "unpredictable" bugs is to allocate fixed time for figuring out what the problem is. E.g. we choose to spend one day (or x points) on digging into the bug trying to understand it, and then plan to address the actual fix for the next sprint. However, if that isn't sufficient time to figure it out we don't want to waste more time on it in the current sprint, and will have to reconsider it for the next. In some cases the bug might be highly critical, and you just gotta live with an uncertain estimate..
以几周而不是几小时为单位进行估算。
如果您的 Scrum Master 不理解错误修复时间估计问题，您的项目可能会受益于拥有至少少量编程知识的 Scrum Master。
Estimate them in weeks instead of hours.
If your Scrum-master doesn't understand the problem with time-estimating a bug-fix, your project would probably benefit from having a Scrum-master with at least minor programming knowledge.
我们可以将错误分类为
“我知道哪里出了问题，我需要更新它”，
“我知道这个错误与这个模块有关，任何调试这些文件我都可以解决它”，
“我不确定为什么会出现这个错误”。
我们可以根据我们在该项目上的经验来估计前两种情况。
但对最后一个案例的估计确实很困难。
We can classify bug in
"I know where it is going wrong I need to update it",
"I know this bug is related to this module and any debugging some of these files I can resolve it",
"I am not sure why this bug has come up".
We can estimate in first 2 cases based on our experience on that project.
But estimating for last case is real tough.
根据修复早期错误所花费的平均时间来估计它们怎么样？
How about estimating them based on the average time spent fixing earlier bugs?
我早些时候问过类似的问题，并得到了一些 良好的反应。
I asked a similar kind of question some time earlier and got some good responses.
您应该能够根据一致的故事点估计建立一周内可以完成多少故事点的历史记录。这还包括错误修复时间。
例如，我们知道我们可以在一周内完成之前冲刺的 20 个故事点。这 20 个点的开发可能会在 2 天内完成，但随后还要进行测试和错误修复。我们不会估计开发错误，因为每个新故事都应该有一个大约包括错误修复时间的估计。在估计之前应该调查活虫，然后才可以准确地估计。
You should be abel to build a history of how many story points you can complete in a week, based on consistent story point estimation. This will also include bug fixing time.
For example we know we can complete 20 story points in a week, from previous sprints. The development of those 20 points may be complete within 2 days, however then there is testing and bug fixing. We don't estimate on dev bugs, as each new story should have an estimate that will approximately include bug fixing time. Live bugs should be investigated before estimation, then it should be possibel to estimate accurately.
我们估计每个 bug 的分析时间为 4 小时。我们还对错误进行了优先级排序。在实施任何其他措施之前，必须修复阻碍或严重的错误。许多需要修复的错误会导致较低实施的故事。但我们有一个强大的软件来实现接下来的功能。
We estimate for every bug a analyze time of 4h. Also we have a prioritization of bugs. Bugs which are blockers or critical must fixed before anything other is implemented. Many bugs to fix results in lower implemented stories. But we have so a robust software for the next features.
我发现尝试估计错误确实没有多大用处。只需阻止它们、找到它们、使它们可见（在您的任务板或您使用的任何东西上）、确定它们的优先级并修复它们即可。您花费的时间会影响速度。重要的是速度。速度是您在下一个冲刺中可以预期取得多少进展的指标。
如果您对某些指标感兴趣，请使用每个冲刺的错误数。
I find that there really is not that much use in trying to estimate bugs. Just prevent them, find them, make them visible (on your taskboard or whatever you use), prioritize them and fix them. The time you spend will impact the velocity. And it's the velocity that matters. It's the velocity that's the indicator on how much progress you can expect in the next sprint(s).
If you are interested in some metrics, use number of bugs per sprint instead.
真正的目标是降低与错误相关的风险；即不让时间表生效。很多时候，团队将能够提前确定哪些故事可能会产生棘手的错误。因此，一种缓解策略是首先解决这些问题，为团队提供尽可能多的时间来应对意外情况。
The real goal is to mitigate the risks associated with bugs; i.e. not letting the schedule be effected. Very often, the team will be able to identify which stories are likely to create the tricky bugs ahead of time. So one mitigation strategy is to tackle those stories first, giving the team as much time as possible to cope with the unexpected.
您还可以考虑在 Sprint 期间分配一个“临时任务”来修复错误（可提交时间的 10-20%），而不是使用看板方法来解决它们。这意味着您可以与产品负责人交谈并向他解释错误修复成本是在控制范围内的（因为这就是您的时间范围），根据团队对产品质量的感觉，该成本将在每次新的迭代中进行调整。目标当然是减少时间并提高透明度。产品负责人可以帮助确定 Bug 积压的优先级，将最有价值的 Bug（通常是保留值）放在首位，以便最高优先级的问题可能会得到修复……越高越好。
使用 KanBan 意味着团队会定期坐下来查看 Bug 队列中的内容（在每日站会之后是一个很好的时间），利用所有团队成员的专业知识来找出查看位置和检查内容，比某人（通常配对真的很好）接受了这个错误。当队伍结束时，团队举手并与产品负责人交谈，他将必须决定是否仍然存在需要修复的错误 - 以一个故事或更多的成本 - 或者他们可以等待下一个 Sprint。
一般来说，透明度应该使 Scrum 团队（包括 PO 和 SM）能够弄清楚修复的成本是多少，并弄清楚如何平衡交付的质量和速度。这通常是与 PO 建立对话的好方法:-)
you might also consider to allocate a "contingent" for bug fixing during the Sprint (10-20% of the committable time) than use a Kanban way to work them out. That means you can talk with the Product Owner and explain him that the bug fixing costs are under control (as the contingent is your timebox) that empirically will be adjusted at every new iteration based on what the team feels the quality of the Product will be. The Goal is of course to reduce the time and promote transparency. The Product Owner can help in prioritizing a Bug Backlog putting on top the most valuable bugs - normally Retainment value - so that the highest prioritized will be probably fixed... the higher the better.
Working with KanBan, means that the Team sits and look at regular interval (after the daily stand-up is a good time) what is in the Bug queue, uses the expertise of all the team members to figure out where look and what to check, than someone (normally pairing is really good) takes the bug. When the contingent is over the Team raises the hand and talks with the Product Owner, he will have to decide if there are still bugs that have to be fixed - at the cost of a story or more - or they can wait the next Sprint.
In general transparency should enable the Scrum Team (includes PO and SM) to figure out what the cost of fixes is and figure out what to do to balance quality and speed of delivery. It is normally a good way to establish a dialog with PO :-)
我听说过修复错误与钓鱼相比。你需要多长时间来修复一个神秘的错误？需要多长时间才能钓到一条鱼？您可以尝试用这些术语向您的产品负责人解释。
I have heard bug fixing compared to fishing. How long will it take you to fix a mysterious bug? How long will it take to catch a fish? You might try explaining it to your product owner in those terms.
非常同意Pascal Thivent的回答。
在我们的Sprint中，通常我们会选择一些任务，如果还有其他更紧急的任务，这些任务是可以定制的。
当出现错误时，我们会对其进行优先级排序并设置其重要性。
如果优先级高或严重性高，我们就会去做，而这个 Sprint 中不重要的任务将移回到待办事项列表中。
如果没有bug或者bug不紧急，我们将完成所有的Sprint任务。
如果已经运行了很多 Sprint，可能会有一个统计数据显示花费了多少精力来修复错误，获取平均努力作为下一个 sprint 的基准是您的另一个选择。
quite agree with Pascal Thivent's answer.
in our Sprint, usually we will select some tasks which can be tailored if there are other more urgent tasks.
When a bug comes, we prioritize it and set the importance to it.
if high priority or severity, we will go to do it and the unimportant task in this Sprint will be move back to the backlog.
if no bug or the bug is not urgent, we will do all the Sprint tasks.
if there are a lot of Sprints have been run, there may be a statistics that shows how much effort has been spent to bug fix, get the average effort as the benchmark for your next sprint is another option for you.