当产品负责人要求发布时，如何避免干扰工作流程？

Question

我的团队多年来一直在使用Scrum，目标是为每个sprint提供一个可能发布的构建。我们最近开始使用看板，将时间限制的交付转移到功能盒交付。到目前为止，这似乎更符合团队的自然工作方式。随着功能盒的交付，当一个人觉得他们已经准备好开始写故事的时候，故事就会从积压中提取出来。

球队的平均故事准备时间是三周。因此，从理论上讲，在产品负责人要求发布的时候，团队应该能够在三周后发布。

当PO设置“停止开发”触发器时，有时间的个人应该开始帮助已经在进行中的故事开始清除董事会。先被释放的人通常是“前端”的人.更擅长分析和开发的人。他们通常被要求帮助后端工作，比如系统测试。

每次设置停止触发器时，团队的工作流程或节奏都会发生变化。您如何最大限度地减少这种变化，并使团队尽可能高效地工作？如何避免产品负责人要求发布所造成的干扰？

Answer 1

您描述它为发行版做准备的方式是对您的工作流程的一次重大的中断，而这种中断似乎不起作用。

由于我们对团队提出了类似的要求，我们介绍了以下解决方案。这主要与您的版本控制系统中的分支管理有关。在我看来，这个概念被称为“在干线上没有垃圾”。它基本上意味着您有一个“干净”的分支，因为它只包含成功通过质量保证(QA)的工作。使用Subversion，这个分支可能被称为‘主干’，因此它的名字。当然，这也适用于其他版本控制系统，例如GIT。

当我们开始处理一个新特性时，我们就创建了一个功能分支。此功能分支每天至少从主干中进行一次合并更新，以将差异保持在最低限度。所有的测试，质量保证，签署由各方完全完成的特点分支.功能完成后，它将被合并回“主干”，然后进行快速集成测试，重点关注新特性与已经存在的功能集成的位置。

当我们发布时，我们从“主干”中创建释放分支。因为‘后备箱’是‘干净’，我们几乎可以在任何时候释放。由于发行版并不依赖于删除看板上的所有故事，所以我们可以随时准备一个版本，而不会中断常规的开发工作流程。

这一过程对我们非常有效。创建发布分支需要大约10秒，因为它是完全自动化的。发行分支中最重要的项目是审查以英语为母语的人的发行说明。不幸的是，这是一个手动过程，根据新版本中新特性和错误修复的数量，它需要大约一到两个小时。

与往常一样，您的环境中可能有一些因素可能会使其他挑战解决方案成为更好的选择。