Scrum中是否允许随机重构代码

背景

• 我的团队使用Scrum
• 我目前没有分配任务
• 积压中没有其他待处理任务
• 今天是我的客户的劳动节。

今天没有很多事情要做，我想开始重构一些代码，我一直在我正在处理的项目中看到这些代码，但是目前我没有分配给任何sprint任务来进行任何大规模重构。

如果我开始随机重构已经拥有的代码并且一直没有写出总是困扰我但又没有时间因为其他日子的分配而修复它的代码，在Scrum中可以吗？

那我在两次冲刺之间有空闲时间的其他日子呢？

实际上，我确实相信连续重构。我总是在分配故事时使用我正在工作的代码段，但是我看到的其他一些当前与当时正在处理的代码无关的代码又如何呢？

我真的不是要攻击其他答案，但是没有其他人在这里编写自动化测试吗？ 这是马丁·福勒（Martin Fowler）的有趣读物，适用于没有适当软件工程实践的任何Scrum使用者。罗伯特·C·马丁（Robert C. Martin）在这里也说了很多。

所以，对我的回答...总之，它是这样的：

是的，只要团队决定应该这样做，Scrum中就允许使用“随机”重构代码。（毕竟，这是自组织的）

现在长答案：

显然，每次Sprint之后留下越来越多的技术债务是灾难的根源。很快，随着代码变得更加混乱，每个人都会放慢速度；每次更改都会更难进行，因为代码太纠结且混乱，以至于发现要更改的地方比进行实际更改要花费更长的时间。如果您必须更改一个您不知道的大而混乱的模块，情况将变得更加糟糕，在项目中添加/切换人员时，无法获得/保持生产力，等等。

如果团队想要保持稳定的速度，他们必须能够保持代码库干净，以便不断增加软件。如果您想在项目的整个生命周期中保持速度，并且想要减轻在项目上增加/更换人员的风险，并且希望能够在模块中进行更改，那么重构是强制性的做法等等。

但是，重构是非常危险的活动。我再说一遍-这是非常危险的活动。也就是说，除非您具有足够的测试覆盖范围，以能够安全，自由地更改代码库。如果您只需要按一下按钮以检查是否一切正常，那么重构就非常安全。实际上，它非常安全，因此它是TDD周期的一部分，这是一种实践，它允许您首先创建这样的测试套件。

但是，由于Scrum中的团队正在自我组织，最后，您的团队必须决定正确的做法。我希望在您必须说服任何人的情况下给您一些论点。（请特别注意第一段中的链接以及它们指向的所有其他文章）

Scrum并没有真正谈论重构。

Scrum的意思是，如果您在sprint中没有任何要处理的任务，则应该支持团队的其他成员以实现sprint目标。即使那意味着为他们拿咖啡。
如果您的团队同意重构代码是您支持代码的最佳方法（并且包括适当的基础结构以确保重构不会引入太多新的错误），那么一定要这么做。

我会说不，不是。这与工作类型（重构等）无关。

至少应创建任务并将其推送到当前的Sprint中。时间跟踪的目的是捕获您的速度，以便有效地规划将来的冲刺。如果您在不跟踪的情况下进行工作，将会影响速度，并且随着时间的推移它不会如预期的那样好转（因为您的预计速度小于实际速度，因此您可能会经常没有足够的工作量） ）。

至于重构工作本身，我可以对此进行长篇大论，但是我不会，因为我不认为这是您要回答的核心问题。

我也不会说。如果没有正确地管理重构，重构常常会导致意外的错误。

作为总经理，我会定期将每个人都放在另一个项目上，并花一个星期的时间对项目进行代码审查/重构/重命名和执行约定。这些重构冲刺在本质上几乎总是很漂亮。任何功能重构都将提前计划，并由原始开发人员参与。

功能重组应该始终作为Scrum流程的一部分进行计划和协调，以便可以跟踪时间，并且所有必要的团队成员都可以用来验证流程。一个开发人员不应放弃更改另一条偏离正常轨道编写的代码，因为它很可能会使每个人都陷入混乱。特别是在代码合并时间方面。

如果您是项目的唯一维护者，并且是您自己的空闲时间，那么假设您采取措施确保不会对当前的sprint造成不必要的延迟，则可能会有所不同。

如有疑问，请询问您的经理。

编辑：我还想提到，您不喜欢的给定代码段可能具有与之相关的特定性能目标。您可能不喜欢它，但是它可能比您可以根据自己的使用方式构建的任何东西都快。功能重构应该始终是托管过程的另一个原因。

Scrum并没有对重构进行任何说明（请参阅Robert C. Martin的演讲，“ Scrum遗忘的土地”）。

在Scrum中，任务是针对客户指定的软件功能，而不是要通过重构偿还的技术债务。这些是完全不同的抽象级别。客户大多无法评估必要性。

Scrum是统计项目管理。为了获得有意义的“花费多长时间”的度量，您必须了解性能（每个sprint的输出）。您将至少一个冲刺（sprint）以上的功能的估计值与实际持续时间进行比较，以进入统计数据。我建议5个冲刺。但这取决于您的团队。

最主要的是保持措施有意义并具有可比性，以使任何预测成为可能。如果由于技术债务导致业绩下降，情况就不会如此。

如果您现在仍然想到重构任务，那么您将遇到两个问题：1.一个不了解客户的原因，为什么他必须接受不会产生新功能的任务2.您完全扭曲了统计数据，因此无法预测当您突然更改先前冲刺中未考虑的其他变量时

在这两种情况下，您都希望与客户讨论功能时折衷Scrum的想法，并对“需要多长时间？”做出可靠的预测。以统计的方式。为了安全起见，您必须保持代码库的质量恒定（也许很高）。

在大多数情况下，重构是一项地下任务。“出色的”重构意味着过去从未处理过“很少的”重构。

最后一点：如果进行重构，请确保您要重构的组件在测试中。哦，您还没有测试？做一个任务来编写测试。您的客户很高兴得知他当前使用的软件没有足够的测试范围...

让技术人员远离客户，并作为专业开发人员来工作。

这是一种方法：两者都做！

重构通常很容易出错，或者耗时更长，正如@misterbiscuit指出的那样。

因此，请考虑尝试进行草稿或尖峰处理。在此阶段，您无需寻求批准或做广告。

然后，通过以下两个渠道之一将其包括在内：

• 现有的票证触及相同的代码/功能，您可以在其中合理地打包。与团队其他成员达成的合理协议。
• 整张票，以便在下一次票务梳理时（或瀑布下的每周会议等）进行审查。那时您可以为此提供理由。

获得实际认可后，您可以尝试应用或重做峰值，并将实际代码合并到主线（主等）分支中。

这将具有几个优点：

• 您的所有代码均通过相同的过程进行测试，质量检查，发布管道等。
• 您可以从产品经理那里得到正式的支持，重构是技术的一部分，而不是需要在假期中“混入”的东西。问自己，为什么不“偷偷摸摸”实际功能可能有助于透视。
• 您可以要求配对，代码审查，质量保证，开发和其他所有因式分解代码更改所需的支持。根据政策和程序及以上规定，所有程序均为正式程序。
• 如果您是一家符合SOX要求的上市公司，则可能希望/需要执行这种正式流程（即记录下来然后遵循它）。
• 您在产品经理（快速完成更改）和开发团队（代码库得到了改进）中都享有更好的声誉。
• 该组织正在寻求关心代码质量，这对于生产力，士气，员工保留和其他许多原因都有好处。
• 当包括所有工作时，可以更轻松地跟踪对项目速度的影响。可以不指定任何点，因为存在本身可以用来影响速度。
• 开发人员很可能会发现鼓励简化代码审查的工具，例如Fisheye，Github等。
• 开发人员更有可能发现一些基本标准（有时记录在案，有时没有记录），这些标准使共享代码并因此更容易重构。有时，重构的很大一部分是选择一种样式，然后将其广泛应用（用一种方法替代各种方法）。

最后的评论：避免产品经理听到“随机”一词。他们可能会通过“有针对性的，战略性的，性能增强的”代码升级做出更有利的响应。或应用程序服务包。或任何语言都可以覆盖您。

随机重构没有任何意义。有意义的是重构将带来最大收益的代码。这意味着：

• 解决设计或架构问题
• 改善实施

如果我开始随机重构已经拥有的代码并且一直没有写出总是困扰我但又没有时间因为其他日子的分配而修复它的代码，在Scrum中可以吗？

从这个答案：

保持代码可维护性必须成为您的精简清单上的一项（如果您使用Scrum）。它与新开发一样重要。尽管它看起来似乎不是“用户可见”的东西，但忽略它会增加您的技术负担。当技术债台高筑，使您的代码缺乏可维护性会减慢开发速度时，客户就会看到新功能开发的延迟。

在我以前的工作中，我们有一些混乱，冲刺较大（2-3个月）。由于两次冲刺之间有一些延迟（1个月），因此我们利用这段时间来分析软件并重构代码。