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

Question

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

Answer 1

在我们的团队中，我们积极管理技术债务。我们做Scrum，所以我们为当前迭代或下一次迭代生成一张技术债务卡，具体取决于估计和剩余sprint容量，并且它们的优先级与功能和bug卡完全相同。我们还通过处理跨团队的技术债务来管理更大型的跨团队债务项目，我们在其Sprint计划期间优先考虑并注入到每个Scrum团队中。

Answer 2

管理技术债务的一个方面是说服非技术管理人员需要时间分配重构和修复bug。

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

Answer 3

如果你正在努力弥补旧罪，我认为安排时间处理技术债务是很重要的，但我也认为你不应该把它当作一种习惯。一旦你清理了这个烂摊子，你应该避免让你的项目陷入更多的债务，除非你有充足的理由这样做。

像迈克所说的那样积极地管理它似乎是最合理的方法，但我认为（向您的团队）明确说明您不应该安排时间或计划长期重构。

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

Answer 4

这取决于产品的很多。当我在我们的代码必须被外部审核的领域工作时，这是我们冲刺计划的一部分。 PM只是问发展需要重构哪些领域，并将其纳入计划。这并不是说你不会在你正在开发的领域修复代码，但是你不会花一整天的时间来重写一个有效的代码块。现在我正在Scrum中工作，开发人员只是在工作时才这样做。我的印象是，无论从哪一方面来看，重构工作都需要花费相同的时间。

Answer 5

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

Answer 6

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

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

Answer 7

如果您迟到了发布周期，您不想过多地更改代码库。这意味着总会有一些技术债务。我通常为不理想的变化编写FIXME：s，然后在开始实施下一个版本的功能之前，我会照顾它们。

Answer 8

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

Answer 9

如果我真的需要堆积技术债务，因为我现在需要发布一些东西，所以我提出了一个关于它的重要bug，所以它得到最高优先级。但是，只有在极端的情况下（客户在上下跳动，妻子正在寻找丁当等）。

Answer 10

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

关于技术债务的一个非常重要的方面是，它不仅涉及开发人员，还涉及管理。从这个意义上讲，我意识到处理这个问题的最好方法就是让“非技术项目利益相关者”可以看到他们，他们可以分配时间和资源来管理技术债务，一旦他们理解了它的含义。

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