想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文来回答。
3年前关闭。
Improve this question
这里有一个问题。
开发人员有某种任务(开发某些功能)，大约需要一个 sprint 的长度。因此，在 sprint 结束时，开发人员很高兴，因为他们刚刚完成了他们的部分。
但。该产品不是 QAd，因此不能将其区分为“潜在可交付”，因为它很可能包含一些错误。
所以，问题是:如果没有自动化测试，只有人类 QA 工程师，那么计划冲刺的最佳方法是什么？延迟一个冲刺(QA 测试在上一个冲刺中开发的项目)？
在这种情况下，什么可以帮助我们？开发人员在 QA 过程中应该做什么？
最佳答案
Scrum 的一个非常重要的方面是在 Sprint 期间“完成”事情，以及完成的定义。如果一个功能在冲刺期间完成，但没有经过测试，它仍然没有完成。
你应该 而不是 来解决这个问题是增加你的 Sprint 的长度。短距离冲刺仍然是首选。我建议两件事。
第一个非常重要，但不一定容易实现。将 QA 集成到您的团队中。有一个单独的 QA 部门在你“完成”你的产品后验证你的产品真的是瀑布式的。您可能仍然希望在产品发货前进行 QA 验证，但是在 sprint 中生产的产品应该在 sprint 期间完成并进行测试。为此，您需要合格的 QA 人员成为您团队的一部分 - 或者您需要培训开发人员尽可能地进行 QA。在我公司，我们的 QA 部门太小，所以我们无法为我们的团队提供一些。相反，我们了解了 QA，并在我们的任务板上添加了一个标题为“准备验证”的列。每当一个功能完成时，它就会被转移到“准备验证”，其他一些开发人员会看看这个。尽管我们可能不像专门的 QA 人员那样熟练，但我们一直通过这种方式发现问题，将它们移回进行修复，然后再次进行验证。这个过程让我们对我们在 sprint 中分类为完成的功能更有信心，并且后来发现的错误显着减少。
另一件事是开始定义更小的任务，或者更好地将功能分解成更小的部分。您不想处理根据您的估计可能需要整个 sprint 的功能。如果您“几乎完成”，那么您在 sprint 期间实际上还没有完成任何事情。反而;将特征分解成更小的部分并一一解决。当有人在第 2 部分工作时，第 1 部分正在由其他团队成员之一进行验证，从而使整个开发和 QA 过程更加集成 - 在 sprint 结束时有更好的机会将您的新功能称为“完成”。
祝你好运!
关于scrum - 在 Scrum 方法论中 Sprint 结束时未测试的产品，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/1363964/