你是否积极管理技术债务？

Question

您是否积极管理软件开发项目的technical debt债务？若然，您是如何做到的？

Answer 1

管理技术债务的一个方面是让非技术管理人员相信你需要时间来分配重构和修复错误。

Here's an article with specific suggestions关于如何做到这一点。

Answer 2

在我们的团队中，我们积极管理技术债务。我们做Scrum，所以我们根据估计和我们剩余的冲刺容量为当前迭代或下一次迭代产生技术债务卡，并且它们像功能和错误卡一样被优先考虑。我们还通过交叉团队积压技术债务来管理更大的跨团队债务项目，我们优先考虑并在sprint计划期间注入每个Scrum团队。

Answer 3

我认为，如果你想要弥补旧的罪行，安排时间来处理技术债务是很重要的，但我也认为你不应该养成这个习惯。一旦你清理了混乱，你应该避免让你的项目承担更多的债务，除非你有充分的理由这样做。

像迈克建议的那样积极地管理它似乎是最合理的方法，但我认为（对你的团队）明确你不应该安排时间或计划从长远来看重构是非常重要的。

重构应该是编写代码的自然部分，因此应该包含在您的其他估算和计划中，而不应被视为单独的活动 - 除非您必须，即出于“历史”原因或因为您有意识地决定以某种方式实现某些东西，然后再重新实现它。

Answer 4

你做的是创造一种文化，除非在极端情况下，技术债务是不可接受的。就像那些只支付现金并仅将信用作为绝对的最后手段的人一样。

Answer 5

如果我真的需要积累技术债务，因为我现在需要发布一些东西，我提出了一个关于它的关键错误，所以它得到了最高优先级。但它只适用于极端情况（客户上下跳跃，妻子正在寻找dingbat等。）。

Answer 6

这很大程度上取决于产品。当我在一个我们的代码必须在外部审计的领域工作时，它是我们冲刺的计划部分。 PM刚刚询问开发需要重构的区域，并将其纳入计划。这并不是说你不会修改你正在处理的区域中的代码，但你不会花一天时间来重写一个有效的代码块。现在我在scrum工作，开发人员只是在工作时这样做。我的印象是，无论哪种方式，重构工作的时间都相同。

Answer 7

我同意安德斯的观点。如果您必须设置管理技术债务的系统，那意味着您仍在添加它。通过升级“完成”的定义，首先停止负债。

这确实意味着“负债”模块将更难以解决。开发人员应该意识到这一点，并分配更多的故事点，以便他们将事情“完成”。

Answer 8

如果您迟到发布周期，则不希望过多地更改代码库。这意味着总会有一些技术债务。我通常会写FIXME：s以获得不太理想的更改，然后在开始为下一个版本实现功能之前我会处理它们。

Answer 9

Java Posse最近涵盖了Technical Debt的管理，这看起来非常全面。

Answer 10

在我迄今参与的项目中，一些技术债务仅在项目新阶段开始时“支付”（管理），即在“大发布”或里程碑之后。

技术债务的一个非常重要的方面是它不仅涉及开发商，还涉及管理层。从这个意义上说，我知道解决这个问题的最佳方法是让“非技术项目利益相关者”可以看到这些利益相关者，他们可能会在理解其影响后分配时间和资源来管理技术债务。

这article讨论了几种类型的技术债务，哪些可能是健康的，特别是如何管理和跟踪技术债务负担。