Scrum Sprint 可以有多短？ [关闭]答案

【问题标题】：How short can a Scrum Sprint be? [closed]Scrum Sprint 可以有多短？ [关闭]
【发布时间】：2011-07-13 04:26:49
【问题描述】：

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

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

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

【问题讨论】：

我投票决定将此问题作为题外话结束，因为project management is now off-topic on Stack Overflow。请在 SoftwareEngineering.SE 和 ProjectManagement.SE 上提出这些问题。（不幸的是，这个问题太老了，无法迁移。）

标签： continuous-integration scrum continuous-deployment

【解决方案1】：

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

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

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

【讨论】：

如果团队拿了一个故事，实现它，根据完成的定义部署它，然后得到另一个故事，然后再做一次，那么冲刺的目的是什么。我并不是想变得粗鲁，但敏捷就是做重要的事情并适应。我不明白 sprint 的重要性，除非它只是作为故事的交付日期。
如果 sprint 中有不止一个故事和时间长度，谁来决定故事的顺序？使用 CD，使用决策矩阵可能是有意义的 - 对业务至关重要，实施的复杂性，首先做高度关键/简单的事情，一般来说，在次要关键之前先做所有高度关键的事情。在我看来，我喜欢制作故事，而 Scrum sprint 并没有多大帮助。
Sprint 的目的是为团队提供一些安全性——在 sprint 期间，经理不能有朝一日说“不要那样做，这更重要”，并且然后回来并在第二天与优先级相矛盾。在 sprint 开始时、在计划会议期间设置的优先级，以及团队在 Sprint 期间可以安全地使用什么。 Product Backlog 由 Product Owner 管理，它应该确定 backlog 项目（可能是用户故事）的优先级。她绝对可以在这样做时使用您描述的那种矩阵。
为了澄清我最后的声明——团队应该在计划会议期间提取它认为可以在冲刺期间完成的所有产品积压项目。这不仅仅是拿上一个，看看情况如何，然后再拿另一个。除此之外，这有助于给团队一种紧迫感——它已经同意在 2 周内完成一定数量的事情——现在它必须交付！设置的时间框也使速度变得明显，因此您可以可靠地预测完成项目需要多长时间。
这可能是因为你觉得你已经大大减少了，或者（不可能，但没有更好的词）消除了开发工作的复杂性。你生产的东西比较相似。冲刺提供了很多东西，但其中包括管理风险和保持可预测性。

【解决方案2】：

如果 Done 表示生产中，则发货。

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

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

【讨论】：

这已成为 Scrum.org 培训师名单上的精彩讨论。我会在这里发布结果。我希望肯能加入。
您能否发送一个链接以使 scrum.org 的那个插件更可信？
抱歉，这不是一个公共邮件列表。

【解决方案3】：

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

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

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

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

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

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

【讨论】：

维基百科说，“Scrum ......在敏捷软件开发中很常见”。敏捷宣言的第一条原则将 CD 描述为敏捷的核心：“我们的首要任务是通过早期和持续交付有价值的软件来满足客户。”那么，如果有人问我们是否敏捷，我以前的一些同事是否会做出回应。 “我们不敏捷，我们是 Scrum。”
不要停留在第一个原则... 第三个原则：“经常交付工作软件，从几周到几个月不等，优先考虑更短的时间范围。”我完全明白你在说什么。持续部署当然是持续交付的一种形式，它强调了对高质量和反馈的警惕性。 Jeff Sutherland 已经讨论了连续流 Scrum（第 111 页，crisp.se/scrum/books/ScrumPapers20070424.pdf）。我可以转发电子邮件链的副本，但我必须询问成员。

【解决方案4】：

简短的回答是否定的。您描述的流程模型更像看板而不是 Scrum。使用看板，团队会在项目通过最后阶段后立即发布项目 - 在您的情况下，这是集成阶段。使用 Scrum，PO 必须在 sprint 结束时决定是否释放增量。在 Sprint 中发布项目并不是 Scrum 的最佳实践。

【讨论】：

感谢您的回复。所以根据这个定义，Scrum 和 CD 是不兼容的。有没有你推荐我看的书或网站来进一步理解这些问题。

【解决方案5】：

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

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

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

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

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

【讨论】：