用金钱计算技术债务

很多敏捷团队都能认识到技术债务相关的罪状。就跟财务上的负债一样，技术债务也会产生利息。要支付这些利息，就要付出额外努力维护和改进正在“腐化”或基础并不牢固的软件。诸多敏捷人士推荐尽早偿还技术债务。然而，大多数敏捷团队无法成功以金钱的方式计算技术债务，因此无法得到有价值的深入理解和思考。

一旦有了与技术债务直接相关的金钱数目，关于软件的多种复杂而麻烦的问题就能得以回答。Israel Gat提出：除非对于技术债务有一个量化的账单，否则团队都会忽略其重要性，软件会因此而逐渐腐化，无法补救。

当债务达到一定程度之后，就没有什么好的补救方法了。代码质量非常糟糕，这时要修复任何部分都会造成伤害，不管修复哪里似乎都会破坏其他某些部分代码。

他还提到了以金钱方式计算技术债务的需要，并使用收支平衡表展示出其作为债务的一面。

在 Israel 看来，以金钱方式计算技术债务有如下好处：

能够告诉团队何时停止开发，开始重构——当技术债务达到一定程度后（比如每行代码 25 美分），就要暂停开发新功能。团队进入重构过程，除非债务得以偿还，否则不加入任何功能。
软件的客户对于软件的风险得以了解——Israel 认为这符合敏捷宣言中的一项：“客户协作胜过合同谈判”。
风险投资者能够以此做出投资决策——VC 们可以以此判断向某项软件产品中投入资金是否理智。
有助于判断软件的支付能力——软件在其生命周期的演化过程中，与之伴随有开发和维护活动，以金钱方式计算技术债务能够有助于回答与这些活动相关的支付能力问题。
有助于人们在重构和重写这二者之间做出选择——将技术债务与其他重要因素联合起来，能帮助人们判断是否要重新开始。
有助于定义限额——一旦金钱上的限额定义出来之后，就能帮助 CxO 等利益干系人做出成熟的决策。

那么，有哪些有效的方式可以用来将技术债务以金钱衡量呢？

使用Sonar中的技术债务插件是一种方式。在 Sonar 的实时站点上，已经有了对于多个项目的技术债务分析。要计算成本，首先要使用下面的方式找出债务：

债务（以人天计算）＝{修复重复部分的成本＋修复违规的成本＋为公共 API 做注释的成本＋修复未发现的复杂性的成本＋带入低于阈值复杂性的成本＋在包的层面上切断生命周期的成本}

在上面各种违规情况中，对于每个小时的成本有个默认值。比如：

现在，比如默认的“修复重复部分的成本”为 2 个小时。假设每个开发人员每天的成本是 500 美元，一天有 8 个小时，那么修复一个重复部分就要花费 125 美元。与之类似，就可以做出针对各种违规情况的金钱分析，并可以计算出最终的技术债务总和。

因此，以金钱方式计算技术债务能够让人们深入理解与软件相关的潜在成本。对于所有希望监控技术债务成本并将其保持在一定限额内的敏捷团队来说，这很关键。这么做有助于创造一个易于维护和改进的软件产品，同时让 VC 有信心投资，让客户有信心买单。

查看英文原文： Monetizing the Technical Dept