在敏捷开发中，您如何处理“架构较差”的代码，这些代码是由专注于sprint的思维方式导致的

Question

我使用Scrum参与了一个敏捷项目。

冲刺来来去去，我们已经成功地完成了里程碑。该系统运行良好，足以满足当前客户的要求。

然而，我们留下了一个严重需要重构的系统，因为许多开发都是在很少着眼于未来的情况下进行的(相反，重点是手头的sprint )。

如何最好地处理这个问题？致力于重构的Sprint？

Answer 1

是的，偶尔发生这样的事情有时并不是一件坏事。但是，如果您使用Scrum进行敏捷开发，那么您可能正在尝试遵循测试驱动开发( Test-Driven Development，TDD)，并且重要的是要记住，序列是red-green-refactor，，而不仅仅是红-绿。低质量的代码不是敏捷开发的结果，而是糟糕的敏捷开发的结果。

Answer 2

你对“完成”有什么定义吗？

当您完成编码并准备签入时，您应该已经满足团队对“完成”的定义。

此定义应包括满足您的验收标准/代码审查/测试审查/和商定的编码标准。

如果在几次冲刺之后，你的代码库需要进行认真的重构，我会建议你对已完成的定义进行审查。

这里有一篇来自Scrum联盟的关于定义你的'definition of done'的文章

Answer 3

你不一定要把整个sprint都用在重构上，它也可以在任务级工作。当你有一个故事需要使用一些杂乱无章的代码时，在这个故事中包括一个重构任务，作为使用该部分完成任何合理工作的先决条件。这样一来，你在功能上取得了进步，同时也逐步完成了一些重构。