7

我们最近在工作中采用了 Scrum，但遇到了代码被接受后出现的一堆小错误。其中包括拼写错误和其他单行修复等内容。为每件小事创建大小为 0.5 的故事似乎是在浪费时间。写故事并指出它比修复它需要更多的时间。如果每个 sprint 中只有一两个这样的问题，那么只需修复它们就很容易，而不必担心为它们创建故事。但是，如果有 10 个或 20 个或更多，因为应用程序很大，这可能会开始增加大量的开发人员时间，而这些时间并没有通过 Scrum 来计算。虽然很容易说 QA 人员和产品负责人在最初接受原始故事之前应该更加彻底，但我'

到目前为止，我们提出了一些不完美的想法：

  • 有一个故事说“应用程序中修复了 90% 的错误”，然后您猜测该 sprint 中会出现多少错误以及可以修复多少错误，然后根据预期的工作量指出它
  • 有一个大小为 8 的故事，在 sprint 结束时总是被接受，在那里您可以修复尽可能多的错误。这显然需要非常信任每个人实际上都在做 8 分的工作
  • 记录错误，但在下一个 sprint 之前不要处理它们。它们可以单独指向，也可以作为一组指向。这具有更“Scrummy”的优势，但会导致本质上是 1 小时的修复延迟三周。

有什么建议么？

4

8 回答 8

13

您的第三个答案是最好的方法。冲刺只是团队承诺在规定的时间内完成指定数量的工作。如果您在 sprint 的中间接受额外的工作，那么您将偏离最初的承诺，从事团队在 sprint 开始时未承诺的事情。

这是我们所做的：

  • 冲刺中的所有故事都必须没有缺陷才能被视为“完成”
  • 在 sprint 中为之前完成的故事发现的任何缺陷都将被记录并放入 backlog。它们像其他任何东西一样被估计，并由产品所有者优先考虑。如果产品所有者优先考虑新功能而不是缺陷，那么他们会选择功能而不是质量，反之亦然。
  • 我们不会将故事点分配给缺陷，但我们会估计每个缺陷，因为它作为计划的一部分被接受到 sprint 中。团队不应该因为损坏的功能而受到赞扬，但同样需要认识到修复它们所花费的时间——这两者兼而有之。

这是您的其他解决方案的问题：

有一个故事说“应用程序中修复了 90% 的错误”，然后您猜测该 sprint 中会出现多少错误以及可以修复多少错误，然后根据预期的工作量指出它

再次，见上文。您希望避免在冲刺期间可以填充的空工作桶。这违背了团队明确承诺的目的。团队如何承诺他们不知道或未估计的事情？

另外，这很容易失去控制，变成一个产品所有者，他们会“根据缺陷进行设计”，用实际上伪装成缺陷的好用功能填充那个桶。

有一个大小为 8 的故事，在 sprint 结束时总是被接受，在那里您可以修复尽可能多的错误。这显然需要非常信任每个人实际上都在做 8 分的工作

这听起来很奇怪。团队应该在新的 sprint 计划开始时接受工作，而不是在上一个 sprint 结束时。此外，从长远来看，这确实会影响您的速度。Scrum 指的是产品待办事项，而不仅仅是故事，所以没有什么可以说你不能将缺陷作为 PBI 包含在内。

记录错误，但在下一个 sprint 之前不要处理它们。它们可以单独指向，也可以作为一组指向。这具有更“Scrummy”的优势，但会导致本质上是 1 小时的修复延迟三周。

你提出了一个有趣的观点，我们对此也有一些担忧。然而，当与积压中的其他事情叠加时，这 1 小时的修复（不管它有多快）可能并不适合花时间。底线是您希望将这些决定推给产品负责人，并让他们自由地优先考虑团队花费的一切努力。

于 2009-06-23T17:58:08.260 回答
5

我坚信，一个过程的好坏取决于它改善情况的能力。这个过程应该对你有用，而不是相反。

如果遵循敏捷 Scrum 流程到“T”是弊大于利，那么在这种情况下，是时候在 Scrum 流程之外寻找更好的解决方案了。

我们创建了一个迷你“QA”冲刺，在每个冲刺结束时附加。它是在代码完成之后但在发布之前。在这么短的时间内，问题会被仔细审查，并且可以根据风险和重要性批准纳入。在此期间修复的问题具有一些额外级别的自定义审查流程，但主要在定义的 Scrum 流程之外工作。

于 2009-06-23T18:26:48.540 回答
3

您是否在回顾过程中确定了这些错误的原因？您是否使用工程 (XP) 实践，即进行 TDD - 测试驱动开发，自动化功能测试将每天进行完整的回归测试以及配对和带有验收标准的故事卡。

当发现缺陷时，是否确定了根源，是否将自动化单元和功能测试添加到您的测试工具中以捕获此类缺陷，以防它再次发生？

据我了解，你的缺陷率太高了。如果至少每天进行一次 TDD 和全功能回归测试，那么在 UAT 期间达到零缺陷的情况并不少见。

在短期内，您可以向团队收取 x 数量的单位/工作点来修复缺陷（查看您过去的迭代，如果每次迭代需要 x 小时数来清理小错误，请从您的团队的能力。）从长远来看，关注根本原因并改进团队的工程实践。

通过衡量缺陷修复的成本，我们看到了以下关系。如果一个缺陷在开发期间的成本为 1 倍，则在功能测试期间修复成本为 2 倍，在 UAT 期间修复成本为 3 倍，在生产时修复成本为 4 倍。通过编写带有验收标准的故事卡、结对开发、测试驱动开发和自动化功能测试，至少每天进行一次完整的回归测试，您将显着提高质量并降低成本。因此，您无需从团队的容量中减去任何时间，这将提高速度。

于 2009-06-27T01:43:47.917 回答
3

这是 Scrum 项目中对良好工程实践的强烈需求的一个很好的例子。

“[我们]遇到了在代码被接受后出现的一堆小错误的麻烦”

这表明您的“完成的定义”不够强。

“这些包括诸如拼写错误之类的东西”

这些拼写错误是否出现在 UI 上？在代码被接受之后发现它们的人应该在代码被接受之前发现它们。

与缺陷有关的事情是 1) 立即修复它们，2) 对系统进行检测，以便下次更早发现类似的缺陷，以及 3) 改进您的流程，以减少导致缺陷的错误类型将来发生。这些都是技术问题。

于 2009-06-28T07:38:05.967 回答
1

如果 Bug 与您正在开发的内容无关，或者假设在 sprint 期间发生的任何其他“无关”活动，我们通常会做的是创建一个“特遣队”。

它基本上是从您的冲刺“容量”中删除的一定时间，并且将根据需要专门用于冲刺目标之外的活动。这通过以下方式工作：

  • 团队每天都专注于 Sprint 目标，但有“缓冲”时间（特遣队）来处理外部问题。在每日站会中，PO 可能会提出每日收到的问题，完成 Sprint 任务（因此不会中断）的团队成员最终将解决其中一个问题。

  • 时间是在特遣队上预定的，到了结束时将不得不关闭。

  • 团队有权与产品负责人沟通，特遣队的时间已经结束，如果他希望他们遵守 Sprint 承诺，他必须决定是要他们这样做，还是在每天之后继续运行问题，放弃了 Sprint 的一些价值。

它总是被证明是一个公平的交易;-)

我们将其用于以下方面：实时产品的错误和维护 (5-15%)，即将到来的 sprint 的准备 (10%)...

高温高压

于 2009-07-05T11:53:28.257 回答
1

我的项目成功实施了以下政策：

  • 缺陷纠正总是优先于功能开发。目标是始终保持零开放缺陷，重视 100% 的工作特性而不是几乎工作的特性。

  • 缺陷可以而且应该在发现后立即修复。仅当某些非开发人员发现缺陷或开发人员发现该缺陷无法立即修复时，才需要提交故障单。

  • 需要对代码库进行架构级别更改的缺陷将架构调整部分记录为故事，并为即将到来的冲刺进行估计和计划。缺陷状态设置为待处理故事实施。

  • Sprint backlog 不受外部更改的影响，但团队本身可能会在 sprint 的中间引入新的东西，这是为了始终满足零缺陷的目标。

  • 如果一个缺陷不值得修复（基于一些基本的成本效益分析），那么它只是被忽略以防止不会修复开放缺陷污染问题跟踪器。

将缺陷修复优先于故事实施会不时影响您的速度，但这没关系。从长远来看，您实现故事的效率将会提高，因为代码库中只有一点技术债务。

于 2009-06-23T21:44:43.393 回答
1

谁负责为您推送到生产中的代码提供支持？如果您的团队确实处理了支持请求，那么这些拼写错误和其他外观问题属于该类别并得到适当处理。如果没有，那么您可能不得不让偶尔的 sprint 有点像“修补”sprint，其中没有添加新功能，但修复了许多旧的东西，并将技术债务减少到合理的水平。或者将小错误中的一个错误组合成一个故事，比如“修复网站上的所有错别字”以获得一个想法。

如果你用 Scrum 搜索“技术债务”或“破窗”，看看其他人如何处理这些事情，可能会有其他想法。

于 2009-06-23T18:01:01.423 回答
0

如果错误导致您停止执行 sprint 目标，您仍然可以决定取消迭代并重新计划。但这是一个安静而艰难的决定。

于 2009-06-28T19:26:04.600 回答