19

嗨，我是 Scrum 方法的新手，正在寻找一些帮助以适应环境，并想知道是否需要一个存储桶来跟踪开发人员和 QA 花费在部署、错误修复和重新测试上的时间。似乎它可能对图表产生重大影响。

4

5 回答 5

35

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

  • 如果错误很容易/快速修复（一个班轮等），那么只需修复它。
  • 如果错误不是微不足道的，也不是阻碍，则将其添加到积压工作中。
  • 如果 bug 是一个阻碍，那么添加一个任务（到当前的 sprint）来捕获修复它所需的工作，并开始处理它。这需要将其他内容（从当前的 sprint）移到积压工作以考虑新的小时数，因为您的可用总小时数没有改变。

当我们添加新的错误任务时，我们会将它们标记为与计划任务不同的标记，以便在 sprint 审查期间轻松查看它们。有时计划外的工作最终占我们 sprint 的 50% 以上，但是因为我们将计划中的项目推到 backlog 中，所以我们很早就知道我们没有交付我们计划的这个 sprint 什么。

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

于 2008-10-06T20:48:10.180 回答
10

在冲刺期间发现的属于该冲刺的错误应该自动修复，就好像任务/故事一开始就没有完成一样。从之前的 sprint 中出现的 bug 可以像正常的 backlog 一样进入 bug-backlog 并确定优先级。

编辑：刚刚意识到通过提及“错误积压”，我打开了“多个积压”，这是一个坏主意。更好的方法可能是用错误标志标记积压中的条目，或者只是接受它作为积压中的任何其他故事。

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

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

编辑：意识到其他事情 - 有时在 Scrum 团队中工作并不总能保护您免受必须维护其他应用程序、支持等的现实。虽然这真的很糟糕，并且使整个想法成为一个只有一个积压的团队并且专注并没有真正起作用，现实情况通常是您需要每周保留固定的小时数来支持/维护。不要鼓励这样做，但如果这是现实，请尝试每周分配一个人（轮换，这样他就不会变得悲伤）固定的小时数专门用于所述支持角色。这样，您就知道会发生什么，因为速度是相对的——它似乎对冲刺的影响较小。

于 2008-10-06T18:00:18.397 回答
1

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

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

于 2008-10-06T17:45:08.490 回答
1

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

如果您的错误数量相当一致，我只会让它“洗掉”以对抗速度。对于影响团队迭代目标的生产缺陷，我通常会这样做。

如果您意识到由于错误问题导致您在迭代中落后（例如，您看到一个燃尽图看起来不会在迭代结束时与您的范围线相交），那么您可以调整范围（放弃最低优先级的故事）以适应额外的工作。

于 2008-10-07T15:31:55.760 回答
0

在每个 sprint 中，我有两个“任务”——一个用于在当前 sprint 中发现的错误（即在未发布的代码上），另一个用于在其他任何东西中发现的问题（任何已发布的版本）。这有助于我跟踪修复错误的时间（每个开发人员）。

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

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

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

于 2008-10-06T18:52:14.093 回答