您是否将花费在修正错误上的时间花在了Scrum上？ [英] Do you count the hours spent on bug fixes towards the scrum?

问题描述

我是scrum方法的新手，正在寻求帮助以适应环境，并想知道是否需要一个跟踪器来跟踪开发人员以及部署，错误修复和重新测试所花费的QA时间。似乎可能会对图表产生重大影响。

I am new to the scrum methodology and looking for some help to get comfortable with the environment and wondering if there needs to be a bucket to track Developers and QA hours spent on deployments and bug fixes and retests. Seems like it could have major impact on the graph.

推荐答案

我的团队正在支持许多旧版应用程序，因此每次冲刺期间都会发生的一些计划外错误修复。我们采用了以下做法：

My team is supporting a number of legacy apps, so there's quite a bit of unplanned bug fixing that occurs during each sprint. We've adopted the following practice:

• 如果该错误很容易/快速修复（一个衬里等），则只需对其进行修复


• 如果该错误不是微不足道的并且不是阻止程序，则将其添加到待办事项中。


• 如果该错误是阻止程序，则添加一项任务（到当前的sprint）以捕获修复该问题所需的工作，然后开始进行处理。这就需要将其他内容（从当前的sprint）移至待办事项列表，以计算新的小时数，因为您的可用总小时数未更改。

添加新的Bug任务时，我们将其标记为与计划的任务不同，从而使它们在sprint审阅时易于查看。有时，计划外的工作最终会超过我们的sprint的50％，但是由于我们将计划中的项目推到了积压中，所以我们很早就知道我们没有交付计划的sprint。

When we add new bug tasks we'll mark them differently from the planned tasks so make them easy to see during the sprint review. Sometimes unplanned work ends up being >50% of our sprint, but because we're pushing planned items to the backlog we know very early what we're not delivering this sprint that we had planned on.

事实证明，这对于我们的团队在处理遗留应用程序方面非常有用，因为在这些遗留应用程序中，我们谁都不像我们想要的那样熟悉或自信。

This has proven to be very useful for our team in dealing with legacy apps where none of us are as familiar or confident with the systems as we'd like to be.

这篇关于您是否将花费在修正错误上的时间花在了Scrum上？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！