技术债是Ward Cunninggham于1992年率先提出的概念，他对技术债的定义如下：代码写好就交，意味着欠债的开始。稍微欠点技术债的确可以加速开发速度，但前提是事后及时重写代码，......如果只借不还，后果很危险。在不准备的代码上花的每一分钟，都算是技术债的应付利息。不稳固脆弱的代码实现所引发的债务负担，会使整个工程组织陷入裹足不前的艰难境地。
技术债有些是我们有意选择的结果，有些是我们无心而为的结果，Cunningham将技术债分为三类：
1. 低级技术债，主要是技术或业务人员不成熟或者流程缺陷而导致的设计粗糙、代码混乱、测试不足。有时候称为“草率技术债”、“无心技术支持”或者“混乱”，这类技术债是可以通过适当的培训、人员结构调整就能够消除。
2. 不可避免技术债，从人脑的局限性以及认知不足的角度思考，我们无法一开始就设计出完美的解决方案，无法穷尽所有的测试用例，无法掌控第三方组件的变化，也无法预测市场的演变等等，因此有一类技术债，通常无法预测、无法预防，只能接受，这类技术债是不可避免的，只能在被识别出来的时候考虑处置方案。
3. 策略性技术债，这类技术债是有意而为之的结果，具体讲就是公司或企业从经济角度或者战略角度，为了其他更重要的目标而是有策略的选择遗留技术债，抄近道走捷径快速交付产品，从而实现一个重要的短期目标。这类经过大家权衡考量后的技术债就叫做策略性技术债。
既然是债就得还，所谓欠债还钱天经地义，耍无赖不还后果就很严重。下图就清晰的总结技术债日积月累的后果。
技术债和财务债一样，必须加以管理。但是我们必须认识到没有那个产品能做到“无债一身轻”，管理的目的不是消除所有债，管理技术债要求综合考量技术与业务因素，作出经济效益最好的折中方案。技术债的管理有是哪个主要活动：管理应计技术债，让技术债可见，维护（偿还）技术债。
管理应计技术债，首先需要停止向产品继续增加低级技术债，使用良好的技术实践（简洁设计、TDD、DevOps，自动化测试、重构等）能减少绝大部分低级技术债，提高团队技术水平（增派技术大牛加入团队、增加培训等）、持续代码代码重构。其次，在定义任务DoD时，检查表中包含的技术细节越多，积累技术债的可能性就越少，此处目的是第一次就把工作做好，避免技术债的遗留。最后，要正确理解和量化技术债的经济效益，看得见的经济效益容易理解，还有很多因素很难考虑到，比如，偿还技术债会导致多少延期成本？这不仅包括偿还债务本身所花的时间，还包括其他产品或后续版本的延期成本，也就是机会成本。还有大多数组织对技术债的优先级放的很低，一到紧急关头业务人员往往更倾向于开发新特性。
让技术债可见，首先让技术债在业务层面可见，这个很关键，只有业务人员认识到产品技术债的重要性，才能做出明智的经济决策。跟踪开发速率是体现技术债对业务影响的很好的体验。其次让技术债在技术层面可见，有三个可见的方式，1.可以把技术债当作缺陷录入缺陷跟踪系统；2.为技术债创建PBI；3.创建特殊的技术债列表；
维护（偿还）技术债，这是一个比较大的话题，首先我们对技术债定义三个状态，偶发技术债(未知但却已经存在的技术债)、已知技术债(已知但未打算偿还的技术债)、目标技术债（已知且决定偿还的技术债），然后基于这些分类考虑如下偿还策略：1.确定已知技术债是否应该偿还；2.如果是编码时发现的偶发技术债，就立即偿还；3.每个冲刺考虑一定数量的已知技术债作为本冲刺的目标技术债。具体偿还方式如下：
并非所有技术债都应该偿还，比如马上退市的产品、一次性产品、临时产品的技术债就不需要还
应用童子军规则(有债就还)，童子军规则：“离开营地时，要让它比你进去时更干净”，及时偿还技术支持对整个开发团队和组织都有好处，时刻保持技术债在一个合理的范围，团队可以在每个冲刺都预留5%~33%的时间用来偿还技术债。
分期偿还高息技术债，Scrum团队可以讨论每个冲刺偿还多少技术债，分期、分步骤偿还已知技术债，避免所谓的“技术债冲刺”或者“重构冲刺”。在分期偿还技术债的时候，应该先锁定高息技术债。所以维护技术债，按照影响程度、偿还后带来的好处等维度去维护已知技术债。
一边做有客户价值的工作，一边偿还技术债，在完成有客户价值工作的同时偿还债务，是分期分步骤偿还已知技术债的理想方式，既能专注于高息技术债，又能把维护技术债与Scrum以价值为核心的方式相结合。
本文主要内容来自《Scrum精髓》
