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

#1 楼

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

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


最佳情况-假设一切都正确（a）
最坏情况-假设一切都错误（b）
实际猜测-您认为可能会发生的情况（c）

您的估计是（a + b + 2c）/ 4


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

编辑：

我的回答是：


OP是初级开发人员（基于所选的用户名）。因此，从项目经理或团队负责人的角度来看，给出的任何建议都不是预期的，这取决于开发环境的成熟度。
项目经理已创建了项目计划由相当多的任务组成，计划要花几个月的时间。
要求项目办对其项目经理分配给他们的任务提供一些估计，这些项目经理想要一个合理的数量（而不是
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的质量不做任何假设。糟糕的项目经理会给项目委员会短暂的评估，以获取批准，然后欺负项目团队，以期达到他们承诺的不切实际的截止日期。唯一的防御措施就是保留记录，以便可以看到您给出的估计并接近它们。

#2 楼

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


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

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

https://pm.stackexchange.com/questions/4251/为什么-为什么-teams-the-fibonacci-sequence-for-story-points

https://stackoverflow.com/questions/9362286/why-is-the-fibonacci-series-used-in-敏捷计划扑克

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

#3 楼

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

那你要去买几本书。


软件估算：史蒂夫·麦康奈尔（Steve McConnell）揭开妖术的神秘面纱
迈克尔·费瑟斯（Michael Feathers）有效地使用遗留代码

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

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

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

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

#4 楼

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


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


初级估算-假设我必须花一些时间进行挖掘，但是架构允许我们想要的更改
天使估算-假设一切都是透明的/易于发现的，而我只需要进行细微的更改（这是我有时遗漏的更改...尤其是如果我知道有仅适用于特定代码库中的恶魔）
深层评估-假定旧代码的基本结构与所请求的功能不兼容，我将进行大量的重构以使事情正常工作

所有这三个估计值都考虑到了该功能本身的艰苦程度，使用该通用代码库的任何经验以及我对更改的直觉（我发现这很准确）

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

#5 楼

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

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

有几个关键要解决：


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

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


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

和

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

#6 楼

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


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

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

#7 楼

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

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

#8 楼

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

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

我们使用启发式方法来估计棕地项目中的功能：我们估计在一个项目中实施该功能要花多长时间。尚未实施的未开发项目。然后，我们将该估算值乘以2，以清理已存在的碎片。

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

#9 楼

我认为您应该和老板坐下来，直视他的眼睛，然后说：


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


使用像这样的坚定自信的手势指向并坐在椅子上向前。

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