13

Scrum 的挑战之一是如何将 QA 融入流程中。当然，在 Sprint 期间，QA 与开发人员一起处理每个单独的用户故事，但是在完全完成的 sprint 中让 QA 有时间在发布到生产环境之前进行完整的回归和负载测试呢？

我见过两种方法：

  1. 在 Sprint 的最后一天投入生产；或者
  2. Sprint 一周后投入生产

这两种方法都有它们的挑战，所以我想知道大多数商店在每个 Sprint 发布时都会做什么？

4

4 回答 4

14

这两种方法都有它们的挑战，所以我想知道大多数商店在每个 Sprint 发布时都会做什么？

在我看来，Scrum 的最终目标是能够在Sprint结束后发布新的增量。换句话说，Sprint 的结果是一个可发布的增量（不是已发布的增量）。

所以选项 #1 对我来说似乎有点太早了（我们的产品待办列表项目在 Sprint 结束时完成，但在演示之前，我们在完成的定义中不包括“发布到生产”，因为这是' 不是真的在我们的控制之下，这是另一个团队的工作）。

不知何故，我认为选项 #2 意味着您没有在您的 DONE 定义中包含“DONE DONE”所需的所有内容。我绝对不是说这很容易做到，并且很可能需要一些时间才能真正包含所有必需的步骤以在您的“完成定义”中实现可发布，并进行必要的组织更改以实现目标。

就个人而言，我仍然没有真正达到这种流动性水平（在每个 Sprint 中发布），虽然在每个 Sprint （IST、UAT）期间完成了一部分 QA，但我们实际上每 2 周的 4 个 sprint 发布一次，最后一个 Sprint 是一种带有“特殊”产品待办列表项目的发布 Sprint，例如执行负载测试、必要时进行优化（尽管现在没有太多令人惊讶的事情）、编写文档（为生产团队、为用户）。缩短发布周期需要进行更深入的更改，而这目前无法完成，在我们的案例中实际上也不需要。当然，您的上下文肯定是不同的。

也可以看看

相关问题：

于 2010-08-29T05:01:36.190 回答
3

这取决于行业、市场和许多其他因素。没有单一的答案。请记住，Scrum 是一个框架，它并不适合所有. 我最常看到解决方案＃1。

在冲刺结束时，您应该有一个潜在可发布的产品版本。它在小型初创公司或小公司中效果很好。这是他们的竞争优势之一。QA 人员可以很容易地加入团队。当软件不重要时，这可以在大公司中实现（解决方案#2）。

我已经在一个安全至关重要的大型企业中实施了 Scrum。由于法规和认证限制，在冲刺之后发布是不可能的。你必须经历一个漫长的发布过程，开发人员必须参与其中。我们必须解决这个问题。

但在大多数软件工厂中，他们可以在演示后发布，并且几乎可以一键发布。当您使这成为可能时，您将获得迭代开发的所有力量，这是一个非常大的竞争优势。

从商业的角度来看，在每次迭代结束时不发布也是一个好习惯。

于 2010-08-29T08:54:24.637 回答
1

如果我可以谦虚地假设您在软件行业，那么您的问题的答案或您的问题的解决方案将是使用具有可靠项目发布计划和项目时间表计划的企业 Scrum 模型。

应该有一个运营支持 Scrum 团队，其中可能包括数据库管理员、应用程序服务器管理员、高级 QA 人员和高级生产支持分析师。该团队可能会为开发 Scrum 团队负责完整的 QA 回归和负载测试、发布管理、代码部署和其他运营支持活动。另一方面，开发 Scrum 团队只会生产可发布的软件并将其放在架子上供运营支持团队使用。

在您的这种特殊情况下，运营支持团队将在他们的产品待办列表列表中包含待办事项，以便为开发团队生产的搁置产品进行回归测试和负载测试活动 - 注意回归理想情况下应该是开发过程的一部分！！！

现在，发布每个 Sprint 的组织需要让运营团队落后于开发团队一周或 2 周，因此例如，如果 Scrum 开发团队正在处理 2.0 版代码，那么运营支持团队应该部署开发团队的 1.0 版代码团队在 2 周前完成了“搁置”。

底线是发布计划需要制定正确的时间表。Scrum 中可能存在一种误解，即每个 Scrum 团队都有自己的发布计划，因为他们是自我管理的，并且他们会进行自己的部署等，这在一定程度上可能是正确的，但团队计划需要适应以及项目范围的发布计划，并且需要相应地适应时间表。

根据项目时间表协调时间表和组织积压工作的责任主要落在 PO 和 SM 的肩上，SM 负责培训 PO 如何最有效地完成这项工作。所以简单的答案是 = 2 周是开发团队和运营团队进行 QA 或发布活动之间的一个很好的间隔，但时间线和间隔应该根据项目需要进行调整。

如果您需要更多详细信息，请询问。讨论这个问题的对话会更容易解释，但我希望这能回答你的问题。顺便说一句，在 Sprint 结束后的第二天发布（给 PROD）对于开发团队来说是一个坏主意，但你可以随时尝试并检查和适应；）并且 1 周是一个足够好的差距，但取决于你的应用程序有多大，你的数据有多大，还有你有多少资源。

谢谢，席德·特朗。认证 Scrum Master

于 2010-09-23T20:21:56.327 回答
0

我的理解是，重要的是在 sprint 结束时“完成”，而不必在另一个 sprint 中承担“技术债务”，人们可能不得不返工以前发布的软件。

于 2010-09-15T07:21:39.573 回答