如何定义和支出您的技术债务预算

最新推荐文章于 2024-10-16 21:19:02 发布

dfsgwe1231

最新推荐文章于 2024-10-16 21:19:02 发布

阅读量367

点赞数

如果您曾经参与过冲刺计划，并争辩说要花时间偿还一些技术债务（即定义技术债务预算），这就是解决方法。

很难为sprint中的竞争功能腾出空间，但是试图证明牺牲其中一些功能以花掉10％到20％的工程时间来偿还技术债务是合理的，这是史诗般的努力。

我参加了产品与工程之间的许多会议，在这个主题上浪费了太多时间。情绪高涨，根据轶事证据做出决定，并且房间中最大声的人的意见盛行。

这些糟糕的决定的总和往往会导致严重的后果。（略微讽刺的）难题是：如果业务压力接管了，公司冒着承担过多技术债务的风险，工程师最终变得无能为力，公司在技术上破产了，他们的竞争对手获胜。如果工程压力接管，该公司将承担承担的技术债务过少的风险，竞争对手将更快地交付产品和功能，获得最大的市场份额，并在以后用这些现金偿还其技术债务。再一次，你输了。

传统观点认为，解决此问题的方法是让软件工程团队对代码库建立一种直观的认识，即存在技术债务，对公司造成的影响并建立对组织的信任。如果您的创始人首席架构师反复告诉您您现在需要重构核心代码，那么您（通常）就可以这样做。

这一切都很好，我们都应努力保留我们的工程师，营造知识共享和信任的文化。但是，这需要多年的努力，而且我们仍然处于重构工作的另一端，几乎不知道我们的时间是否花得好。我们可以等一会儿再偿还这笔技术债务，然后提供更多功能吗？我们只是节省了未来的工程时间吗？我们永远不会确定。

这常常被认为是产品开发更多的是艺术而不是科学。我们该注入一些科学知识了。

故意承担并妥善管理的技术债务是一个了不起的工具！就像金融债务一样，您可以将其用于额外的杠杆作用。另一方面，如果我们在不知不觉中承担过多或没有真正了解交易条款的情况（即对您的代码库，客户，团队和业务的影响），则可能导致任何软件公司的灭亡。

事实证明，这正是最好的站点可靠性工程团队如何考虑其站点可靠性预算的一种方式，该概念已由Google推广。站点可靠性负责保持软件产品的正常运行。有趣的是，与许多人可能会想到的不同，像Google这样的公司并不希望100％的正常运行时间。这是因为99.99％的正常运行时间更容易实现，而正常运行时间足以使Google产品对现实世界的用户来说具有绝对的可靠性。最后的0.01％根本不值得争取。

因此，如果这使他们每年可以有52分钟的停机时间，则Google将希望尽可能地接近此数字。少于52分钟的停机时间是一个错失良机，可以承担更多的风险并更快地为客户提供更具雄心的功能。

将您的技术债务预算想像为站点可靠性预算。如果您正在承担审慎的技术债务，并且您的债务仍低于客户和业务开始受到影响之前可以承担的最大技术债务，则您应该承担更多的技术债务以承担更多的风险并战胜您的债务竞争对手。

当您的技术预算赤字时，还清部分债务。如果它是绿色的，您可以承担更多的风险和承担更多的债务。您的目标是不断地尽可能接近理想的技术债务额。换句话说，如果您处于图表红色部分的峰值，则理想的技术债务预算为A⇒B。如果处于绿色部分的峰值，则为B⇒C。A⇒C太大a预算。

因为现在可以测量技术债务（这是我们在另一篇文章中谈到的主题），所以这不再仅仅是概念上的，而是完全可行的。

如何获得最大的科技债务预算优惠

适当的技术债务预算可以使您降低或增加您可以承受的最大技术债务金额。为了定义该预算，您需要确定代码库中值得立即偿还技术债务的区域。值得立即偿还的债务是会妨碍您的公司实现其当前目标的债务。您显然不想偿还过多的债务，但您也想避免偿还过多的债务。

并非所有内容都需要重构。如果它不是很关键，或者在接下来的几个月中没有人需要改进其功能，或者它太复杂了，请考虑将其视为技术债务。

AngelList远程主管 Andreas Klinger ， 重构大型旧版代码库

简而言之，您的目标是确定在此sprint，月份或季度中要处理的事情与代码库中有技术欠债的部分之间的交集。然后，偿还该交叉路口的债务，但不偿还外部债务。

这就是科学对艺术的补充。您可以使用数据来确定需要尽快偿还技术债务的领域：

识别您的代码库中所有权不强的文件。由于代码所有权是代码库运行状况的主要指标，因此容易出现问题。在我的文章“ 为什么要拥有所有权的工程文化”中对此有更多介绍。
测量这些文件的内聚和耦合。现在，您已将列表修剪为所有权不强，内聚性低和耦合度高的一组文件。有关这三个指标的更多信息，请参阅我们关于理解和管理技术债务的三个指标的文章。
计算这些文件中每个文件的流失率，以识别问题文件的子集。正如Microsoft Research所示，尽管活动文件仅占整个系统的2–8％，但它们却占所有缺陷的60–90％。
将这些文件与本季度的路线图进行比较。路线图上列出的任何功能是否需要工程师处理您发现的问题文件的子集？如果是这样，请针对这些文件进行重构，估算所需的工作，然后将其分配给应该是这些文件所有者的工程师，然后将此工作纳入您的计划中。

等等。