我工作的公司一直在一个项目上试用 Scrum，现在正在寻求将 scum 推广到三四个不同的项目团队。我们设想这些团队将在不同的功能分支中工作（我们使用的是 SVN）。
我们不确定不同团队的 sprint 是否应该同时结束，或者我们是否应该错开 sprint 以便 sprint 结束和发布是分开的。该产品是一个网站，因此部署不是问题。
我们关心代码集成，如果三个团队同时集成他们的代码，这是否容易导致冲突。但是如果发布是错开的，那么这个负载可能只会转移到处于冲刺中期的团队。
有没有人尝试过这两种方法，他们发现什么有效？
我们也有几个团队，我们的 sprint 是一致的，并且我们不断整合：当一个故事完成时。这有时很烦人，但这样我们就可以避免长时间的集成，这可能是痛苦的。每个故事都在一个单独的分支中开发，然后集成到主分支中。当两个团队需要共享未集成的东西时，他们会在同一个分支中工作。
我们正在构建一个打包产品，因此部署对我们来说不是问题。
这两个问题联系在一起：如果你只在冲刺结束时进行整合，我不建议这样做，那么你最好错开冲刺。
Henrik Kniberg（Scrum 和 XP 的作者来自战壕）写了一篇关于多个敏捷团队的版本控制的文章。
我们有两个同步冲刺的团队，它似乎工作得很好。我们的策略是保持故事小。完成故事并在冲刺期间经常将它们发布到主干。是的，我们确实遇到了合并冲突，但它们是可控的。
哦，并确保团队之间相互沟通良好。
看看这篇文章，简洁地解释了这些问题。http://www.infoq.com/news/2008/04/kniberg-agile-version-control
持续集成。始终集成，每次签到时，不要等到一天结束或迭代结束时才集成。在每次签入时运行单元测试和自动化验收测试，以确保没有人破坏代码。
计划较小的功能，处理较小的工作。当事情破裂时，较小的块更容易修复。是否所有团队都在同一产品/代码行上工作？您可以尝试规划功能，以便这些功能不会影响其他团队正在开发的功能。尝试参加其他团队的站立会议，以便更早地解决集成冲突。如果功能冲突，请分享工作。