你在Scrum中验证了一个任务多少次了？

Question

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

这证明对错误，更好的代码等有帮助。

对于有类似做法的人：在开发人员处理了评论/错误之后，您是否再次验证它，或者您是否认为已解决问题并将任务移至“完成”？

我希望这很清楚，并希望听到你的想法。

Answer 1

根据我的经验，修复bug有50-75％的可能性引入新的bug，特别是如果代码未被测试用例覆盖。我当然会再次验证它。

Answer 2

这个问题并不是针对Scrum的，我在敏捷过程之外也看到了这个问题。

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

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

Answer 3

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

Answer 4

我们没有要验证列。任务正在进行中，直到实施和测试。一个未经测试的任务无法完成，为什么其他人要测试它，向程序员报告然后程序员必须修复它？这只会增加工作流程的延迟。程序员应该测试他自己的代码，如果可能的话为它编写单元测试，并在可能的情况下将其集成到应用程序中，并在此处作为自然工作流程的一部分进行测试。这样他就可以找到自己的bug并立即修复它们。当他将任务设置为Done时，他不仅确信已完全执行任务，而且还认为该任务没有错误。

好的，我们都知道，这意味着什么。有时候很多bug都会被发现，但是这些bug并不是那么明显的错误，通常它们的修复将是它自己的任务。

Answer 5

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

开发人员也没有找到错误的所有路径，或者错误报告是如此不清楚以至于开发人员做出了错误的修复 - 例如如果某些内容被误解，并且正确的功能被报告为错误。

为了确保在完成后保持完成，还应该在自动化测试中添加修复测试 - 否则一些令人尴尬的角落案例错误将在几个月后重新出现。