-1

根据这个 Scrum Sprint 描述，已知 Sprint 有 30 天，但也可以短至一周。这如何与持续部署相适应。使用 CD，您可以在完成整合后立即发布已完成的故事。

是否可以进行 2 周的 sprint，但不是在 sprint 结束时“交付”已完成的故事，而是表明它们已经交付？实际上，您可能已经在整个 sprint 中释放了它们。

问题在于，在整个 sprint 中集成和发布并不能让团队规划 sprint。它允许管理层推动团队发布发布、偷工减料和推出代码。

4

5 回答 5

1

在 Sprint 开始时，团队需要与产品负责人达成协议，他们将在 Sprint 期间生产哪些项目（无论多长时间）。这发生在 Sprint 计划会议上，因为某种原因（涉及到计划）。

在 Sprint 期间，团队交付承诺的项目——如果他们承诺整合项目并将它们投入生产，那就是他们所做的。Scrum 本身并没有规定什么时候可以或不可以进入产品——这取决于团队和产品负责人。

Scrum 的一个基本理念是，一旦 Sprint 开始，团队以外的任何人（包括产品负责人）都不得更改团队将在 Sprint 期间工作的项目。

于 2011-07-13T21:39:33.770 回答
0

Short answer is No. The process model you are describing is more like Kanban than Scrum. With Kanban, the team releases items as soon as they pass through the final stage - in your case this is the Integration stage. With Scrum, the PO has to decide at the end of the sprint whether to release the increment or not. Releasing items mid-sprint is not a best practice in Scrum.

于 2011-07-15T23:29:50.013 回答
0

所以这里是 Scrum.org 培训师名单上讨论的结果（到目前为止，我相信其他人会回应）。我必须说我同意清单上所说的内容，并在我之前的回答中发现错误，因为我忘记了一个非常重要的角度。

您可能还记得，尽管很多人不记得，Sprint 应该有一个总体的、有点模糊的目标。许多或大多数（但不是全部）产品待办列表项存在于实现目标中。我经常使用的简单示例是：我们希望增加应用程序的社交网络存在。PBI 的范围可能从显示 Twitter 提要到喜欢产品，以及一些 Google+ 集成等。

该目标为我们为什么要构建这些东西提供了指导，但它也允许业务和团队在我们无法完成某些 PBI 的情况下决定冲刺是否成功。例如，如果我们完成了 Twitter 提要和 Facebook Like 的集成，但无法预见的 API 稳定性问题使我们无法解决 Google+ 集成，那么业务可能仍会在 sprint 中取得成功，因为我们实际上已经在我们的应用程序中“增加了社交网络的存在”。

作为团队成员，这是一个简单而自然的角度，因为它给了我们一个机会。在高压环境中，我们总是习惯性地渴望得到一些东西。真正重要的角度是从业务的角度来看，我忘记了这是一名编码员。

如果我们在完成后发送 Twitter 提要，然后在完成后发送 Facebook 集成，但在 Google+ 集成上失败，这可能是企业觉得我们错过了目标。现在这是一个人为的例子，但可以将其视为非常重要的事情，例如抽奖、在线游戏、短信彩票等多渠道营销活动。缺少其中一个或多个可能意味着商机已经过去，因为他们围绕着奥运会什么的。企业确实以这种方式工作。

连续流模型可能很棒，因为他们会看到以前从未见过的事情发生，但 Scrum 的目标并不是为企业提供一台运转良好的机器和节奏。

于 2011-07-14T04:36:47.573 回答
0

如果Done意味着在生产中，则将其发货。

为什么团队不能计划？他们知道运输是任何 PBI 完成标准的一部分，因此，无论长度如何，Sprint 的规模和规划都应该考虑到这一点。

管理层总是有可能会以牺牲团队对完成的定义为代价来推动更快的步伐，但是团队、Scrum Master 和产品负责人（Scrum 团队）有义务与管理层一起解决推动力的来源.

于 2011-07-13T19:23:53.530 回答
0

我觉得我现在明白 Scrum 不是敏捷的，因为持续部署是敏捷的核心，而 Scrum 是大约 1 到 4 周的发布点节奏，产品负责人在 sprint 结束时做出决定，不是以连续的中期冲刺方式。

事实上，维基百科指出“Scrum ......经常出现在敏捷软件开发中”，暗示并非总是如此，当然也不是同义词。

我想预发布的软件开发，或者具有自然发布周期的非基于服务器的软件，可以灵活到 CI 完成的程度，并且仍然可以使用 Scrum 进行管理。

Scrum 介于瀑布和敏捷之间。比瀑布好得多，更接近敏捷，但不是敏捷。

瀑布：几个大的长冲刺 Scrum：管理较小的冲刺敏捷：连续冲刺

于 2011-07-16T02:07:25.717 回答