Do you actively manage technical debt?您是否积极管理软件开发项目中的技术债务债务，如果是，该如何处理？ 管理技术债务的一个方面是说服非技术经理，您需要分配时间进行重构和错误修复。 这是一篇有关如何执行此操作的具体建议的文章。 在我们的团队中，我们积极管理技术债务。我们做Scrum，所以我们根据估算值和剩余的冲刺容量为当前迭代或下一个迭代生成一个技术债务卡，就像功能和错误卡一样，对它们进行优先级排序。我们还通过跨团队积压的技术债务来管理较大的跨团队债务项目，这些问题在每个Scrum团队的冲刺计划中都得到优先排序并注入到每个Scrum团队中。 我认为安排时间以偿还技术债务很重要，如果您要弥补旧的罪过，但我也认为您不应养成这种习惯。一旦清理了混乱，除非有充分的理由，否则应避免使您的项目承担更多的债务。 像Mike所说的那样积极地管理它似乎是最合理的方法，但是我认为(对您的团队)明确的是，您不应该安排时间或从长远来看计划重构非常重要。 重构应该是编写代码的自然部分，因此应该包含在其他估算和计划中，除非出于"历史"原因或因为您有意识地决定实施给定的东西，否则不应将其视为单独的活动。方式，然后在以后重新实现。 如果真的需要累积技术债务，因为我需要立即发布某些内容，那么我会提交一个严重的错误，因此它具有最高的优先级。但这仅适用于极端情况(客户在上下跳跃，妻子在寻找装饰)。 您要做的是营造一种文化，在这种文化中，除非在极端情况下，否则技术债务是不可接受的。就像只付现金并仅将信贷作为绝对的最后手段的人一样。 在到目前为止我参与的项目中，一些技术债务仅在项目的新阶段开始时才"支付"(管理)，即在"大发行"或里程碑之后。 关于技术债务的一个非常重要的方面是，它不仅涉及开发人员，还涉及管理人员。从这个意义上讲，我知道最好的处理方法是使"非技术项目利益相关者"看到它，他们可以在了解技术问题后分配时间和资源来管理技术债务。 本文讨论了几种类型的技术债务(可能是健康的)，尤其是如何管理和跟踪技术债务负担。 Java Posse最近涵盖了技术债务的管理，该技术看起来非常全面。 如果您处于发布周期的后期，则不想过多更改代码库。这意味着总会有一些技术债务。我通常会为次优的更改编写FIXME：s，然后在开始为下一个版本实现功能之前会照顾好它们。 我同意安德斯的观点。如果必须设置用于管理技术债务的系统，则意味着您仍在添加它。首先，通过升级对"完成"的定义，不再承担债务。 这确实意味着"负债累累"的模块将更难处理。开发人员应该意识到这一点，并分配更多的故事点，以使事情"做完"。 这很大程度上取决于产品。当我在必须对我们的代码进行外部审核的领域中工作时，这是我们冲刺计划中的一部分。 PM只是问开发人员需要重构哪些区域，因此已将其放入计划中。这并不是说您不会在正在处理的区域中修复代码，但是您不会花一天时间来重写大量无法正常工作的代码。现在，我正在Scrum中工作，开发人员在工作时就做到了。我的印象是，无论哪种方式，重构工作大约花费相同的时间。 |
