团队常常将很难重构或其他技术清理工作纳入到其Sprint中。首先，要说服技术负责人响应技术债务应该偿还，而不是任其累积，这就会是一个挑战。
然后，即使产品负责人同意了，由于其他因素干扰，中断和变更，很难将重构纳入到Sprint中。
接下来的文章中，将会描述如何为重构留出时间的常用的三种方式，以及每种方式的优缺点。
方式1：为每个迭代分配固定量的重构时间。
第一种方式是，每个迭代都分配固定量的时间进行重构工作。
这里所说的时间，可以是若干小时数、时间点数，或者两者的百分比。例如，一个团队可以决定为重构和其他技术预留10个小时，4个故事点，或者10%。
由于更加偏爱容量驱动的Sprint的计划方式，所以我建议预留若干小时数。这也是最简单的方式：在Sprint期间能很容易地跟踪所使用的时间，这样团队就可以决定是否有额外时间进行额外的重构。
| 分配固定时间的利与弊
这一方式一大优点是很容易实施。团队可以在早上对重构工作进行承诺，然后当天完成。另一个好处是，重构将变成团队例行工作的一部分，这能将团队从讨论和安排技术清理工作所需的负担中解放出来。
但是，安排多少时间进行重构和技术清理才合适？ 很难决定。即使开发人员和产品负责人一致同意每个迭代要分配固定时间来做重构，他们也很难对多少时间合适在数量达成一致。
而且，也很难每个迭代都达到一个固定时间量。如果商定了20个小时，但在某个迭代中只有15个小时可用，那么剩下的5个小时是否转到下一个迭代中，团队计划投入25个小时呢？
最后一个缺点是，有时候能多安排点重构时间，而有时候又得少安排点重构时间。 一个迫在眉睫的重要截止日期可能导致需要减少重构时间，而在截止日期不那么激进的时期可能又能增加重构时间。
方式2：负债时就确定何时偿还
将重构纳入Sprint的第二种方式是，在承担技术债时，就确定在何时偿还。
我今天买了一个非常好的便携式固态硬盘。我刷信用卡支付，花了449美元。这是债务，而我也确定了还清债务的时间——我会在每月23号收到信用卡对账单时偿还。
团队也能采用同样的方式，创建一个名为“待偿还技术债务”的产品待办项，然后把它放到其产品待办列表中。该待办项的位置应该是这样的，它上升到顶部，并被纳入到他们承担债务时指定的Sprint中。
例如，假设一个团队的主要截止期限是三个月。为了能达成期限日期，他们走了捷径。在作出此决定时，他们会立即编写一个待办项并将其插入到产品待办列表中并安排时间，比如说，四个月后。
| 负债时就确定何时偿还的利与弊
这种方式的最大优点是，它在确定何时偿还技术债或进行其他技术工作方面提供了灵活性。 一些技术债的偿还速度要相对更快——用于偿还此类债务的待办项，可以放在靠近产品待办列表顶部的位置。
其他可以存在更长时间也不会引发问题的债务，对应的债务偿还待办项可以放在更低点的位置。
这种方式也非常容易长期坚持下去。它可以根据需要启动和停止。
这种方式的最大缺点是，它不能解决预先存在的债务或其他技术问题。要解决这些问题，团队可能需要选择其他方式，或者与此方式结合使用。
方式3：维护独立的技术待办列表，并在时间允许的情况下进行重构。
第三种常见方法是 ，维护技术待办列表，以将重构和其他技术工作纳入到Sprint中的，并让团队成员在有时间的时候继续进行还债工作。
例如，在下午较晚时，程序员可能会更喜欢做一个小重构，而不是开启一个较大的新产品待办项。在3点时，某位开发人员可能不会花精力去启动一个产品待办事项（或许是一个涉及3到4人、需要3天才能完成的用户故事），而他会花精力去做两三个小时的重构。
许多以这种方式工作的团队都维护着一份“技术待办列表”。 对于一些团队来说，这只不过是被标记并与产品待办项列表其他部分一并存储的待办项而已。
而另一些团队，则会在团队空间或某个共享文档中，划出一片区域，来维护他们的技术待办列表。
| 在时间允许时处理技术待办项的利弊
这种方式的一个优点是，它非常容易实现。
但随之而来的缺点是，这种做法很难持续进行。 团队可能会采用这样的思维方式:“当某人一天中还有一两个小时，并且想做技术清理工作时，可以试着去清理一些旧债务。”但当日程安排有压力时，这可能会很难坚持下去。团队可能会几个月（甚至更久）都不会去关注积累的技术问题。
有些人可能会说，存在技术待办列表本身就是一个缺点。对此，我并不完全同意。
技术待办列表上的待办项，往往只需要几个小时就能完成，采用这种方式的团队得到了其产品负责人的信任，他们可以自行决定何时完成这些工作。这类待办项，类似于我需要在接下来的几次出行中给我的车加油。我的油箱空了一半，而我很少开车出远门时，我就不需要急着加油，所以它不会出现在我明天要开展的工作清单上(或称为“明天的待办列表”)。这只是我下次外出时有十分钟空闲时才会做的事。
| 无论采用哪种方式，都必须腾出时间来进行技术清理
团队常常很难腾出时间来偿还技术债，或者清理他们可能在几个月甚至几年前走捷径而付出的代价。当这些缺陷被允许存在于产品中时，就会产生进一步的问题。 这就是为什么“技术债务”这个比喻会引起如此强烈共鸣的原因。
尽管在此概述了三种方法，我更喜欢第四种：避免承担任何技术债务。
但这并不总是可行的。有时，团队会在不知不觉中承担了技术债。所以制定一个技术债务的偿还策略，是很重要的。
作者：MikeCohn
译者：李洁（Jerry Li）
