在 Scrum 中驾驭技术债务的实用清单
技术债务是你已交付的代码与时间充裕时本应写出的代码之间的差距。它并不总是错误：有时 Scrum 团队会为了赶上发布日期而有意承担债务。真正的危险在于无人追踪的债务。经历了十八个月的远程与混合办公后，我们在 2021 年遇到的许多团队仍背负着早期封锁慌乱中走的捷径，而利息正以交付变慢、缺陷增多的形式逐渐显现。
《Scrum 指南》刻意对工程实践保持沉默，这让团队自行摸索处理债务的方式。这种自由本身没有问题，但往往意味着债务既无归处，也无主人。这份清单旨在借助你已有的 Scrum 事件与工件，为债务同时赋予二者。
让债务可见
看不见的东西无法管理。首要任务是把债务暴露在整个团队和产品负责人日常工作都会遇到的地方。
把债务条目写进产品待办列表，而不是放在工程团队私下的清单里——任何脱离待办列表的事项，都在争夺一份从未分配给它的时间。
用业务语言描述影响：哪项功能会变得有风险，哪项改动会变慢，客户最终会感受到什么。
为债务打上标签，以便筛选和汇报，使其趋势在几个 Sprint 内一目了然。
在“完成的定义”中加入一项简短检查，在新债务产生的当下就将其标记出来，而不是几个月后才发现。
去决策与预算，而非只是被动反应
债务进入待办列表后，产品负责人会把它与其他所有事项一起排序。团队的职责是提供诚实的信息，使这种排序是真实的，而不是猜测。
区分必须修与可以等。 阻碍即将到来的功能、或造成安全与合规风险的债务，与表面性的清理截然不同。要说清楚哪个是哪个。
为每个 Sprint 预留固定的一份。 可预期的配额——比如百分之十到二十的产能——胜过那些永远排不上日程的英雄式清理 Sprint。
把债务挂到触及它的功能上。 当你本就在改动某个模块时，顺手修复其债务，比日后另跑一趟更省。把工作打包在一起。
拒绝无声的权衡。 如果截止日期逼你走捷径，请在 Sprint 收尾前写下由此产生的债务条目，让这个决定被记录而非被遗忘。
每个 Sprint 都检视与调整
债务是 Sprint 回顾会议的常设议题。问一问：债务待办在增长还是缩减，你的“完成的定义”是否真的捕捉到了新债务，预留的产能是真的花在了清理上，还是被悄悄挪去做功能了。远程团队尤其需要这个检查点，因为过去那些在走廊里顺口指出代码杂乱的随意交谈，如今不会自行发生了。
这一切都不需要新工具或新框架。它需要的是把债务当作真实工作：可见于待办列表，由团队负责，并像其他事项一样接受审视。持之以恒，利息便不再复利累积。
如果你的交付团队正背负看不见的债务并因此错过期限，XNM 的项目群与项目交付咨询 可以帮助你让债务变得可见，并制定切实可行的偿还计划。