logo标签列表

Scrum和重构

scrum
18

如果Scrum中的所有事情都关乎用户可以看到的功能性内容，那么与任何新的功能需求无关的重构代码是否真的有其存在的意义呢？

4
这是一个编程问题吗？还是你只是对参加Scrum会议感到沮丧？ - RubyDubee
6个回答
21

我认为这与Scrum并不那么相关，而是与项目管理哲学有关。

无论项目是否使用Scrum，许多项目经理都不喜欢开发人员花时间在“不必要”的事情上，比如代码重构或重组，这些事情并没有直接推进尚未完成的功能要求之一。这不像正常开发一样“产生结果的工作”，而是“防止以后延迟结果的工作”。考虑到Sprint通常使用的短期时间表，其好处往往难以看到，几乎不可能量化。

保持代码可维护性需要成为您Burn-down list（如果使用Scrum）中的一个项目。它和新开发一样重要。虽然它可能看起来不像是对用户“可见”的东西，但忽略它将增加您的技术债务。当技术债务足够累积，以至于您的代码缺乏可维护性会减缓开发速度时，新功能开发的延迟将被客户看到。

这完全是管理/哲学问题。与其将重构和可维护性增强视为不影响客户的“额外”工作，不如将其视为投入时间，以防止客户可见的延迟（以及潜在的错误）。开发人员有时可以比管理人员更清楚地看到这些好处；如果您的经理不了解忽略可维护性的缺点，您可能需要与其他几个开发人员一起与经理交流。

5
我认为在以下情况下，进行技术债务重构是有道理的：维护代码的努力/成本影响与改进质量或使其更好/正确的重构成本相当甚至更高 - 具体而言，是为了提高可维护性。例如：如果软件存在严重问题导致失去客户或金钱，您将迅速采取措施修复它。一些人可能会认为这是业务要求，但通常不会放在小到中等开发项目的核心位置，而是专注于创建应用程序的技术细节，而不是应用程序质量对底线的影响。
4

我想你可能是在谈论大规模重构，而不是在整个红绿重构周期中持续进行的重构。

我的方法是这样的，如果重构旧功能使添加新功能变得更容易，那就去做。但在某些方面，你是正确的，如果没有特定单元需要改变（即完全完成，再也不会改变，并且永远不会影响其他模块），则没有实际需要重构。然而，我很少找到一个如此最终化的模块。

4
如果Scrum中的一切都是用户可以看到的功能性东西，那么任何项目和方法论都应该是为了产生商业价值，在商业环境下很少只是为了好玩而做事情。话虽如此，我认为Scrum（以及其他敏捷方法）中的质量是长期不降低速度、最终实现超级生产力的一种方式。因此，我认为典型的“完成定义”应该包括像“不增加技术债务”（将您的质量标准放入其中）这样的内容。如果您认为新功能将影响现有代码，需要进行重构，请在估算中包含此成本（或在产品待办列表中创建一个重构项），并向产品所有者解释情况。因为最终，由产品所有者来优先考虑项目并决定是否可以暂时牺牲质量（如果您不发布某个功能，您的业务就会死亡，那么重构现有代码还有什么意义呢？）。但他必须意识到这不能成为长期策略，否则他将会降低团队速度。
4
bta: 无论项目是否使用Scrum，许多项目经理都不喜欢开发人员花时间在“不必要”的事情上，比如重构或重组代码，这些并不能直接推进突出的功能需求。
这是一个值得注意的观察结果；我的解决方案如下：
  • 进行定期的代码审查。每次代码审查都应该推荐改进代码中的缺陷。
  • 现在有了提高代码质量的工作要求。将它们纳入迭代，并像跟踪其他工作一样跟踪它们。
如果您的经理需要更多的说服力，请将“维护者”设想为用户，并为他们描述一些用户故事-然后“特性”就是诸如“代码完全带有XML文档注释”和“代码不会产生任何来自ReSharper的警告”的内容。
1
如果你能够将其作为完成其他任务的过程中，通过识别当前代码集的问题/风险来证明它，并且这是更好的最终结果，请去做。但不要过度热衷并影响时间表/预算。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接