【发布时间】：2008-10-23 14:53:18
【问题描述】：
在我们的 Scrum 板上，任务从“待办事项”开始，转到“进行中”，当您完成一项任务后，它们会转到“待验证”，然后最终进入“完成”。 “待验证”列表示您完成了一项任务，其他人可以查看、测试和评论它。
这已被证明有助于错误、更好的代码等。
对于有类似做法的人：在开发人员解决了 cmets/错误之后，您是否再次验证它，或者您是否假设问题已经解决并将任务移至“完成”？
我希望这很清楚，并想听听您的想法。
【问题讨论】：
【发布时间】：2008-10-23 14:53:18
【问题描述】：
这个问题不是 Scrum 特有的，我在敏捷流程之外也看到过这个问题。
答案是：这取决于验证中提出的问题。如果提出了一些小问题，并且负责的开发人员足够资深，那么相信他会在第一时间解决问题。但是，如果进行验证的人认为项目过于复杂，或者 Scrum Master 缺乏信心相信开发人员第二次就能把它做好，那么你就可以将便利贴移回 In Progress。
简单的拼写错误就是您无需检查的错误类型的一个很好的例子。当有许多相互依赖的边界条件时，您需要再次检查的一个很好的例子是边界条件中的错误。
【讨论】：
在我的有效期内，错误的修复有 50 - 75% 的机会引入新的错误，特别是如果代码没有被测试用例覆盖。我肯定会再次验证它。
【讨论】：
永远不要假设问题已得到解决，直到它被独立（即不是由修复它的人）验证。
【讨论】：
我们没有要验证的列。在实施和测试之前，任务一直在进行。无法完成未经测试的任务，为什么其他人要对其进行测试，向程序员报告，然后程序员必须修复它？这只会增加工作流程的延迟。程序员应该测试自己的代码，尽可能为它编写单元测试，并尽可能将其集成到应用程序中，并在此处作为自然工作流程的一部分对其进行测试。这样他就可以找到自己的错误并立即修复它们。当他将任务设置为“完成”时，他不仅确信已完全实施该任务，而且该任务没有错误。
好的，我们都知道，这意义不大。有时会在很久以后才发现错误，但这些错误并不是那么明显，通常它们的修复将是它自己的任务。
【讨论】：
在我参与的项目中（敏捷和非敏捷），错误修复总是由其他人验证。经常会引入新的错误，因此需要围绕修复进行一些探索。我什至看到在构建中忘记了一些调试代码 - 一切正常，但额外的文件不知从何而来。
也有可能开发人员没有找到错误的所有路径，或者错误报告太不清楚以至于开发人员做了错误的修复 - 例如。如果某些内容被误解，并且正确的功能被报告为错误。
为确保事情在完成后保持完成，还应将修复测试添加到您的自动化测试中 - 否则几个月后一些令人尴尬的极端情况错误将重新出现。
【讨论】：