0

我工作的公司一直在一个项目上试用 Scrum,现在正在寻求将 scum 推广到三四个不同的项目团队。我们设想这些团队将在不同的功能分支中工作(我们使用的是 SVN)。

我们不确定不同团队的 sprint 是否应该同时结束,或者我们是否应该错开 sprint 以便 sprint 结束和发布是分开的。该产品是一个网站,因此部署不是问题。

我们关心代码集成,如果三个团队同时集成他们的代码,这是否容易导致冲突。但是如果发布是错开的,那么这个负载可能只会转移到处于冲刺中期的团队。

有没有人尝试过这两种方法,他们发现什么有效?

4

3 回答 3

1

我们也有几个团队,我们的 sprint 是一致的,并且我们不断整合:当一个故事完成时。这有时很烦人,但这样我们就可以避免长时间的集成,这可能是痛苦的。每个故事都在一个单独的分支中开发,然后集成到主分支中。当两个团队需要共享未集成的东西时,他们会在同一个分支中工作。

我们正在构建一个打包产品,因此部署对我们来说不是问题。

这两个问题联系在一起:如果你只在冲刺结束时进行整合,我不建议这样做,那么你最好错开冲刺。

Henrik Kniberg(Scrum 和 XP 的作者来自战壕)写了一篇关于多个敏捷团队的版本控制的文章。

于 2009-03-21T17:22:03.910 回答
0

我们有两个同步冲刺的团队,它似乎工作得很好。我们的策略是保持故事小。完成故事并在冲刺期间经常将它们发布到主干。是的,我们确实遇到了合并冲突,但它们是可控的。

哦,并确保团队之间相互沟通良好。

于 2009-03-20T15:35:21.507 回答
0

看看这篇文章,简洁地解释了这些问题。http://www.infoq.com/news/2008/04/kniberg-agile-version-control

持续集成。始终集成,每次签到时,不要等到一天结束或迭代结束时才集成。在每次签入时运行单元测试和自动化验收测试,以确保没有人破坏代码。

计划较小的功能,处理较小的工作。当事情破裂时,较小的块更容易修复。是否所有团队都在同一产品/代码行上工作?您可以尝试规划功能,以便这些功能不会影响其他团队正在开发的功能。尝试参加其他团队的站立会议,以便更早地解决集成冲突。如果功能冲突,请分享工作。

于 2009-03-21T17:31:02.690 回答