您在Scrum中验证了多少次任务？

Question

在我们的Scrum板上，任务从“待办事项”开始，进入“进行中”，当您完成任务时，他们在“完成”之前转到“验证”。 “验证”列是指完成任务后，其他人可以查看它，对其进行测试并对其进行评论。

这已被证明错误的帮助，更好的代码等

要谁也有类似做法的人：后开发商已经解决的意见/错误，你再次验证它，或者你假设的问题已解决并将任务移至“完成”？

我希望这是明确的，并希望听到你的想法。

Answer 1

这个问题不是特定于Scrum，我也看到了敏捷过程之外的这个问题。

答案原来是：它取决于验证中提出的问题。如果有小问题提出，并且负责的开发人员足够高级，那么请相信他第一次解决问题。但是如果进行验证的人认为这些项目太复杂，或者Scrum Master缺乏信任让开发人员第二次正确使用这些项目的信心，那么您将该项目移回到进行中。

你不打扰检查错误的一个很好的例子是一个简单的错字。当存在许多相互依赖的边界条件时，您将再次检查的一个很好的例子是边界条件中的误差。

Answer 2

在我的期限中，bug的修复有50-75％的机会引入新的bug，特别是如果代码没有覆盖测试用例。我肯定会再次验证它。

Answer 3

从不假设问题被解决，直到它是独立的（即不是由谁修理它的人）验证。

Answer 4

我们没有验证列。一项任务正在进行中，直至已执行和测试。一个未经测试的任务不能完成，为什么其他人应该测试它，向程序员报告，然后程序员必须修复它？这只会增加工作流程的延迟。程序员应该测试自己的代码，尽可能编写单元测试，并尽可能将其集成到应用程序中，并在此处测试它作为自然工作流的一部分。这样他就会发现自己的错误，并可以立即修复它们。当他将任务设置为完成时，他不仅确信完成了任务，而且确保任务无缺陷。

好的，我们都知道，那意味着很少。有时候错误会在很晚以后发现，但这些错误并不是那么明显，通常它们的修复将成为它自己的一项任务。

Answer 5

在我参与的项目中（敏捷和非敏捷），错误修复总是由其他人验证。通常会引入新的错误，因此需要对修复进行一些探索。我甚至看到一些在构建中被遗忘的调试代码 - 一切正常，但是额外的文件从无处出现。

它也有可能是开发者没有找到所有错误的路径，或者错误报告太不清楚以至于开发者做出了错误的修复 - 例如，如果某些东西被误解了，并且正确的功能被报告为一个错误。

为了确保它们完成后仍然保持完好，修复测试也应该添加到您的自动化测试中，否则一些令人尴尬的角落错误将在几个月后重新出现。