在Scrum冲刺中发布的频率

在冲刺期间释放的频率。仅在冲刺结束时或每次功能就绪时。以及如何处理错误修正版本？

TL; DR：在适当的时候发布

只要发布有价值，我们就会发布。有时，这意味着在完成单个功能或错误修正后进行发布。有时，这意味着发布功能和/或错误修正的集合。

这并不意味着我们经常会有需要快速发布的“紧急情况”。这意味着我们已经努力使发布变得容易。我们的代码在每个版本中都经过测试，标记和打包。我们使用自动验收测试，因此，我们对通过测试的代码形成了高度的信心。由于我们的软件包可通过本地yum存储库立即提供，因此部署发行版很简单。

永远不要。这违反了“冲刺”的基本前提。您将运行直到完成承诺的操作。完成后，它确实完成并且可以正常工作。然后可以释放它。

Release可以是一种单独的sprint，其中打包了要发布的东西。

Bugfix版本可能只是短距离的冲刺。许多人认为，没有规律的等长冲刺赛程是一个坏主意。因此，通常的规则是，错误修复只是在下一个冲刺期间发生的高优先级工作。

如果是紧急情况，那么您要做的事情太多了-支持和开发-您应该考虑更改组织以减少发生的事情。

如果团队致力于的工作有利于在sprint中进行多个发布，请根据需要多次发布。

缺陷修复版本也是如此-如果有必要发布它们，请这样做。

我从事的最后一项敏捷工作释放了每个冲刺。每隔一个星期四（两周冲刺）冻结代码，然后将产品打包并发布到UAT服务器，供我们的客户使用。这是在产品的最初开发期间；对于成熟的产品（尤其是可分发的程序而不是Web应用程序），您可能不想让用户负担每两到三周进行一次升级。

实际上，我们所有的发行版都包含故事点和缺陷（错误）的混合。缺陷计为“非理想时间”；在一个工作日中有5个理想的小时，这意味着对新点工作进行平视编码。每天另外三到四个小时是会议，讨论，设计，有时是“尖峰”（重点研究/概念验证开发）和缺陷工作。有助于更好的产品的东西，并且是过程中必不可少的一部分，但根本无法占用整个团队的整个冲刺。我们唯一的缺陷发布版本是在IPM的积压工作中没有故事点工作的情况。然后我们只是安排了一次质量检查冲刺，要求我们“杀死尽可能多的缺陷”。因为没有准备就绪的需求总是采购订单的错误（并且采购订单为客户服务），我们可以简单地签发合同变更通知书并使用我们现有的书。当然，一旦实际的故事工作结束了，我们进入了“保修”开发阶段，那么缺陷就全部存在了。

在一个管理良好的敏捷项目中，永远不会耗尽需求。待办事项列表应始终准备好冲刺的工作价值。但是，有时PO会淹没生产要求；有时，由于与需求质量或故事冲突有关的原因，BA /测试人员会阻止将故事发布到开发积压中；有时，一个团队决定他们必须“挑剔”一个没有明确定义或没有正确估计的故事，并且没有可以轻易占用剩余周期的东西。简而言之，即使在敏捷中，也会发生狗屎事件。

您发布的意思是什么？如果您指的是PSP-可能是可发货的产品，则有两种选择：

• 逐书Scrum（或Scrum级别2），您在冲刺结束时具有PSP，这就是您在回顾会议上显示的内容
• 我还达到了Scrum级别3的学期，在那里团队精通了诸如源代码控制和持续集成之类的工具，并转向了持续交付。这样的团队能够在每个夜间构建（或最佳情况下的每个构建）之后获得PSP。在每次构建后都拥有PSP并不意味着您在每次构建后都将其展示给客户-它仍然只是内部发行。

第2级和第3级之间的主要区别在于，在第2级中，您必须付出一定的努力才能在冲刺结束时制作最终的PSP，但在第3级中，您首先要在工具和配置上投入一些金钱和精力，并且已经准备好PSP始终自动=无需人工。完全达到3级的情况很少见。

Scrum中绝对没有关于何时部署新功能的规则。每个团队都需要有一个“完成的定义”，其中应该始终包含一些有关测试的标准。功能“完成”后，就可以为现实世界做好准备了，如果在部署功能之前不需要满足任何其他依赖关系或条件，那么就没有理由等待Sprint结束了。部署它。

这些都不意味着它不会在Sprint审查/计划会议上展示。其概念是将团队完成的所有事情都显示给PO（以及其他客户SME），以便他们可以将其纳入对系统发展的日益了解中。

几周后，我们找到了适合我们需求的好的解决方案。我们决定随时释放。我们如何做到这一点：

1. 每当有人决定发布实际的developer分支时，他都会将master分支中的所有更改与新的发布编号标记在一起，并推送到我们的登台系统中。
2. 而不是我们的质量检查团队和其他所有团队都会收到一封包含实际变更日志的邮件，他们会测试登台系统
3. 如果他们发现错误，我们将其修复在母版中，将其推送到暂存，然后将母版合并回develop分支
4. 当登台系统通过质量检查后，主机开始运行

而已。我们使用git和maven作为CI系统，并且具有良好的测试覆盖率。这就是我们可以这样做的原因之一。

回答将近2年的问题可能有点多余，但是希望为遇到此问题的其他人增加价值，我想加2分左右。:)

要回答这个问题：您最好在该Sprint的末尾释放该Sprint中的承诺。这样做与Scrum的所有其他其他部分/过程/指南联系在一起，旨在在适当的时候获得最佳的业务价值。

但是紧急情况，错误，意外事件等可能会迫使您动手，如果“发布计划”的概念可以派上用场，那就可以了。对于“发布计划”，我并不是指瀑布式的计划，而是期望的计划，这可以帮助管理产品积压和冲刺中故事的优先级。

但是，也许大卫对这个问题的评论是最好的考虑。Scrum并不总是正确的答案。