如何以敏捷的方式处理~3年未合并的合并代码？

Question

我们的团队最近采用了敏捷实践，而且大多数团队对于敏捷来说都是新的。

在我们的产品中，我们使用另一个团队开发的一些代码，只有他们维护该代码。在过去的4到5年中，以前的开发人员已经合并了他们打算使用的代码，而不是所有的代码。随着时间的推移，我们分支中的代码也是自定义的。三年来，这些代码库一直没有被合并。我们期待着大量的更改和手动冲突解决过程来执行合并，因为我们都是这个代码的新手，而且代码已经不同步很长时间了。

我们应该如何以敏捷的方式来处理这种任务/故事呢？在不确定性很大而且我们不知道会出现多少冲突/bug的情况下，是否有任何准则来处理这些不明确的任务？

编辑:1如果问题不清楚，请耐心等待，在评论中让我知道，我会尽量澄清。所以让我再试一次。

作为一个敏捷团队，我(和团队)到目前为止学到的是，在两个星期的sprint开始之前，我们将与PM讨论需求，了解需要完成的工作，最后确定任何DB设计的方法，如果两个星期sprint开始的话。在某一天，我们还会进行另一次PBR会话，对于当前的sprint，可以提出任何新的关注，或者我们只是继续了解下一个sprint的新故事。在Sprint的最后一天，我们做Sprint，下一天的Sprint回顾展。

最近我认识了单词斯派克。许多敏捷团队使用Spike作为两到三天之间的时间，要么在sprint结束时完成次要的剩余任务，而不需要将整个故事带到下一个sprint。或者有时在sprint开始时完成设计/方法，或者清除概念类事物的证明。

当我(团队)看到这个代码合并任务时，我们似乎无法将这个故事分解为有限的任务，因为90%的事情都是未知的。我们没有围绕代码进行自动化测试，我们以前也没有合并过这段代码，这是SQL端的一次毫无根据的合并。不管我们估计了什么，我们很有可能完成大量的任务。现在，在回顾中，这将成为坏的团队。这样的任务也会干扰团队的速度。

，所以我的问题是，其他人如何在敏捷团队中包含这样的任务。这真的是作为SPRINT执行的吗？或者这应该是团队的一次努力，而不是登录敏捷板？在某种程度上，我正在寻找关于敏捷如何允许执行这样的任务的指导。如果不是斯普林特，还有别的什么吗?

Answer 1

这是一次艰难的考验。

首先，必须合并你不熟悉的代码的两个分支是很困难的。再加上三年的发散发展，你使它成为我想要辞掉的工作；

但我们要保持建设性。

合并冲突没有简单的解决方案。你必须手动解决这些问题。

不幸的是，每次合并冲突都会带来更多的倒退风险。

如果幸运的话，您的代码和要合并的代码将已经具有非常好的自动化测试覆盖率。这一点很重要，因为团队中没有人知道应用程序内部的预期行为是什么。你的测试会让你知道的。

这样做的想法是，在合并两个分支之后，您的自动化测试将突出显示由于合并而产生的任何回归。

另一方面，您可能会感到不走运，并且发现测试覆盖范围很小甚至没有。在这种情况下，您必须开始编写自动化测试。您可以针对您的代码编写这些单元和集成测试，希望其他团队也会同意对他们的代码进行同样的测试。否则，你就得自己动手了。

根据应用程序的大小，在合理的时间内实现100%的功能覆盖可能是不可能的。这里我唯一能提出的建议是专注于最重要的功能，然后花一些时间进行手动回归测试，以涵盖其余的功能。

Answer 2

我同意元，这是一个艰难的问题。

为了抛开相反的观点，你真的需要合并代码吗？

您有两个共享共同祖先的大代码块。他们至少在三年前分手了。这些区块由两个明显互不交谈的独立团体维护。

企业从这种合并努力中得到了什么价值？你知道，这将是昂贵的，困难的，而且需要很长时间。无限期地维护两个代码基可能比花费开发年合并它们更便宜。(生产阶段的代码维护比开发阶段的工作要便宜得多)

Answer 3

在我看来，把它当作合并的一个很大的例子可能是一个很大的错误，它将涉及一组异常长的在合并工具前进行的会话，并按下“接受/拒绝更改”。

相反，我会：

• 花适当的时间，也许一周，阅读这两组代码。
• 决定哪一个有更好的架构和测试；将其称为A系统基线
• 确保系统A有一套不错的自动化测试；可能大部分是集成式的，接近端到端的测试。
• 从system中提取所需的一组功能的列表
• 将这些特性放到系统A待办事项中
• 在实现这些特性时，请考虑挖掘system以获取有用的代码。但实际上，您正在重新实现这些特性，至少要达到正常的测试量；也许更多。
• 当A的子系统成为功能完整的wrt B需求时，在两个系统上将它们转换为产品，丢弃B的这一部分。
• 重复，直到B只剩下一个部分:使A的'do-B‘子系统。