在敏捷开发中,您如何处理以冲刺为中心的思维导致的"不太精心设计"的代码

Question

我使用Scrum开展敏捷项目.

短跑已经过去了,我们已经成功实现了里程碑.该系统运行良好,足以满足当前客户的要求.

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

如何最好地处理这个？Sprint(s)致力于重构？

Answer 1

是的,偶尔的其中一个有时并不是坏事.但如果您使用Scrum敏捷,那么您可能会尝试遵循测试驱动开发(TDD),重要的是您要记住序列是红绿色重构,而不仅仅是红绿色.质量差的代码不是敏捷开发的输出,而是敏捷开发的不良.

我不同意,TDD并不经常将架构良好的系统等同起来.此外,TDD应该用作"适当时"的方法.虽然我同意红绿折射器,但我相信有很多人会因此而被挂起,因此显着延长了开发时间.TDD非常适合专注于应用程序的微小部分.它显然会扩展并发展成一个设计得更好的工作流程,但这并不总能带来良好的宏观设计.Sprint级折射器对此至关重要. (2认同)
@Chance:(1)**任何**方法应用不当或误用都会导致系统架构和编写不当.(2)TDD是一种通常在整体敏捷过程中应用的开发方法,如果你阅读它,我的评论谈到了**敏捷开发的输出**,而不是特定的TDD.如果您尝试使用TDD解决更高级别的问题,比如架构问题,那么您将失败.TDD并不等同于设计良好的系统,就像驾驶测试无法测量烹饪煎蛋的能力一样!但做得好TDD不会**加剧这种情况. (2认同)

Answer 2

你有'完成'的定义吗？

当您完成编码并准备办理登机手续后,您应该已经满足了团队对"完成"的定义

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

如果在几次冲刺之后您的代码库需要严格的重构,我建议您对完成的定义需要进行审核.

以下是Scrum联盟关于定义"完成定义"的文章

Answer 3

您不一定需要将整个sprint用于重构,它也可以在任务级别工作.当你有一个需要使用一些毛茸茸的代码的故事时,在该故事中包含一个重构任务,作为使该部分做出任何合理的事情的先决条件.这样,您可以在功能上取得进步,但也可以逐步完成一些重构.

Answer 4

对于我的团队,我通常每三到四个月开始一次重构冲刺.考虑到我们进行了为期两周的冲刺,这是一次重构冲刺,大约每七次冲刺.

我像任何其他冲刺一样运行重构冲刺 - 严格的2周时间限制.有时我们甚至只运行一周的重构冲刺(当出现紧急情况时).

关于重构冲刺的说明:不要过于雄心勃勃:

这是我个人用作重构的指南.它不仅可以使重构成为可管理的,而且还可以作为一个很好的指标,当你过度使用它时.