如何偿付技术债务

Paul Tevis 的团队在四个月前开始使用 Scrum。 该项目拥有大量技术债务，他正在努力解决如何跟踪和偿付技术债务的问题。 Tevis 写到:

我关心的问题是：（1）我们一开始跟踪非故事的任务，就无法集中于交付客户的价值；（2）如果我们不让这些任务可见，那么就无法以需要的速度取得进展。 对于解决不是直接与故事相关（或者涉及到多个故事）的技术债务，你有什么好的模式吗？

什么是技术债务？ Ward Cunningham 创造了“技术债务”这个词，它指的是组织为了达到短期的目标，而降低代码质量时所造成的债务。 想要重新提高代码质量，马上解决会很容易，而做的越晚，成本就越高。 额外的成本就是技术债务的“利息”。

Malcolm Anderson 创建了一个案例，它与特定情况下的技术债务相关：

之所以使用短期的技术债务，会有很多种原因。 让我使用利息率为 36% 的信用卡作为比喻。 你不想使用那个卡。 但是，当拥有很大的业务合理性的时候，你就会在短期的情况下使用那个卡。

但是 Adam Sroka 反对说：

如果你想要做出业务决定，至少要知道： 1. 我会花费多少？
2. 会产生多少利息？ 会经过多长时间？
3. 我是否有足够的收入来偿付？

当团队自发地采用技术债务的时候，甚至很少有人（如果有的话）知道以上任何一个问题的答案。

不管这是否是个好主意，在 Tevis 的案例中，债务已经发生了。 那么我们如何才能在项目中减少已经存在的技术债务呢？

Roy Morien 为如何偿付技术债务的问题提供了两种可能的解决方案：

你真的需要做出这么困难的选择吗？ 我想，如果你的“技术”开发需求那么重要，那么大，或者那么多，那么暂停面向用户的开发是否是可行的呢？那样你可以把那些技术问题理清并清理掉。 或者，是否可以重新分配一些开发者来解决这些技术问题，同时团队中其它人员会继续开发面向用户的内容。 这可能会影响团队的效率，但那又怎么样呢？

然而，Ron Jeffries 并 不同意这两个方法：

当技术问题是由故事驱动的时候，处理它才会最有效。 代码库可能到处都需要处理，但是只有在因为面向用户的原因工作的代码才需要偿付技术债务。 如果某些糟糕的代码没有涉及到任何故事，那么对它所做的工作就是很大程度上的浪费。

因此，我更喜欢像平时那样（但可能很少会那样）采用故事的方法，并且遵循“童子军军规”，在离开营地时让它比我们找到时更干净。 也就是说，在故事引领我们到达的地方，让我们编写更多的测试，并更积极地进行更多的重构。

这个方法至少拥有以下优点：

• 保持故事“最敏感”的流程；
• 发动所有团队智慧来提供帮助；
• 让整个团队知道如何保持代码整洁；
• 专注于对需要的地方进行改善；
• 不浪费精力在可能需要的改善上；

… 以及更多。

而“banshee858”提供了下面的建议（他最初信任 Tobias Mayer），这与 Jeffries 的方法非常吻合：

在很小的便利贴上列举所有技术债务，并把它们贴到任务板上。 当为 Sprint 选择产品 Backlog 项目（PBI）的时候，看一下各个技术债务，并找到处理 PBI 的同时可以合理完成的那些项目。 把它们添加到 PBI 的工作范围之内，并估计需要多长时间才能完成特性和技术债务内容。 使用这种方式，你就可以看到技术债务方面的工作，并且能够区分出优先次序，与真正的价值关联起来。

查看英文原文： How To Pay Down Technical Debt