我目前正在使用一种相当古老的产品，这种产品背负着来自糟糕的程序员和过去糟糕的开发实践的大量技术债务。我们开始变得更好，技术债务的创造已经大大减缓。
我已经确定应用程序的区域状况不佳，我可以估算修复这些区域的成本，但我很难估计投资回报率（ROI）。
代码将更容易维护，并且将来更容易扩展，但我怎样才能在这些代码上加上一个美元数字呢？
一个好的起点似乎是回到我们的错误跟踪系统并根据与这些“坏”区域相关的错误和功能来估算成本。但这似乎很耗时，可能不是最有价值的预测因素。
过去有没有人进行过此类分析并对我有任何建议？
答案 0 :(得分：9)
管理者关心通过增长来实现收益（首先是例如吸引新客户的新功能）和（第二）通过优化流程生命周期。
看看你的问题，你的建议属于第二类：这无疑会落后于目标＃1（因此可以优先考虑甚至，如果这样可以省钱...因为省钱< strong>暗示花钱（至少大部分时间; - ））。
现在，在“糟糕的技术债务”上加上一个数字可以转变为更积极的旋转（假设以下情况适用于您的情况）：“如果我们投资于重新加工组件X，我们可以更快地引入功能Y，从而获得更多Z客户“。
换句话说，评估技术债务的成本与失去商机的成本。
答案 1 :(得分：3)
我认为你走在正确的轨道上。
我没有必要计算这个，但我和一位管理着大量软件开发组织的朋友讨论了很多遗留代码。
我们讨论过的一件事是通过分析VCS提交并使用它们来划分程序员小时的粗略估计来生成一些粗略的工作量度量。这是受Joel Spolsky的Evidence-based Scheduling启发。
进行此类数据挖掘还可以确定何时维护代码的聚类，并将其与跟踪系统中的错误完成进行比较（除非您已经完成了两者之间的紧密集成和准确的记录）。
正确的投资回报率需要计算完整的回报率，因此需要考虑的一些事项是： - 降低维护成本（显然） - 停机业务的机会成本或错过无法及时添加的新功能 - 由于重构而产生新产品线的能力
请记住，一旦你有了一个推导数据的规则，就可以有关于如何计算事物的参数，但至少你有一些数字来讨论！
答案 2 :(得分：3)
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)
答案 3 :(得分：1)
+1 jldupont专注于失去商机。
我建议考虑管理层认为的那些机会。他们认为什么会影响收入增长 - 新功能，上市时间，产品质量？将债务减免与这些驱动因素联系起来将有助于管理层了解收益。
专注于管理观念将帮助您避免错误的计算。投资回报率是一种估计值，并不比其估算中的假设好。管理层只会怀疑数量论证，因为他们知道那里有一些定性。例如，在短期内，您的债务减少的实际成本是程序员没有做的其他工作，而不是那些程序员的现金成本，因为我怀疑你是否会为此招聘和培训新员工。未来开发时间或质量的改进是否比这些程序员原本添加的功能更重要？
此外，请确保您了解管理产品的范围。如果管理层在两年后没有考虑，他们就不会关心18个月内不会出现的好处。
最后，回想一下管理层的看法让这个产品首先进入这个状态。改变了什么会让公司更加关注技术债务？如果差异在于你 - 你是一个比你的前辈更好的经理 - 请记住，你的管理团队不习惯考虑这些东西。你必须找到他们对它的兴趣，并专注于那些能够提供他们关心的结果的项目。如果你这样做，你将获得可信度，你可以使用它来让他们考虑进一步的变化。但是对增长的欣赏可能还需要一段时间。
答案 4 :(得分：1)
我只能谈论如何在迭代和增量过程中凭经验这样做。
您需要收集指标，以估算您展示的最佳成本/故事点。据推测，这代表了您的系统刚刚在最初的架构流失之后，当大部分设计试错已经完成但是熵有最少的时间导致衰减。当速度/团队规模最高时，在项目历史记录中找到该点。使用此作为您的成本/点基线（零债务）。
随着时间的推移，随着技术债务积累，速度/团队规模开始减少。此数字相对于您的基线的百分比减少可以转换为每个新故事点支付的“利息”。 （这实际上是对技术和知识债务的利息支付）
严格的重构和退火导致技术债务的利息稳定在高于基线的某个值。将此视为产品所有者为系统中的技术债务支付的稳态利益。 （同样的概念适用于知识债务）。
有些系统达到了每个新故事点的成本+利息超过正在开发的特征点的价值的程度。这是系统破产的时候，是时候从头开始重写系统了。
我认为可以使用回归分析来梳理技术债务和知识债务（但我还没有尝试过）。例如，如果您假设技术债务与某些代码指标密切相关，例如代码重复，你可以确定由于技术债务和知识债务而支付的利息增加的程度。
答案 5 :(得分：0)
作为一个主要是单独或小团队的开发人员，这不属于我的领域，但对我而言，找出浪费时间的一个很好的解决方案是非常非常详细的计时，例如使用方便的任务栏工具，例如{ {3}}甚至可以在你去厕所时过滤掉，并且可以将所有内容导出到XML。
一开始可能很麻烦，并且要引入团队是一项挑战，但如果您的团队因软件中的错误，错误或误解而每十五分钟就会记录一次，那么您就会积累一个令人印象深刻的真实基础关于技术债务实际上每月工资成本的生活数据。
我链接的工具是我的最爱，因为它很简单（甚至不需要数据库），并通过任务栏图标提供对每个项目/项目的访问。此外，还可以在此处输入有关所执行工作的其他信息，并在几秒钟内完成计时。 （我不隶属于供应商。）
答案 6 :(得分：0)
估算过去过去花费的金额可能更容易。一旦你完成了这项工作，即使你的老板能够理解，你也应该能够用范围和逻辑来估计未来。
话虽这么说，我对这种事情没有太多经验，仅仅因为我从未见过一位愿意在修复代码方面走得太远的经理。当我们必须修改错误的代码时，它一直是我们修复的东西，因此重构实际上是所有修改和错误修复的隐藏成本。