23

您是否积极管理软件开发项目的技术债务,如果是,您是如何做到的?

4

10 回答 10

10

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

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

于 2008-09-10T22:31:53.660 回答
4

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

于 2008-09-10T22:23:53.413 回答
2

如果你想弥补旧罪,我认为安排处理技术债务的时间很重要,但我也认为你不应该养成这种习惯。一旦你清理了烂摊子,你应该避免让你的项目陷入更多的债务,除非你有充分的理由这样做。

像 Mike 建议的那样积极管理它似乎是最合理的方法,但我认为(向您的团队)明确表示您不应该安排时间或计划长期重构是非常重要的。

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

于 2008-09-10T22:56:00.857 回答
1

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

于 2008-12-11T18:27:18.843 回答
1

如果我真的需要积累技术债务,因为我需要现在发布一些东西,我会提交一个关于它的严重错误,所以它得到最高优先级。但这仅适用于极端情况(客户上下跳跃,妻子正在寻找装饰物等)。

于 2009-08-11T11:27:50.507 回答
0

It depends a lot on the product. When I worked in a field where our code had to be outside-audited it was a planned part of our sprint. PM just asked development what area needed refactoring and it was put in the plan. That's not to say you wouldn't fix the code in the area you were working on, but you wouldn't devote a day to rewriting a mangled chunk of code that worked. Now I'm working in scrum and developers just do it as they work. My impression is that about the same amount of time goes into refactoring work, either way.

于 2008-09-30T10:09:48.607 回答
0

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

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

于 2008-12-11T18:53:20.727 回答
0

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

于 2008-12-11T19:07:12.163 回答
0

Java Posse 最近介绍了技术债务的管理,看起来非常全面。

于 2009-08-11T11:12:12.973 回答
0

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

技术债务的一个非常重要的方面是它不仅涉及开发人员,还涉及管理。从这个意义上说,我知道处理它的最佳方法是让“非技术项目利益相关者”看到它,一旦他们了解技术债务的含义,他们可能会分配时间和资源来管理技术债务。

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

于 2013-04-18T15:59:34.100 回答