deployment - Scrum 方法中如何处理部署过程？

Question

我们正在使用 scrum 方法开发一个复杂的系统，其中包含 1 周的 sprint 和一个由 6 名开发人员组成的团队。

当更改在开发分支上进行测试和集成时，我们会不断更新每台开发人员机器上的源代码，并且开发人员每天都会将更改集成到测试公共服务器上。

但是生产系统对于任何问题或停机时间都非常关键，会导致大量损失，而且部署过程缓慢、艰难和微妙。即使系统更改经过测试甚至部署到测试服务器，当我们尝试大量发布整个一周的进度时，有时也会出现问题。因此，我们选择了之前的部署过程，该过程发生在整个一周的开发完成并部署到测试服务器之后。我们在测试服务器上对整周的更改运行全功能测试，然后将周工作批次发布到预生产服务器，然后有时一切正常，但有时在部署过程或发布的更改上出现一些新问题，然后我们计划高度精细的生产过程，我们可以在第二天晚上执行，避免客户工作的任何停机时间。

现在，我们正在与客户进行讨论，因为他辩称这不是 scrum，因为他没有在 scrum 当天获得 sprint 结果，而是在三天后获得。但是很明显，我们不能在 sprint 完全完成之前开始预发布和发布过程——所以，第二天——然后系统的复杂性和关键性迫使我们将部署过程安全到顶部，客户生产使用也需要一些特殊的操作调度。

我们是否违反了 Scrum 指南？Scrum 方法的部署过程在哪里？Scrum 适合这个项目吗？

标签： deploymentscrum

Answer 1

部署过程缓慢、艰难而微妙。

当部署过程很困难时，这往往意味着组织部署的频率较低。如果他们不经常部署，那么发布就会变得更大、更困难和更关键。这往往意味着更不愿意释放。

这种负面循环不利于敏捷，因为它意味着组织难以应对变化。

你能做的最好的事情就是尝试通过改进发布过程来打破这个循环。这可能很困难并且会耗费时间和资源，但好处是显着的。

如果您可以自动化发布，那么您往往会降低风险。随着风险降低，更频繁地发布成为可能。频繁发布意味着减少了发布的大小，并且您可以在必要时快速修复错误。

频繁发布也让客户更快乐，因为他们有更多机会提供反馈。他们提供的反馈越多，产品就越早成为他们想要的。

也许一个好的起点是自动化您当前对公共测试服务器所做的发布。一旦你这样做了一段时间，你应该有信心在生产中使用相同的过程。