Scrum中的技术债务管理：好的做法与不好的做法

技术债务是快捷方式、推迟的重构以及当时正确但此后已成为约束的设计决策的累积代价。每个软件产品都带有一些技术债务；问题在于它是否被管理，或者是否积累到减慢每个Sprint、使新开发成本不成比例地高昂的程度。在Scrum中，技术债务管理主要是产品和团队的责任，而非专业职能。以下介绍团队层面的好的和不好的做法。

好的做法

• 好的做法：完成定义要求技术标准，而非仅功能完成。包含代码审查、最低阈值的单元测试覆盖率，以及对任何有意技术捷径的记录（同时创建Backlog条目来解决该捷径）的完成定义，使债务保持可见且有意识。不可见的技术债务是无法管理的。

• 好的做法：团队为技术债务削减预留Sprint产能的一部分。常见方法是将10%至20%的Sprint产能分配给债务削减工作。具体百分比不如一致性重要：如果每当交付压力增加时债务削减就从Sprint中消失，债务将恰好在团队最不需要时积累。

• 好的做法：技术债务条目在产品Backlog中，对产品负责人可见。产品负责人无法对他们看不到的技术债务条目做出知情的优先级决策。债务条目应以业务后果来表述，使产品负责人能够权衡债务与功能工作。

• 好的做法：团队对什么构成技术债务有共同定义。并非每个不完美的实现都是技术债务；有些只是学习的自然结果，应该置之不理。团队应能区分值得解决的债务和只是陌生的代码。

不好的做法

• 不好的做法：技术债务从不在开发人员回顾之外讨论。如果唯一提到技术债务的时间是开发人员感到沮丧的时候，它就没有被管理，而是在被忍受。

• 不好的做法：完成定义在压力下被降低。随截止日期紧张而改变的完成定义不是定义，而是建议。每个违背完成定义的捷径都增加债务，而积累的债务成为引发捷径的错过截止日期的原因。

• 不好的做法：团队因为"了解代码"而将债务条目重新估算为微不足道。对问题代码的熟悉不会使问题减少；它使问题不那么可见。技术债务往往被最接近它的人低估。

• 不好的做法：技术债务积累到提出大型"清理Sprint"为止。专门的清理Sprint是失败模式，不是策略。它表明债务被允许积累到超出可以增量管理的程度，而清理Sprint的代价通常远高于在多个Sprint中以小增量处理债务的总代价。

XNM协助公共部门及资本项目组织建立可持续的Scrum实践。欢迎联系XNM项目群与项目交付咨询团队，获取敏捷交付项目群的支持。