我使用 Scrum 从事敏捷项目。
冲刺来了又去，我们成功地完成了里程碑。该系统运行良好，足以满足当前客户的要求。
然而，我们留下了一个严重需要重构的系统，因为大部分开发都是在几乎没有关注未来的情况下进行的（相反，重点是手头的 sprint）。
如何最好地处理这个问题？Sprint(s) 致力于重构？
问问题
886 次
5 回答
25
是的，偶尔的其中一个有时并不是一件坏事。但是，如果您使用 Scrum 很敏捷，那么您可能正在尝试遵循测试驱动开发 (TDD)，重要的是要记住该序列是红-绿-重构，而不仅仅是红-绿。质量差的代码不是敏捷开发的结果，而是敏捷开发差的结果。
于 2010-01-26T22:56:24.863 回答
8
你有“完成”的定义吗？
当您完成编码并准备签入时，您应该已经满足团队对“完成”的定义
除其他事项外，此定义应包括满足您的验收标准/代码审查/测试审查/并满足商定的编码标准。
如果在几个 sprint 之后您的代码库需要认真重构，我建议您对完成需求审查的定义。
这是 Scrum Alliance 的一篇文章，关于定义你的“完成的定义”
于 2010-01-27T02:50:07.090 回答
7
您不一定需要将整个 sprint 用于重构，它也可以在任务级别上工作。当您有一个故事需要处理一些毛茸茸的代码时，请在该故事中包含一个重构任务，作为对该部分进行任何明智操作的先决条件。这样，您可以在功能方面取得进展，但也可以逐步完成一些重构。
于 2010-01-26T23:17:30.237 回答
5
对于我的团队，我通常大约每三到四个月开始一次重构冲刺。考虑到我们运行 2 周的 sprint，大约每 7 个 sprint 就有一个重构 sprint。
我像任何其他 sprint 一样运行重构 sprint - 严格的 2 周时间限制。有时我们甚至只运行 1 周的重构冲刺（当紧急情况出现时）。
关于重构冲刺的注意事项：不要太雄心勃勃：
- 意识到重构是一个无限循环：你总能找到更好的方法来做事。
- 如果只重构需要重构的内容的 10%，也可以。
- 像对待任何其他故事一样对待重构，这样您就被迫优先考虑要重构的内容并识别代码中最需要重构的地方。唯一的区别是，对于重构故事，我让开发人员设置优先级。
- 部分重构仍然会使您的代码处于比完全不重构更好的状态。另外，它往往使进一步的重构更容易。
- 在处理故事时，即使在重构冲刺之外，重构也会发生，但前提是重构是一种容易实现的成果，不会干扰故事的完成。
这是我个人用作重构指南的内容。它不仅使重构变得易于管理，而且还可以作为您过度使用时的一个很好的指标。
于 2010-01-26T23:35:57.467 回答
3
在我工作的地方，我们将有专门针对错误和技术债务的 sprint 。它对于改进事物很有效，并且在一定程度上具有持续改进的精神。
这里还需要考虑的是是否有客户想要但尚未请求的增强功能。客户是否真的对当前系统感到满意，或者它是否工作得足够好以至于他不想抱怨？
于 2010-01-26T23:05:29.047 回答