2

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

事实证明，这有助于错误、更好的代码等。

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

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

4

5 回答 5

3

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

于 2008-10-23T14:58:02.220 回答
3

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

答案原来是：这取决于验证中提出的问题。如果提出了一些小问题，并且负责的开发人员足够资深，那么相信他会在第一时间解决问题。但是，如果进行验证的人认为项目过于复杂，或者 Scrum Master 缺乏信心相信开发人员第二次就能把它做好，那么你就把便利贴移回 In Progress。

一个简单的拼写错误就是你不去检查的错误的一个很好的例子。当有许多相互依赖的边界条件时，您将再次检查的一个很好的例子是边界条件中的错误。

于 2008-10-23T15:02:48.950 回答
0

在独立（即不是由修复它的人）验证之前，切勿假设该问题已得到解决。

于 2008-10-23T15:03:33.723 回答
0

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

好吧，我们都知道，这意义不大。有时错误会在很久以后才被发现，但这些错误并不是那么明显，通常它们的修复将是它自己的任务。

于 2008-10-23T15:14:32.280 回答
0

在我参与的项目中（敏捷和非敏捷），错误修复总是由其他人验证。经常会引入新的错误，因此需要围绕修复进行一些探索。我什至看到在构建中忘记了一些调试代码——一切正常，但额外的文件不知从何而来。

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

To ensure things stay done when they are done, tests for the fix should also be added to your automated tests - otherwise some embarrassing corner-case bug will re-appear months later.

于 2008-10-24T13:27:18.863 回答