首先对无代码问题感到抱歉，但我想澄清一件事。
我的团队中有一位高级开发人员正在积极推动代码质量 - 合并请求审查，没有糟糕的代码和类似的。但是团队中的大多数其他人都有 - 完成了该死的心态。作为一个商务人士，我根本不检查代码，但如果我没有那个关心质量的人——在我看来，我们会在某个时候遇到一些繁重的重构周期。
但是，过分关注质量当然也有不利的一面——这只是需要时间。当我们必须随着业务需求的变化而调整时，也许我们将不得不抛出很多漂亮的代码。
两个问题：a) 你如何保持产品的质量？你使用什么做法？b) 足够关心代码质量的界限在哪里（不是太少也不是太多）？
代码质量很重要，与您是否开发敏捷无关。你说得对，质量改进需要额外的时间。大多数人失败是因为他们花时间在更大的块（“重构项目”）上或多或少地清理任意位置的代码，目的是尽可能减少质量问题的数量。
我建议使用的过程是遵循童子军规则，始终使更改的代码比以前更干净（更好）。这意味着每当您更改函数、过程、方法或其他代码单元时，都要修复其中的质量问题。优点是您已经理解了代码（因为无论如何您都必须更改它）并且它将被测试（因为您需要测试原始更改）。这意味着质量改进的额外努力（添加评论、改进标识符、删除冗余......）非常低。此外，您只改进您正在使用的代码，而不是浪费时间改进从未接触过的代码。
遵循童子军规则可确保质量不会下降，而是会随着时间的推移而稳步提高。这也是一个合理的“关怀”水平。我在这里写了更多关于此的内容。此外，您还需要像Teamscale这样的高质量分析工具，能够可靠地区分遗留问题、新问题和您最近更改的代码中的问题。
获取并实施良好的单元测试框架，并通过自动化集成测试对其进行备份。
至于敏捷，我发现早上 10 分钟的 scrums 很有用，但冲刺结束会议往往很长。
我使用Sonar Qube获得了很好的体验，这是我们用于静态代码分析的工具。所以我们可以在我们的代码库中跟踪代码异味等。另一点是，可以在冲刺中计划解决问题！IDE 集成也可用！