你是否计算了修复错误的时间？

Question

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

Answer 1

我的团队正在支持许多遗留应用程序，因此在每个sprint期间发生了相当多的计划外错误修复。我们采用了以下做法：

• 如果错误很容易/快速修复（一个衬垫等），那么就修好它。
• 如果错误不是微不足道的，而不是阻止程序，则将其添加到积压工作中。
• 如果错误是阻止程序，则添加一个任务（到当前的sprint）以捕获修复它所需的工作，并开始处理它。这需要将其他内容（从当前sprint）移动到待办事项以计算新的小时数，因为可用的总小时数没有变化。

当我们添加新的bug任务时，我们会将它们与计划任务区别开来，以便在sprint审核期间轻松查看。有时计划外的工作最终不会超过我们sprint的50％，但由于我们将计划的项目推送到积压工作，我们很早就知道我们没有提供我们计划进行的这个sprint。

事实证明，这对我们团队处理遗留应用程序非常有用，因为我们没有人像我们希望的那样熟悉或对系统充满信心。

Answer 2

sprint中发现的属于该sprint的错误应该自动修复，就好像任务/故事没有开始一样。从之前的冲刺中出现的漏洞可以输入错误积压并按照正常的积压进行优先排序。

编辑：刚才意识到通过提及“bug-backlog”我打开“多个积压”这是一个坏主意。更好的方法是使用bug标记在积压中标记条目，或者只接受积压中的任何其他故事。

sprint中出现的严重错误的数量应该是最小的，因为所有内容在接受之前已经过测试，并在sprint结束时交付给项目所有者。

实际上它不应该影响图形，因为你将承诺修复一定数量的错误（通过PO的选择 - 一些错误的优先级低于新功能）以及当错误从sprint本身出现时，这个任务真的没有完成，所以可以意识到并花时间修复它。

编辑：意识到其他事情 - 有时候在scrum团队工作并不总能保护你免受必须维护其他应用程序，支持等的现实。虽然这真的很糟糕并且完全有理由成为一个团队一个积压和重点不是真的有效，现实往往是你需要每周保留固定的小时数来支持/维护。不要鼓励这一点，但如果这是现实，请尝试并指定一个人（轮换所以他不会感到悲伤）每周一个固定的小时专用于所述支持角色。通过这种方式，您知道会发生什么，因为速度是相对的 - 它会在某种程度上看起来对短跑的影响较小。

Answer 3

我倾向于处理此问题的方法是将错误修复移到sprint之外。因此，为期三周的冲刺可能会在演示/发布之前进行一周的错误修复。

这不是一个理想的解决方案，因为没有尝试估计将在错误修复阶段修复的错误数量。所以我期待其他人提供比我更好的解决方案。

Answer 4

我认为在您诊断问题之前很难估计修复错误的工作量，并且诊断通常是花费大部分时间。

如果你的bug容量相当一致，我会让它“在冲洗中”对抗速度。这就是我通常对影响团队迭代目标的生产缺陷所做的事情。

如果你意识到中间迭代你会落后（例如，由于bug问题，你会看到一个看起来不像它会在迭代结束时与你的作用域线相交的燃尽图表），那么你可以适应范围（剔除最低优先级的故事）以适应额外的工作。

Answer 5

在每个sprint中，我有两个“任务” - 一个用于当前sprint中发现的bug（即未发货的代码），另一个用于发现其他任何问题（任何发布的版本）。这有助于我记录修复错误所耗费的时间（每个开发人员）。

任何登录后一类的行为都被视为浪费，它是减少的关键目标。记录前者记录的时间，以了解它如何与导致它的功能和更改更紧密地联系起来。

不要针对错误进行估算，而是尝试将时间添加到针对您正在处理的功能的单元/功能测试的估算中。

随意调整任何模型以适应您团队的工作方式 - 任何Scrum团队都应该有持续改进的文化，开发人员应该能够在学习Scrum时建议并尝试改进。