Scrum 中的技术债：任由其滚雪球的那些错误
技术债是团队在选择眼下更快、更粗糙的方案、并接受日后工作更艰难时所背负的代价。少量、出于深思熟虑而背上的债，可以是一笔明智的权衡。但在 Scrum 中若放任不管，它会悄悄拖慢每一个冲刺，直到团队花在与代码搏斗上的时间多于打造产品的时间。Scrum 框架没有专门针对债务的仪式——而这恰恰是团队任其溜走的原因。下面是反复出现的错误，以及如何在 Scrum 的经验主义内核——透明、检视与调整——之中处理债务。
让债务增长的那些错误
让债务保持隐形。 如果债务只存在于开发者的脑海里，就既无法被检视，也无法被排序。透明是 Scrum 的第一根支柱；看不见的债务，无从管理。
把它当成开发者的私事。 当团队对产品负责人隐瞒债务，就是在不告知业务方的情况下替业务方做权衡决策。产品负责人对产品待办列表排序，必须理解背负这笔债的代价。
薄弱的「完成的定义」。 许多债务只不过是没有测试、没有文档、没有评审就被称作「完成」的工作。严格的「完成的定义」是抑制新增债务最有效的刹车。
等待一个虚无缥缈的清理冲刺。 那个「上线之后再修」的冲刺很少真正到来；下一个优先级总会先一步插队。债务必须在普通冲刺内部一点一点地偿还。
任其无声堆积，然后要求推倒重写。 被忽视的债务最终会以危机的形式爆发，而彻底重写往往是对一个本可由持续维护避免的问题最昂贵、最冒险的回应。
把债务当作一等的待办事项
最干净的做法，是不再把债务视为工作之外的东西。把它作为普通的产品待办事项放进产品待办列表，并以影响来描述：不是「重构支付模块」，而是「把新增一种支付方式的时间从两周缩短到两天，并降低相关的缺陷率」。这样表述后，产品负责人就能在同一把尺子上权衡债务与功能，而这正是单一、有序的待办列表的全部意义所在。开发者带来技术认知；产品负责人就价值做出判断。二者缺一不可。
把习惯嵌入你已有的事件中
你并不需要一个新会议。用冲刺规划在大多数冲刺中有意拉入少量偿债工作，让偿还是稳定的而非英雄式的。用冲刺回顾——团队内建的检视与调整时点——去追问上个冲刺是什么产生了债务、如何不再重蹈覆辙；这正是回顾会议存在的那种流程改进。强化「完成的定义」，从源头上少制造债务。并让这场对话对所有人可见——如今许多团队是隔着屏幕而非围着看板来规划、构建和评审，这一点比以往任何时候都更重要。如此管理之下，债务便成为交付中正常、经过协商的一部分，而不再是以错失冲刺目标的形式浮现的隐形税。
如果你的团队在债务攀升之际难以保持交付的可预测性，XNM 的项目集与项目交付咨询 可以帮你把它重新控制住。