agile - 你如何处理 Scrum 中一堆不相关的小错误？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

3年前关闭。




Improve this question




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

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

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

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

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

有什么建议？

Answer 1

你的第三个答案是最好的方法。冲刺只是团队 promise 在规定的时间内完成规定的工作量。如果您在 sprint 的中间接受额外的工作，那么您就偏离了最初的 promise ，因为在 sprint 开始时团队没有 promise 的事情。

这是我们要做的:

冲刺中的所有故事都必须没有缺陷才能被视为“完成”

在先前完成的故事的冲刺期间发现的任何缺陷都会被记录下来并放入待办事项中。它们就像其他任何东西一样被估计并由产品所有者优先考虑。如果产品所有者优先考虑新功能而不是缺陷，那么他们选择的是功能而不是质量，反之亦然。

我们不会为缺陷分配故事点，但我们会在每个缺陷作为计划的一部分被接受到冲刺中时对其进行估计。团队不应该因为损坏的功能而受到赞扬，但同样的道理，修复它们所花费的时间需要得到认可——这可以实现两者。

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

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

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

此外，这很容易失去控制，产品所有者将通过在该桶中填充真正伪装成缺陷的好功能来“按缺陷设计”。

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

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

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

你提出了一个有趣的观点，我们对此也有一些担忧。然而，当与积压工作中的其他事情叠加起来时，那 1 小时的修复(不管它有多快)可能不会花太多时间。最重要的是，您希望将这些决定推给产品负责人，并让他们可以自由地优先考虑团队所付出的一切努力。