Scrum 指南 · 工件与实践
Scrum 中的技术债：如何发现和管理
技术债务是今天所走捷径的未来成本：仓促编写的代码、缺失的测试、过时的工具。就像金融债务一样，少量债务可能有用，但不加管理就会拖慢每一个冲刺。
要点总结
- 技术债务是今天所走捷径的未来成本。
- 在产品待办事项列表中使其可见。
- 用严格的完成的定义防止产生新的技术债务。
技术债务的来源
- 截止日期压力导致走捷径。
- 完成的定义过于宽松。
- 缺少自动化测试。
- 过时的库和基础设施。
- 知识只掌握在一个人手中。
- 设计完成后需求发生了变化。
技术债务增长的迹象
- 下降或不稳定 速度.
- 更多缺陷逃逸到用户手中。
- 简单的变更耗时越来越长。
- 开发人员不愿触碰某些部分。
在 Scrum 中管理技术债务
- 使其可见： 将技术债务条目添加到产品待办事项列表中，并清楚描述其成本。
- 加强完成的定义 ，以免产生新的债务。
- 预留产能 在每个冲刺中预留一部分（例如团队工作量的一定比例）用于偿还技术债务。
- 持续重构 作为常规工作的一部分。
- 在冲刺评审会上讨论 ，让相关方理解其中的权衡。
向相关方解释技术债务
用业务语言描述技术债务：“这一部分的变更耗时是其他部分的三倍，并且导致了我们大多数的生产事故。投入两个冲刺将加快这里今后的所有工作。”
本主题的免费模板
常见问题
由谁决定何时偿还技术债务？
产品负责人对待办事项列表进行排序，并参考开发人员对技术债务成本的说明。
所有技术债务都是坏的吗？
不是。为快速学习而有意承担的短期债务可能是明智的，只要对其进行跟踪并偿还。
什么是技术债务？
现在选择快速或简单的解决方案而非更好方案所带来的未来成本。它表现为变更更慢、缺陷更多、发布风险更高。
“技术债务”一词是谁提出的？
Ward Cunningham 于 1992 年提出了债务这一比喻，用以向业务相关方解释为何需要重构。
如何衡量技术债务？
没有单一的衡量标准。团队会参考各种迹象，例如完成简单变更所需的时间、缺陷率、代码分析工具以及产品待办事项列表中技术债务条目的规模。
技术债务应该放入产品待办事项列表吗？
应该。将技术债务作为产品待办事项列表条目使其可见，可以让产品负责人将其与新功能进行权衡。
Scrum 团队应该在技术债务上花多少时间？
没有硬性规定。许多团队会在每个冲刺中为此预留一部分产能，并根据技术债务拖慢进度的程度进行调整。
完成的定义如何防止技术债务？
严格的完成的定义（包括测试、代码评审和文档）可以防止捷径成为增量的一部分。
重构如何减少技术债务？
重构在不改变代码行为的情况下改进其内部结构。定期重构可以防止技术债务累积。
技术债务只是软件问题吗？
该术语源自软件领域，但其他领域也存在类似的债务，例如过时的流程、未成文的知识，或内容和数据中的临时修补。
如何说服相关方偿还技术债务？
用业务语言来解释，例如变更速度慢了多少或导致了多少事故，并在以下场合展示修复后的预期收益： 冲刺评审会.