我们是否积极管理软件开发项目中的技术债务债务，如果是，该如何处理？

解决方案

回答

在我们的团队中，我们积极管理技术债务。我们做Scrum，所以我们根据估算值和剩余的冲刺容量为当前迭代或者下一个迭代生成一个技术债务卡，就像功能和错误卡一样，对它们进行优先级排序。我们还通过跨团队积压的技术债务来管理较大的跨团队债务项目，在每个Scrum团队进行冲刺计划时，我们会优先处理这些问题并将其注入。

回答

管理技术债务的一个方面是说服非技术经理，我们需要分配时间进行重构和错误修复。

这是一篇文章，其中包含有关如何执行此操作的具体建议。

回答

我认为安排时间以解决技术债务很重要，如果我们想弥补旧的罪过，但我也认为我们不应该养成这种习惯。清理混乱之后，除非有充分的理由，否则应避免使项目承担更多的债务。

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

重构应该是编写代码的自然部分，因此应包括在其他估算和计划中，除非出于"历史"原因或者因为我们有意识地决定实施给定的东西，否则不应将其视为单独的活动。方式，然后稍后重新实现。

回答

这在很大程度上取决于产品。当我在必须对我们的代码进行外部审核的领域中工作时，这是我们冲刺计划中的一部分。 PM只是询问开发人员需要重构哪些区域，因此已将其放入计划中。这并不是说我们不会在正在处理的区域中修复代码，但是我们不会花一天时间来重写大量无法正常工作的代码。现在我在scrum中工作，开发人员在工作时就做到了。我的印象是，无论哪种方式，重构工作大约花费相同的时间。

回答

我们要做的是营造一种文化，在这种文化中，除非在极端情况下，否则技术债务是不可接受的。就像只付现金并仅将信贷作为绝对的最后手段的人一样。

回答

我同意安德斯的观点。如果必须设置用于管理技术债务的系统，则意味着我们仍在添加它。首先，通过升级对"完成"的定义，不再承担债务。

这确实意味着"负债累累"的模块将更难处理。开发人员应该意识到这一点，并分配更多的故事点，以使事情一发不可收拾。

回答

如果我们处于发布周期的后期，则不想过多更改代码库。这意味着总会有一些技术债务。我通常为次优的更改编写FIXME：s，然后在开始为下一个版本实现功能之前先照顾好它们。

回答

Java Posse最近涵盖了技术债务的管理，该技术看起来非常全面。

回答

如果我真的需要增加技术债务，因为我需要立即发布某些内容，请提交有关此问题的严重错误，以便将其置于最高优先级。但这仅适用于极端情况(客户在上下跳跃，妻子在寻找装饰)。