Scrum中的技术债务：真实场景

技术债务是为实现短期目标而采取的设计和实现捷径所积累的成本——这些捷径降低了代码库的质量、可维护性或性能，最终必须通过重构、返工或增加维护工作来偿还。在Scrum中，技术债务是一个特别常见的问题，因为Sprint-by-Sprint的交付节奏持续产生快速交付工作功能的压力，这可能导致跨Sprint积累的捷径。

场景：一个软件产品团队

一个Scrum团队正在为政府机构构建一个网络应用程序。产品负责人优先考虑面向用户的功能，因为利益相关者对可见进度感到满意。开发团队一贯满足Sprint目标。

技术债务如何积累

当团队遇到需要大量重构才能干净解决的复杂问题时，他们选择更简单的变通方法，以避免威胁Sprint目标。变通方法有效，Sprint目标达到了，但代码中留下了一个TODO注释，指出变通方法应该被正确替换。经过八个月，代码库有：三个独立的身份验证实现；两种不同的数据访问模式；以及覆盖率40%的测试套件。

症状

• 速度下降：团队的Sprint速度从第三个月的每Sprint 45个故事点下降到第八个月的28个故事点。新功能需要更长时间构建，因为开发人员必须驾驭积累的复杂性。

• 缺陷率增加：缺陷率在同一期间增加了两倍。变通方法和不一致的模式使代码库变得脆弱，难以更改而不引入回归。

• 入职困难：一名新开发人员在第七个月加入团队，难以提高生产力。代码库复杂、文档不足且不一致。

如何在Scrum中解决技术债务

• 使技术债务可见。创建技术债务待办列表——已知债务项目的专用列表，包括所需重构工作的粗略估计和遗留它的业务影响。将其带到Sprint规划和待办列表细化中。

• 为减少债务分配容量。一个常用的启发式方法是将20%的Sprint容量分配给技术债务减少。这可以防止债务积累情况恶化，同时仍然交付功能。

• 应用童子军规则。将代码留在比你发现时更好的状态。在代码库的某个区域工作时，随时清理相邻的债务。增量改进会随时间复合。

• 在产品待办列表中包含技术故事。技术重构工作应该与用户故事一起出现在产品待办列表中。产品负责人应该了解技术债务对速度和质量的影响，并相应地优先处理债务减少。

XNM为公共部门组织提供Scrum辅导和敏捷交付顾问服务。欢迎联系XNM项目群与项目交付咨询团队，探讨贵组织的技术债务管理和Scrum实施。