您如何估计技术债务清算的投资回报率?

管理者关心的是通过增长(首先是吸引新客户的新功能)和(其次是通过优化流程生命周期)来赚取利润。

考虑到你的问题,你的建议属于第二类:毫无疑问,这将落后于目标1(因此优先考虑 即使 如果这能省钱…因为省钱 暗示 花费金钱(大多数时间至少;-)。

现在 ,在“技术性坏帐”上加上一个$数字可能会转为一个更积极的旋转(假设以下适用于您的情况):“如果我们投资于改写组件x,我们可以更快地引入特性y,从而获得z更多的客户”。

换言之, 评估技术债务的成本与失去商业机会的成本 .

Sonar 有一个很好的插件( technical debt plugin )分析源代码以寻找这样的度量。虽然您可能不能在构建中具体地使用它,因为它是一个Maven工具,但它应该提供一些好的度量标准。

以下是他们的算法片段:

Debt(in man days) =
    cost_to_fix_duplications +
    cost_to_fix_violations + 
    cost_to_comment_public_API +
    cost_to_fix_uncovered_complexity + 
    cost_to_bring_complexity_below_threshold


 Where :

 Duplications = cost_to_fix_one_block * duplicated_blocks

 Violations   = cost_to fix_one_violation * mandatory_violations

 Comments     = cost_to_comment_one_API * public_undocumented_api

 Coverage     = cost_to_cover_one_of_complexity * 
                         uncovered_complexity_by_tests (80% of
                         coverage is the objective)

 Complexity   = cost_to_split_a_method *
                         (function_complexity_distribution >=
                          8) + cost_to_split_a_class *
                         (class_complexity_distribution >= 60)

我觉得你走对了。

我不需要计算这个,但是我和一个朋友讨论过,他管理一个大型软件开发组织,有很多遗留代码。

我们已经讨论过的一件事是,通过分析VCS提交并使用它们来划分程序员时间的粗略估计,生成一些粗略的工作度量。这是乔尔·斯波斯基的灵感 Evidence-based Scheduling .

这样的数据挖掘还可以让您识别代码维护时间的集群,并将其与跟踪系统中的bug完成情况进行比较(除非您已经获得了这两个记录和准确记录之间的紧密集成)。

适当的投资回报率需要计算全部回报率,因此需要考虑以下几点: -降低维护成本(明显) -业务机会成本,即停机或错过无法及时添加到发布中的新功能 -由于重构而生成新产品线的能力

记住,一旦你有了一个派生数据的规则,你就可以有关于 怎样 去计算,但至少你有 一些 数字种子讨论!

+1对于捷豹路虎专注于失去的商业机会。

我建议考虑管理层认为的那些机会。他们认为什么会影响收入增长——新功能、上市时间、产品质量?将债务偿还与这些驱动因素联系起来将有助于管理层了解收益。

专注于管理观念将有助于避免错误的计算。投资回报率是一个估计值,它并不比它在估计中所做的假设更好。管理层会怀疑仅仅是数量上的争论,因为他们知道在某个地方有一些定性的争论。例如,短期内,偿还债务的真正成本是程序员没有做的其他工作,而不是那些程序员的现金成本,因为我怀疑你是否会为此雇佣和培训新员工。未来开发时间或质量的改进是否比这些程序员将要添加的功能更重要?

此外,请确保您了解管理产品的范围。如果管理层不考虑从现在开始的两年,他们就不会关心18个月内不会出现的福利。

最后,思考一下这样一个事实,即管理层的看法首先允许该产品进入这种状态。有什么变化会使公司更加关注技术债务?如果差异是 你 --你是一个比你的前任更好的管理者——记住你的管理团队不习惯思考这些事情。你必须找到他们对它的胃口,把注意力集中在那些能带来他们关心的结果的项目上。如果你这样做,你将获得信誉,你可以用来让他们考虑进一步的改变。但收益的升值可能还需要一段时间。

我只能在一个迭代和增量的过程中,通过经验来讨论如何做到这一点。

您需要收集指标来估计您展示的最佳成本/故事点。大概,这代表了您的系统在最初的体系结构搅动之后,当大部分的设计尝试和错误都已经完成,但是熵导致衰减的时间最少。当速度/团队规模最大时,在项目历史记录中查找该点。将此作为成本/点数基准(零债务)。

随着时间的推移,随着技术债务的累积,速度/团队规模开始减小。这个数字相对于基线的减少百分比可以转化为在每个新的故事点上支付的“利息”。(这实际上是支付给技术人员的利息 和 知识债务

严格的重构和退火使技术债务的利息稳定在高于基线的某个值上。把这看作是产品所有者为系统中的技术债务支付的稳态利息。(同样的概念也适用于知识债务)。

一些系统达到了每个新故事点的成本+利息超过正在开发的特征点的价值的程度。这是系统破产的时候,是时候从头重写系统了。

我认为可以使用回归分析来梳理技术债务和知识债务(但我没有尝试过)。例如,如果假设技术债务与某些代码度量密切相关,例如代码复制,则可以确定由于技术债务与知识债务而支付的利息增加的程度。

作为一个非常孤单或小团队的开发人员,这已经超出了我的工作范围,但是对于我来说,一个很好的解决方法就是找出浪费时间的地方,这是非常非常详细的时间安排,例如使用一个方便的任务栏工具 this one 它甚至可以在您访问loo时过滤掉,并可以将所有内容导出到XML。

一开始可能很麻烦,向团队介绍可能是一个挑战,但是如果您的团队每十五分钟就记录一次,他们花费的时间是由于软件中的错误、错误或误解,那么您就可以根据令人印象深刻的实际数据来积累每月实际花费的技术债务。

我链接到的工具是我最喜欢的,因为它非常简单(甚至不需要数据库),并且通过任务栏图标提供对每个项目/项的访问。此外,还可以在那里输入有关所执行工作的其他信息,并且计时实际上是在几秒钟内激活的。(我与卖方无关。)

估计一下你花了多少钱可能比较容易。 在过去 .一旦你做到了这一点,你就应该能够用范围和逻辑来估计未来,即使你的老板也能理解。

尽管如此,我对这类事情没有太多的经验,仅仅是因为我还没有见过一个经理愿意在修改代码方面走这么远。当我们必须修改坏代码时,它总是我们要修复的,所以重构实际上是所有修改和错误修复的隐藏成本。