估算旧版代码库中的时间成本

最近，我开始从事一个项目，该项目将一个非常古老的单片应用程序迁移到基于微服务的体系结构中。

遗留的代码库非常混乱（“意大利面条代码”），并且通常一个看似简单的函数（例如，命名为“ multiplyValueByTen”）随后将自身显示为“涉及3个不同模式的10个表的数千行验证代码”。

现在，我的老板（正确地）要求我估计在新架构中编写功能X所需的时间。但是我很难提出一个现实的估计。由于上述原因，我常常大大低估了任务，并因为无法及时完成而感到尴尬。

明智的做法似乎确实进入了代码，注意到每个分支并调用了其他函数，然后估算了时间成本。但是在记录旧代码与实际写下新版本之间确实有微小的区别。

我应该如何处理这样的情况？

尽管我完全理解了遗留代码重构的工作原理，但我的问题不是关于“如何进行重构/重写？”。但是要给出一个现实的答案：“重构/重写X部分需要多长时间？”

阅读Bob Martin的“ Clean Coder”（和“ Clean Code”）。以下是记忆中的内容，但我强烈建议您购买自己的副本。

您需要做的是三点加权平均值。您需要为每项工作进行三个估算：

• 最佳情况-假设一切正常（a）
• 最坏的情况-假设一切都不对（b）
• 实际猜测-您认为可能会发生什么（c）

那么您的估计为（a + b + 2c）/ 4

• 不，那不会是准确的。有更好的估算方法，但此方法快速，易于理解，并通过让您考虑最坏的情况来减轻乐观情绪。
• 是的，您将不得不向您的经理解释您不熟悉该代码，并且无法进行准确，准确的估算，而不必每次都花费大量时间调查代码来提高估算（这是可以做到的，但是例如，您需要n天时间才能确切估计所需的天数）。如果您是“ JuniorDev”，那么对于一个合理的经理来说应该可以接受。
• 您还应该向您的经理解释，您的估算是根据最佳情况，最坏情况和可能情况进行平均的，并给他们提供您的数据，这也会给他们带来误差。
• 不要就估算进行谈判-如果您的经理试图为每个估算使用最佳案例（他们是傻瓜-但我遇到过类似的情况），然后欺负/激励您尝试按时完成任务，那么，他们有时候会很失望。继续解释估计数背后的理由（最好的情况，最坏的情况和可能的情况），并在大多数情况下保持接近加权平均值，您应该可以。此外，出于您自己的目的，请保留估算值的电子表格，并在完成后添加实际值。那应该使您更好地了解如何调整估算值。

编辑：

我回答这个问题时的假设是：

1. OP是初级开发人员（基于所选的用户名）。因此，从项目经理或团队负责人的角度出发，给出的任何建议都不是预期的，这取决于开发环境的成熟度，他们有望进行更复杂的估算。
2. 项目经理已经创建了一个项目计划，其中包含相当多的任务，计划要花几个月的时间才能完成。
3. 要求OP为他们的项目经理分配给他们的任务提供一些估计，他们希望有一个合理准确的数字（而不是概率曲线：）进入项目计划并用来跟踪进度。
4. OP没有几周的时间来生成每个估算值，并且由于给出了过于乐观的估算值而被烧掉了，并且希望比将手指悬在空中并说“ 2周，除非代码特别神秘，在这种情况下2个月”更准确的方法或者更多”。

在这种情况下，三点加权平均值效果很好。它是快速的，对于非技术人员来说是可以理解的，并且超过几个估算值应该平均可以接近准确度。特别是如果OP采纳我的建议来保存估计和实际记录。当您知道现实世界中的“最坏情况”和“最坏情况”时，您可以将实际情况输入将来的估算中，如果最坏情况比您想象的要糟，甚至可以为项目经理调整估算值。

让我们做一个可行的例子：

• 最好的情况是，以最快的经验，我做了一件非常简单的事情，那就是一周开始完成（5天）
• 最糟糕的情况是，根据经验，当时到处都有链接，最终我花了6周（30天）的时间
• 实际估算，可能要花2周（10天）

5 + 30 + 2x10 = 55

55/4 = 13.75这就是您告诉PM的内容。也许您最多舍入14天。随着时间的流逝（例如十个任务），它应该达到平均水平。

不要害怕调整公式。也许一半的任务会变成噩梦，只有百分之十容易完成。因此，您将目标设为a / 10 + b / 2 + 2c / 5。从您的经验中学习。

注意，我没有对PM的质量做任何假设。糟糕的项目经理会给项目委员会短暂的评估，以获得批准，然后欺负项目团队，以期达到他们承诺的不切实际的截止日期。唯一的辩护是保留记录，以便可以看到您给出估计并接近它们。

这可能是引入准敏捷方法的好时机。如果您不是根据小时/天进行估算，而是分配了斐波那契类型量表并根据任务的大小为其分配了一个值：

• 0-即时
• 0.5-快速获胜
• 1-简单的改变
• 2-几个简单的更改
• 3-更具挑战性
• 5-需要一些思考
• 8-大量的工作
• 13-可能需要分解的大量工作
• 20-绝对需要分解的大量工作

然后，一旦您估计出了许多这样的任务，便可以进行处理。在敏捷的环境中，您会发展“速度”，这是衡量您一周（例如一周）能达到多少积分的度量。完成几周的测试和学习后（您可以将其作为过程的一部分出售给您的经理-“我需要几周的测试并学会理解估算过程”），您将对您每周可以完成多少点更有信心，因此您可以更轻松地将估算的点数转化为时间。

https://pm.stackexchange.com/questions/4251/why-would-teams-use-the-fibonacci-sequence-for-story-points

https://stackoverflow.com/questions/9362286/why-is-the-fibonacci-series-used-in-agile-planning-poker

这并不是真正的敏捷，因为它不涉及任何仪式，但是我从OP中得知他是一个人。希望这种方法可以给出一些更自信的估计。

您要做的第一件事是开始收集有关您现在需要花费多长时间才能完成工作的数据。关于团队绩效的数据越多越好。这将是全面的，但是现在不必担心。这是事实，您需要向老板展示现实。

然后，您将去买几本书。

1. 软件评估：揭开史蒂夫·麦康奈尔的妖术神秘面纱
2. 通过迈克尔·费瑟斯有效地使用遗留代码

麦康奈尔的书将告诉您开始收集数据，然后说明如何使用它来获取更准确的估算值。始终给出3分的估算值！总是。确保突出显示本书中有关代码质量差将如何影响您的估计的部分。告诉他们给你的老板。

说明如果准确的估算对公司很重要，则需要开始应用从Feather的书中学到的东西。如果您想快速，顺利且可预测地运行，则需要开始重构代码并将其放入测试工具。我一直在你那里。开发时间是完全不可预测的，因为您不知道可能会破坏什么，对吗？将其放入测试工具。运行这些测试的CI服务器也不会受到伤害。

最后，向您的老板解释，一段时间后事情仍然会有些不可预测。可能需要几年的时间，但是随着您拥有更多的数据并且代码变得更好，这种开发每天将变得更加容易，估计也将变得更加准确。这是公司的一项长期投资。我最近经历了这一过程，花了将近两年的时间才可以预测。

我知道我谈论的不是代码估计，而是代码改进。但是，硬道理是，除非您能驯服旧代码库，否则您的估计就很糟糕。同时，使用历史表现来评估需要多长时间。随着时间的流逝，您将要考虑是否已经将代码提高到估算的规格。

现在，我的老板正确地问我一个关于在新架构中编写功能X所需时间的估计。但是我很难提出一个现实的估计。由于我上面提到的原因，我常常低估任务并因为无法及时完成而使自己感到尴尬。

您也许正在考虑提交一个估计的框。我必须使用遗留代码，当我进行更正式的估算时，我通常会做两三个：

1. 主要估算-假设我必须花一些时间来挖掘，但是架构允许我们想要的更改
2. Angelic Estimate-假定一切都是透明的/易于发现的，而我只需要进行少量更改（这是我有时会忽略的更改……尤其是当我知道特定代码库中只有恶魔时）
3. 深渊估算-假定遗留代码的基本结构与所请求的功能不兼容，我将进行大量的重构以使工作正常

所有这三个估计考虑到功能多么艰难其本身，任何经验，我已经与通用代码库，而我的直觉有关的变化（我已经发现可以相当准确）

在得出这些估算值之后，我使我的经理保持最新状态，好像我们正在处理的那样。如果事实证明我们正在研究深渊功能，那么我们可能不得不牺牲它-这是真的。如果您的老板不能接受给定的传统代码块具有深渊功能，那么我希望他们好运，因为他们的生活将非常艰难和令人沮丧。

当我面对此类问题时，我依赖于估算范围。我对老板说：“很难在此代码库上进行现成的估计。如果您要一个，这将是一个非常广泛的估计。” 我给了“ 3天到3年”作为一次估计。不用说这不是一个流行的估计，但这是我给的。

关键是要达成协议，我将随着工作的进展更新我的估算。因此，如果我被告知“实施XYZ，需要多长时间？” 我的答案可能是“一天到四个月之间的某个地方。但是，如果您让我实际看几个小时的代码，则可以减少该窗口中的不确定性。” 然后，我看一下代码，然后返回“ 2-4周”。那仍然不是一个理想的窗口，但至少可以管理。

这里有一些关键：

• 说服老板，将这些估计值更好地视为一次对话，因为您将在工作过程中了解有关任务的更多信息。这是您的老板有机会获得他们仅要求一个估计数就不会获得的信息的机会。
• 提供有关如何推进贸易代码开发速度与改进估算的选择。给他们一个额外的旋钮，他们可以旋转。有时老板知道只需要完成一项任务，而他们只需要估算即可。其他时候，他们正在执行任务的利弊，因此能够完善估算值非常有价值。
• 如果可能，我还将提供协同奖励。通常，对体系结构进行改进会使许多任务受益。如果我有10个任务，而所有这些任务“现在需要1-2个月，而升级X则需要2周”，那么出售升级X可能要花费20周的时间就容易多了。

如果我的老板不愿意接受我随时更新的范围，那么我将给他们一个数字和我的方法。我的方法是将我年轻时被告知的经验法则和霍夫斯塔德定律相结合。

估计您认为任务应该花费多长时间，然后将该数字增加四倍，并将其作为您的估计。

和

霍夫施塔特定律：“即使考虑到霍夫施塔特定律，它总是比您期望的更长。”

明智的做法似乎确实进入了代码，注意到每个分支并调用了其他函数，然后估算了时间成本。但是在记录旧代码与实际写下新版本之间确实有微小的区别。

这是解决您的问题的方法。您无法估计是否没有要求。告诉您的老板，您需要先执行此操作，然后才能开始编码。在完成几个功能和模块之后，您可能会发现它们均已被一致编码（在这种情况下，编码效果很差），因此您有一个基准来确定将来的估算值。如果发现编码变差，只需确保调整估计值即可。

我知道您的老板想要一个估算，但是在不知道如何使用此信息的情况下，我们不知道您的估算需要多么精确。与他交谈并找出答案。如果他只需要一个数字即可提供给老板，您可以稍微增加一些估计值并提供一个数字。对于在此之前等待付款的客户，请确保您确定强行到期日是否会带来可观的收入。

在这种情况下，我认为不可能给出正确的估计。基本的问题是，这样做的很大一部分往往是弄清楚需要做什么。

在处理此类情况时，我会根据可能带来的后果进行估算，但要注意的是，很可能会出现意外情况。虽然我不必以传统代码的方式处理很多事情，但我在处理输入时却遇到了一些非常令人讨厌的惊喜-我看到几个小时变成了几周，一次变成了这是不可能的（大量的挖掘工作使我发现在某些情况下，我没有足够的数据返回到绘图板。）幸运的是，我的老板知道我给出这样的估计。

好吧，估计是某些人从未学过的技能。即使您无法提出正确的估计，它也不会使您作为开发人员变得毫无用处。也许队友或管理层将填补这些空白。我的工作很糟糕，但是大多数团队还是喜欢和我一起工作。保持冷静，组队并进行重构。

技术债务给您带来了很小的挑战，但请记住，最终产生债务的公司/团队将继续产生债务，除非团队精神或管理层有所改变。该代码仅反映了社会问题，因此请关注实际问题。

我们使用一种启发式方法来估计棕地项目中的功能：我们估计了在未实施任何项目的情况下在绿地项目中实现该功能要花多长时间。然后，我们将该估算值乘以2以处理清理已经存在的碎片。

该因素取决于耦合的数量和整体代码大小，但是如果您以此方式执行某些功能，则可以根据实际证据对该因素进行插值。

我认为您应该与您的老板坐下来，直接看着他说：

'听老板！我们只是在这里重构。没有要交付的新功能，也没有客户在等待该功能；所以不应该有任何截止日期。这将花费很长时间，您需要确定我们是否必须这样做。”

使用坚定自信的手势，例如指向并坐在椅子上。

或者，您可以补一些数字，使他高兴。但是，让我们面对现实吧，直到您完成工作的一半为止，您的估计都将非常不准确。