颠覆分支与多个Scrum团队

Question

因此，我们对如何处理有关并行Scrum团队冲刺的源代码有不同意见。背景信息是我们有两个7人团队在同一产品发布的2周迭代中处理相同的代码基线。

团队A：在一个阵营中，我们首选的方法是：每个团队在自己的分支中工作，如果更改可以接受，则在每个sprint结束时合并到主干。原因是团队A不想冒B团队引入错误代码的风险。

B队：在另一个阵营中，我们首选的方法是：两个团队都在后备箱中工作，尽早并经常检查小型工作变更集，并依靠持续集成构建来尽早预防和识别损坏的构建。 B队不希望每隔几周进行一次大型合并。

思考？这两种方法都比另一方更有效吗？是否有团队推荐的第三种方法？

编辑：只是为了澄清两个团队都想要CI，但是团队A将有多个夜间构建，每个分支一个。 B队赞成单一分支上的单一构建。

感谢〜

Answer 1

在涉及人员的任何正常情况下，合并将很快被推迟“直到我们稳定了这一件事”。这一件事很快就会稳定下来，所以分支机构开始出现分歧。一开始并不坏，但很快你会注意到你将合并和稳定冲刺。这就是我在所有项目中发生的事情，我看到分支被用于这样的事情。

在上面两个选项中，我建议立即咬掉子弹，然后使用选项B.它会产生一些开销，但至少人们在他们仍然记得他们正在做什么以及他们为什么做的时候会立即合并他们的变化。在几周内，它会变得更加困难。

解决方案C可以是为两个团队提取具有公共代码的第三个项目，让每个团队的主动开发部分随意修改。共享代码库应该更加稳定。不知道这样的解决方案是否适用于您的情况。

Answer 2

团队B.你正在引入开销 - 大型合并 - 以避免经常不会发生的假设情况（“坏代码”），如果确实如此，将导致更少的工作纠正比所有的合并都会积累。此外，这些合并本身可能会引入错误。

简而言之，您正在添加更多工作来处理未经证实的问题，最终可能导致更多工作。

另一方面，如果团队B（或者A就此而言）正在检查错误的代码，那么捕获它的地方就在CI中，如果他们 引入了错误的代码，那就是管理问题，而非程序问题。

Answer 3

为什么不让B队在主干和A队的分支上工作？每个人都得到他们想要的东西！ （开个玩笑：这与方法A没什么不同）

但是，说实话，你正试图在“孤岛工作”和“只有一个庞大的团队”（或更具外交性：“稳定的工作空间”和“主动协作”）之间做出选择。 我建议采用混合方法。但我同意Kai Inkinen的想法，即将代码库重构为共享代码与特定于团队的代码。您的团队足够大，他们生成的代码将是重要的：更多的组件是有意义的，并可能完全避免这个问题。假设你没有这个选项：

A的一些缺点：

• （想想：第2周结束时后备箱会是什么样子？你对这段代码有多大的信心？）
• 鼓励在短跑结束时“大肆宣传”合并（实际上你正在计划它！）。合并后会出现冲突，重复工作和次优代码结构。
• 阻止团队利用其他团队做出的良好更改
• 在sprint结束时：谁先合并到trunk？那个团队可能一直都在行李箱上！

B的一些缺点：

• （想想：B队想要分享他们之间的变化，但这些变化对于主干还不够好。你知道会发生这种情况，或者为什么还有两支球队呢？）< / LI>
• 不鼓励频繁登记
• 鼓励“工作副本转移”
• 每当B队的某个人“打破”代码库时，A队就会说“我告诉过你了”

我的建议方法：

• 让两个团队使用不同的分支机构，以鼓励每个团队频繁签到。签到好。 （如果一个团队（A）希望保护他们的代码，他们会找到实现相同目的的方法，即使你没有给他们一个分支，即工作副本转移：“嘿，金，我知道它并不完美，你尚未检查它，但是你可以把你的修复程序发给我吗？“）
• 让两支球队经常“交付”到后备箱：不仅仅是在冲刺结束时。完成后发送每个“故事”。
• 让两队经常从主干“同步”（理想情况是在每次“交付”之后从其他球队）。这与上面的操作相结合，使合并尽可能小，并且应该使sprint的结束完全无痛。 A队可能会抵制这一点;应该鼓励他们在代码中“响应变化” - 他们最终必须合并。

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.stayinsync

通过这种方法，团队将获得奖励（相对容易的合并），以便经常和检查，以便尽快向主干进行更改。这些都是好事。

我还应该指出，使用像git / Mercurial这样的东西，你会有更多的灵活性。

Answer 4

我会继续进行整合。这样做的理由很少。查看Martin Fowler的this链接，了解它的优点。