scrum - 当使用 Scrum 并且还没有创建故事时，为缺陷生成故事是否明智？

Question

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












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

3年前关闭。




Improve this question




假设您正在处理一段遗留代码，该代码是在您的公司开始使用像 Scrum 这样的敏捷方法之前编写的。

现在假设您在该领域发现了一个需要修复的错误，并且从来没有写过该功能的故事。团队中的每个人都知道这个特别的功能是什么以及它应该如何表现，但只是没有与之相关的故事。

现在，在当前的 sprint 中，您将致力于解决该缺陷，因为营销和支持部门已经厌倦了处理该问题。

您是否为要链接到的缺陷创建了一个回顾故事？
您是否将缺陷重新标记为故事并修改格式使其看起来像故事？
如果您不创作故事，您是否会因缺陷而获得积分？
如果您确实创建了一个故事，您是否会因修复缺陷而获得分数(通过故事的分数)？

处理这种情况的最佳方法是什么？

更新:假设安装过程突然开始在 Windows 7 64 位系统上蓝屏，并且一直要求应用程序安装在所有 Windows 平台上。新问题可能是由于 Service Pack 1 或类似问题而出现的。

Answer 1

Do you create a story in retrospect for that defect to be linked to?

是的。也值得审查，以确保每个人都同意这个故事。

如果它是一个没有错误但令人讨厌的界面，那么您实际上是在修改工作流程，并且确实需要将其作为一个适当的故事来纪念。

如果涉及到一个错误，那么单元测试应该已经发现了这个错误(但没有)。这似乎不是您的情况，但不完整的单元测试找不到错误是很常见的。扩展单元测试(在修复故事之后)也非常重要。

Do you relabel your defect as a story and modify the formatting so that it looks like a story?

并不真地。缺陷只是一个缺陷，无论是否有故事。

缺陷消失。故事没有。

If you do create a story, do you get points for fixing the defect (via the story's points)?

为什么不？

编辑 .故事点问题很困难。理想情况下，这些点会跟踪完成的工作和创造的值(value)。故事==努力==积分。但是在处理重用、发布和返工时会出现问题。

你有几个不相关的问题:努力、质量和值(value)。这些点可以跟踪其中之一。它无法跟踪其他任何一个。

如果你认为速度应该反射(reflect)努力，那么你不能因为错误或需求变化而扣分。它不跟踪创造的值(value)，也不能用于此目的。

如果您认为速度应该跟踪值(value)，那么您必须将积分拿走。它不跟踪工作量，因为工作已完成，但功劳已被删除。

返工很艰难。错误和需求更改是一回事，它们是返工。你有各种各样的候选人。

实现错误的“简单”错误，但故事是“正确的”。理想情况下，这不计入速度。对？

“不完整的故事”错误，实现是正确的，但故事省略了一些关键(和技术)细节。唔。谁的错？谁的速度测量应该为此受到惩罚？

我们在测量什么？努力？工作完成了。值(value)？值(value)没有被创造。

“错误的故事”错误，实现是正确的，但故事从一开始就是一个坏主意，没有人发现它。这可以称为“说谎的用户场景”。它发生了。理想情况下，这计入速度。用户撒谎。但是，您如何将其与任何其他返工区分开来？什么是“规则”？

“改变的故事”错误，实现正确，故事正确。但整体背景发生了变化，故事需要改变。这只是“增强”或“适应”，就像新工作一样。当然，这不是全力以赴的工作，是吗？它可能只是对现有代码的一个调整，所以你不想用创造的全部值(value)来过度奖励它。

我们在测量什么？努力？做了一些，但不多。值(value)？值(value)被创造了。

底线 .积分是一种政治武器，不能衡量太多。努力或值(value)，但不能两者兼而有之。而且还不好。