您在Scrum中验证任务的次数是多少?[关闭]

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

答案是:这取决于验证中提出的问题。如果出现了一些小问题,并且负责的开发人员足够资深,那么请相信他第一次就解决了问题。但是,如果执行验证的人认为项目太复杂,或者Scrum管理员缺乏信任开发人员在第二次执行时正确执行的信心,那么您可以将日志移回进行中。

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

在我看来,修复bug有50-75%的机会引入新的bug,特别是如果代码没有被测试用例覆盖的话。我肯定会再核实一次。

从未 假设问题已得到独立(即,不是由修复问题的人员)的验证。

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

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

在我参与过的项目中(敏捷和非敏捷),错误修复总是由其他人验证的。经常会引入新的bug,因此需要对修复进行一些探索。我甚至看到一些调试代码在构建过程中被遗忘了——所有的工作都很好,但是额外的文件不知从何处出现。

也可能是开发人员没有找到bug的所有路径,或者bug报告太不清楚,以至于开发人员进行了错误的修复——例如,如果某些东西被误解了,正确的功能被报告为bug。

为了确保事情在完成后仍能继续进行,修复测试也应该添加到您的自动测试中——否则一些令人尴尬的角落案例错误将在数月后重新出现。