如何将QA集成到Sprint中

  这两种方法都有它们的挑战所以我想知道大多数商店在每个Sprint上发布了什么？ 在我看来，Scrum的最终目标是能够在Sprint结束后发布新的增量。换句话说，Sprint的结果是可释放的增量（不是释放的增量）。 因此选项＃1对我来说似乎有点太早了（我们的产品Backlog项目是在Sprint结束时完成的，但是在演示之前，我们在“完成定义”中不包括“发布到生产”，因为这不是真的在我们的控制之下，这是另一支球队的工作。 不知何故，我认为选项＃2意味着你没有在你的DONE定义中包含所有要求“DONE DONE”的内容。我绝对不是说这很容易做，而且很可能需要一些时间来真正包含所有必需的步骤，以便在您的“完成定义”中实现可释放性并进行必要的组织变更以实现目标。 就个人而言，我仍然没有真正达到这种流动性水平（在每个Sprint发布），虽然QA的一部分是在每个Sprint（IST，UAT）期间完成的，但我们实际上每4个冲刺发布2周，最后一个Sprint是一种发布Sprint的“特殊”产品Backlog项目，如执行负载测试，必要时进行优化（尽管现在没有太多不好的意外），编写文档（针对生产团队，针对用户）。缩短发布周期需要进行更深层次的更改，这在目前尚无法完成，在我们的案例中实际上并不需要。当然，你的背景肯定是不同的。 也可以看看 Sprint期间质量保证的陷阱？ 相关问题： 敏捷（Scrum + XP）团队中QA /测试的最佳实践？ 帮助我了解QA在Scrum中的工作原理 将bug修复融入Scrum流程的最佳方法是什么？     

这取决于行业，市场和许多其他因素。没有一个答案。记住Scrum是一个框架，并不适合所有人。我已经看到解决方案＃1在行动中最多。 在sprint结束时，您应该有一个可能可释放的产品版本。它在小型初创公司或小公司中运作良好。这是他们的竞争优势之一。 QA人员可以轻松地加入团队。当软件不重要时，可以在大公司中实现这一点（解决方案＃2）。 我已经在一个安全性至关重要的大型企业中实施了scrum。由于法规和认证限制，在冲刺后发布是不可能的。你不得不进行一个长期的发布过程，开发人员必须参与其中。我们必须与之合作。 但在大多数软件工厂中，他们可以在演示后发布，几乎只需点击一下。当您实现这一目标时，您将获得迭代开发的所有功能，并且这是一个非常大的竞争优势。 从商业角度来看，在每次迭代结束时不发布也是一种很好的做法。     

如果我谦虚地假设您在软件行业，那么您的问题的答案或问题的解决方案将是使用企业Scrum模型以及可靠的项目发布计划和项目时间表计划。 应该有一个Operations Support Scrum Team，其中可能包括数据库管理员，Application Server管理员，高级QA人员和高级生产支持分析师。该团队可以负责开发Scrum团队的完整QA回归和负载测试，发布管理，代码部署和其他运营支持活动。另一方面，开发Scrum团队只会生成可释放的软件，并将其放在运营支持团队的架子上。 在您的这种特定情况下，运营支持团队将在其产品待办事项列表中包含Backlog，以对开发团队生成的搁置产品进行回归测试和负载测试活动 - 注意回归理想情况下应该是开发过程的一部分！ 现在，发布每个Sprint的组织需要让运营团队落后于开发团队一周或两周，因此，例如，如果Scrum开发团队正在开发Release 2.0代码，那么运营支持团队应该部署Release 1.0代码团队在2周前完成了“搁置”。 最重要的是，需要使用正确的时间表布置发布计划。在Scrum中可能存在一种误解，即每个Scrum团队都有自己的发布计划，因为它们是自我管理的，并且他们会进行自己的部署等，这在某种程度上可能是正确的，但是团队计划需要适合还有项目范围的发布计划，时间表需要相应地适应。 根据项目时间表协调时间表和组织积压工作的责任主要在于PO和SM的背景，SM负责培训PO如何最有效地完成这项工作。如此简单的答案= 2周是开发团队和运营团队之间进行质量保证或发布活动的良好差距，但应根据项目需求调整时间线和差距。 如果您需要更多详细信息，请询问。讨论这个的对话会更容易解释，但我希望这能回答你的问题。顺便说一句，在Sprint结束后的第二天发布（对PROD）开发团队是一个坏主意，但我总是可以尝试并检查和适应;）和1周是一个很好的差距，但取决于您的应用程序有多大，数据有多大，以及您拥有多少资源。 谢谢Sid Telang。认证的Scrum Master     

我的理解是，在冲刺结束时“完成”并且不必在另一个冲刺中进行“技术债务”非常重要，因为人们不得不重新修改以前发布的软件。