技术债务的真正成本

我们软件行业的大多数人至少对技术债务有一定的了解，但您是否考虑过技术债务的整个生命周期成本？

在本文中，我们将研究一个虚构的技术债务从开始到解决的过程。

我的目标是让您从几个不同的角度思考技术债务。

接受技术债务

我们的场景始于一家公司为了赶截止日期而努力工作。在大型展会上进行演示，完成功能开发会带来巨大的经济效益。

这是演示前的最后一个冲刺阶段。一切进展顺利，但时间安排很紧。Kayla 在单口会议上描述了她正在开发的一项功能，以及它的复杂程度远超预期。

Kalya 估计正确完成该功能需要 8 个小时，但冲刺中剩余时间不足。Dwayne 提出了一个建议，可以让团队在 3 小时内完成关键需求。

经过一番深思熟虑后，团队决定采用短期解决方法，并创建待办事项以便在截止日期后妥善清理该功能。

团队按计划完成了功能，在截止日期前完成，公司也从团队的决策中获利。

此时，团队通过承担债务获得了 5 小时的生产力（贷款本金）。

演示结束后，该公司达成了多项关键销售和承诺，这对公司而言意义非凡。这对公司来说是一个激动人心的时刻，团队也为自己的辛勤付出获得回报而感到欣喜。

由于演示期间发现了几个错误以及需要一些新功能，技术债务票未能进入下一个冲刺。

此外，在冲刺期间，Dwayne 发现由于团队采取了变通措施，他现在需要额外花费一个小时来开发一个新功能。这可以理解为我们金融隐喻中的利息。

让我们暂停一下，用瀑布图来看一下这个场景。这是一张财务图表，旨在绘制随时间变化的金融交易。毕竟，用财务图表来表示技术债务这样的金融隐喻似乎再合适不过了。

我们从左到右来理解这张图表。我们通过承担债务获得了 5 小时的生产力，但由于工作而损失了 1 小时，最终净增了 4 小时的生产力。

下一个冲刺，团队包括偿还技术债务的任务。

然而，在 Kayla 开始处理之前，出现了两个需要添加到冲刺中的紧急 Bug。这些 Bug 最终被证明是临时解决办法造成的。每个 Bug 都需要 3 个小时来复现、编写测试、修复、测试，最后将其打上补丁并投入生产。

此外，凯拉没有时间偿还债务，因此债务问题被推迟到未来的冲刺阶段。

因此，我们的瀑布图现在如下所示：

此时，由于最初的捷径，团队总共损失了 2 个小时的生产力——而他们甚至还没有开始偿还最初的技术债务。

清理原有债务的任务按照预期进入下一个冲刺阶段。

值得庆幸的是，这次没有发生任何干扰团队的事情，Kayla 只需花费另外 5 个小时的时间就能全额还清债务。

总而言之，做出该决策造成的生产力损失高达7个小时。此外，该决策还导致了一些客户可见的缺陷，损害了用户体验和信任。

除此之外，修复 bug 和技术债的任务本身就有一定的机会成本。换句话说，由于团队正在处理这些任务，他们无法进行软件的其他改进。

那么，这意味着什么？球队不应该承担债务吗？

我会说不是。就解决技术债务而言，这其实是一个相当理想的故事。债务的承担是经过深思熟虑的明智之举。如果没有这个决定，公司就无法按时完成任务，并且会损失十万美元的销售额和交易。

除此之外，该团队还积极优先解决债务以及由此产生的错误。

不，仅仅因为债务耗费了团队大量的开发时间，并不意味着这是一个糟糕的决定。但我们在承担债务时必须牢记，偿还债务带来的收益将远远超过生产力提升——如果它真的能够偿还的话。

这给我们带来了一个不幸的事实：这支球队像这样完全还清债务的故事极不寻常。

根据我自己的经验，我认为大多数技术债务都没有得到解决。

根据我的经验，债务通常会一直存在，直到产品退役。事实上，我观察到严重的技术债务代码被重复，并成为未来工作的基础。

如果您允许技术债务在您的代码中持续存在，它将作为未来代码的架构基础。

大多数团队并不像我们本文中的团队那样刻意承担技术债务。这意味着他们不太可能从承担这些债务中获得太多，甚至可能没有任何好处。

换句话说：如果您必须承担 5 个小时的技术债务，您是希望为了进行大宗销售，还是因为开发人员有一天感到有点懒惰？

那么我们这里的关键要点是什么？

如果您想进一步了解如何处理技术债务，请查看我的其他几篇文章：

我也很想听听你对技术债务的理解。请告诉我你的想法。