您是否积极管理您的软件开发项目中的technical debt 债务，如果是，您是如何做到的？
【问题讨论】：
标签： project-management technical-debt
管理技术债务的一个方面是让非技术经理相信您需要分配时间来进行重构和错误修复。
Here's an article with specific suggestions 了解如何做到这一点。
【讨论】：
在我们的团队中，我们积极管理技术债务。我们做 Scrum，所以我们根据估计和我们剩余的 sprint 容量为当前迭代或下一次迭代生成一张技术债务卡，它们像功能和错误卡一样被优先考虑。我们还通过跨团队积压的技术债务来管理更大的跨团队债务项目，我们在每个 Scrum 团队的 sprint 计划期间优先考虑并注入这些债务。
【讨论】：
如果你想弥补旧罪，我认为安排处理技术债务的时间很重要，但我也认为你不应该养成这种习惯。一旦你清理了烂摊子，你应该避免让你的项目陷入更多的债务，除非你有充分的理由这样做。
像 Mike 建议的那样积极管理它似乎是最合理的方法，但我认为（向您的团队）明确说明您不应该安排时间或计划长期重构是非常重要的。
重构应该是编写代码的自然部分，因此应该包含在您的其他估计和计划中，而不是被视为单独的活动——除非您必须这样做，即出于“历史”原因或因为您有意识地决定以给定的方式实现某些东西，然后再重新实现它。
【讨论】：
您所做的是创建一种文化，除非在极端情况下，否则技术债务是不可接受的。就像只支付现金并仅将信用卡用作绝对最后手段的人一样。
【讨论】：
如果我真的需要积累技术债务，因为我需要现在发布一些东西，我会提交一个关于它的严重错误，因此它具有最高优先级。但这仅适用于极端情况（客户上下跳跃，妻子正在寻找装饰物等）。
【讨论】：
这在很大程度上取决于产品。当我在一个我们的代码必须进行外部审计的领域工作时，这是我们 sprint 计划的一部分。 PM 只是询问开发部门需要重构哪些区域，并且已将其放入计划中。这并不是说您不会修复您正在处理的领域中的代码，但您不会花一天时间来重写一个有效的代码块。现在我在 scrum 中工作，开发人员只是在他们工作的时候做。我的印象是，无论哪种方式，重构工作所花费的时间都差不多。
【讨论】：
我同意安德斯的观点。如果您必须建立管理技术债务的系统，这意味着您仍在添加它。通过升级您对“完成”的定义，从一开始就停止负债。
这确实意味着“负债”模块将更难完成。开发人员应该意识到这一点并分配更多的故事点，以便他们将事情“完成”。
【讨论】：
如果您迟到发布周期，您不希望过多地更改代码库。这意味着总会有一些技术债务。我通常为次优的更改编写 FIXME:s，然后在开始为下一个版本实现功能之前处理它们。
【讨论】：
Java Posse 最近介绍了Technical Debt 的管理，看起来很全面。
【讨论】：
在我迄今为止参与的项目中，一些技术债务仅在项目新阶段开始时才“支付”（管理），即在“大版本”或里程碑之后。
关于技术债务的一个非常重要的方面是，它不仅涉及开发人员，还涉及管理。从这个意义上说，我知道处理它的最佳方法是让“非技术项目利益相关者”看到它，一旦他们了解技术债务的含义，他们可能会分配时间和资源来管理技术债务。
此article 讨论了几种类型的技术债务，哪些可能是健康的，特别是如何管理和跟踪技术债务负担。
【讨论】：