Scrum和重构

作者: 荧惑
发布时间: 2025-02-04 11:27:01 (11天前)
转自：

6 条回复

0#
回复此人
只怕再见是故人 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <BLOCKQUOTE> <P> 的<strong> BTA： </强> 无论项目是否使用Scrum，许多项目经理都不喜欢开发人员花时间处理代码重构或重组等“不必要”的事情，而这些事情并未直接推进其中一项突出的功能需求。 </p> </BLOCKQUOTE> <P> 绝对是一个值得注意的观察;我对此的解决方案如下： </p> <UL> <LI> 定期进行代码审查。每次代码审查都应该建议采取措施来改进代码中的缺陷。 </LI> <LI> 现在需要提高代码质量的工作。将这些构建到sprint中并以与任何其他作业相同的方式跟踪它们。 </LI> </UL> <P> 如果您的经理需要更有说服力，将“维护者”作为用户进行投射，并为他们描述一些用户故事 - 然后“功能”就像“代码完全注释了xml doc comments”和“代码不会”从ReSharper发出任何警告 </p> </DIV>

编辑
1#
回复此人
࿏自ོ༾由ོ༽人͙⃡⌇ | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <BLOCKQUOTE> <P> 如果Scrum中的所有内容都与用户可以看到的功能性内容有关（...） </p> </BLOCKQUOTE> <P> 的<strong> 任何 </强> 项目和方法应该是关于产生的的<strong> 商业价值 </强> ，你很少只为了商业环境中的乐趣而做事。话虽如此，我认为Scrum（和其他敏捷方法）的质量是一种不会长期阻止你的速度，并最终实现超高效率的方法。因此，我认为典型的“完成定义”应该包括“不增加技术债务”（将质量标准放在那里）。如果您认为新功能会影响应重构的现有代码，请在估算中包含此成本（或在产品Backlog中创建重构项）并向产品负责人解释。因为最终，由产品负责人决定项目的优先级并决定是否可以暂时牺牲质量（如果您的业务因为没有发布功能而死亡，那么重构现有代码的重点是什么？）。但是他必须意识到这不是一个长期战略，否则他会扼杀团队的速度。 </p> </DIV>

编辑
2#
回复此人
日耀九洲 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 我想你可能正在谈论大规模的重构，而不是在整个红绿重构循环中你会做的连续重构。 </p> <P> 我的方法就是这样，如果重新构建旧功能可以更容易地添加新功能，那么继续执行。但在某些方面你是正确的，如果特定单位没有压力要改变（即它完全完成并且永远不会再改变并且永远不会影响其他模块）那么就没有实际的重构需求。但是我很少找到一个完全如此定型的模块。 </p> </DIV>

编辑
3#
回复此人
撩心 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 如果您可以通过使用当前代码集识别问题/风险来完成其他任务的过程中的一部分，并且这是一个更好的最终结果，那就去做吧。但是，不要过度热心并搞砸时间表/预算。 </p> </DIV>

编辑
4#
回复此人
圈圈红 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 我不认为这与Scrum和项目管理理念有很大关系。 </p> <P> 无论项目是否使用Scrum，许多项目经理都不喜欢开发人员花时间处理代码重构或重组等“不必要”的事情，而这些事情并未直接推进其中一项突出的功能需求。这不是“正常开发产生结果的工作”，而是“防止结果延迟的工作”。鉴于Sprint通常使用的时间通常很短，因此通常很难看到这种好处，而且几乎无法量化。 </p> <P> 保持代码可维护性需要成为刻录列表中的项目（如果使用Scrum）。它与新开发同样重要。虽然它可能看起来不像“用户可见”，但忽略它会增加您的技术债务。当技术债务累积到足以使您的代码缺乏可维护性减缓开发时，新功能开发的延迟 <EM> 将 </EM> 对客户可见。 </p> <P> 这完全是管理/哲学的问题。不要将重构和可维护性增强视为不会影响客户的“额外”工作，而应将其视为时间投资，以防止客户明显的延迟（以及潜在的错误）。开发人员有时可以比管理者更清楚地看到这些好处;如果您的经理不理解忽视可维护性的缺点，您可能想要抓住其他几位开发人员并与您的经理聊天。 </p> </DIV>

编辑

登录后才能参与评论