【问题标题】:What are the crucial key items in recording technical debt?记录技术债务的关键项目是什么?
【发布时间】:2011-04-23 13:49:52
【问题描述】:

我正在 The Office 设置技术债务登记册,并希望使其成为一个相当全面的工具。

我们应该记录哪些关键信息?

【问题讨论】:

  • 天哪,我们只是使用我们正常的问题跟踪系统并用特定的标签/类别标记问题。
  • 喜欢这个问题,期待答案。也许您应该为每个答案指定一个问题,以便我们可以使用投票来查看哪些问题比其他问题更重要?

标签: language-agnostic capacity-planning technical-debt


【解决方案1】:

首先 - 你要让你的寄存器非常简单,否则维护寄存器的开销会阻止人们使用它,并且浪费更多的时间而不是实际修复它本应解决的技术债务解决.....

如果您仍然决定继续,我建议您保留一个简单的寄存器,它是一个包含以下字段的平面文件/简单数据库/Google 电子表格:

  • 模块/组件名称
  • 描述需要修复的内容(您可能有一个类别列表,但我认为这也需要一个文本单行)
  • 估计的修复时间(以天为单位)(我倾向于坚持使用整数天,否则人们会倾向于开始记录琐碎的小事)
  • 哪个开发商承担了债务(并提供了修复时间估算)
  • 债务发生在哪个项目上(任何暗示,由哪个项目经理负责)

规则如下:

  • 预计开发人员对技术债务保持透明。如果开发人员因项目压力需要承担技术债务,开发人员应将其添加到日志中,并附上他们预计的修复时间。
  • 项目经理应对他们产生的技术债务负责(即他们是否迫使开发人员走捷径?)。他们应该能够为总债务增加提供可靠的商业理由,并提出应该采取哪些措施来解决这个问题。
  • 如果未发现技术债务,则代码应具有最高质量并通过任何相关的代码审查。如果记录了技术债务,那么开发人员会获得任何记录的“通过”(审查可能会有助于考虑债务记录的准确性以及应该采取哪些措施来解决问题)。
  • 预计开发人员会对修复时间给出合理的估计。如果他们说重构架构需要两天时间,那么如果他们有两天时间在以后修复它,他们应该不会感到惊讶....

我认为这种方法将创造一个良好的整体动态 - 开发人员有责任保持透明并考虑如何解决技术债务,项目经理/业务主管必须做出权衡,但很明显,债务是他们的责任,最优秀的开发人员和架构师将因完成艰巨的项目而获得赞誉,同时还能控制技术债务。

【讨论】: