开发人员应该接受Excel宏完成的工作量估算吗？

在一个新项目中，一个朋友必须编写测试，编写测试所需的时间是由他的非开发人员经理编写的Excel宏计算出来的。

在这种情况下，开发人员是否应承担在计算的时间内编写和运行测试的责任？这些测试的结果值得信赖吗？

为了提供信息，我的朋友拒绝对他未做的估算负责，要求成功完成另一个项目，并由经验不足的校外“老兄”代替。

这取决于他们对开发人员的敏感程度以及他们所基于的数据/逻辑。（它们可能基于几年来收集的统计数据，该统计数据表明该开发人员本人和/或其他人过去需要多少时间才能解决类似的任务...或者它们可能完全基于其经理的权限-正确或不正确-假设。）

理想情况下，他应该与他的经理讨论不能合理地期望一个人去承担和承担别人估计的任务。

完全拒绝承担这些估计确实可能会导致他迅速被替换，因此最好是采取一种较柔和的方法，并尽可能避免直接对抗。

假定宏正在某种输入数据上运行，这不只是一个随机数生成器吗？因此，为了回答您的问题，我们需要知道什么是输入数据以及宏的功能。没有这个答案，答案就毫无意义。

或者，您的问题真的是关于接受缺乏相关经验的经理产生的估计值吗？在这种情况下，答案是否定的，您（或您的朋友）应提出自己的估计并将其提交给经理。如果两个数字不匹配，那么他们需要共同努力，找出最佳的前进方法-可能同意编写更少的测试，或者花费更长的时间编写所有测试。

点空白拒绝不会帮助任何人，并且在无法满足的时间范围内工作也不是一件有趣的事，解决方案在于采取专业方法并做出妥协，以使工作能够继续进行。

绝对没有。

一个小程序，甚至是一个大型，复杂的程序，都无法估计任何编程工作将花费多长时间。有关原因，请参见软件估计的数学限制。也有较长的，经过同行评审的论文，《软件估计的大限制》。

我还要重新考虑对经理的看法：他或她为什么认为过去没有尝试过电子表格宏，因为过去尝试过其他所有方法来估计软件任务持续时间。

啊!

这是巨大的“工作气味”。这是令人难以置信的微观管理。

如果他们不信任自己的员工提供估计，那么他们不信任您吗？

绝对没有。

我向您保证，经理并不会因此而认为他的Excel宏可以准确地预测估计值。我什至没有争论一个众所周知的事实，那就是涉及太多变量，无法在算法中准确预测这样的事情。如果他发明了这样的算法，他应该为它申请专利，并且在我看来可以赚到数百万美元。

真正发生的是，经理正在使用这个假定的Excel宏作为掩盖的伪装，以掩盖他逼迫不切实际的期望和对开发人员造成不当压力的事实。

他知道这是BS，并且不在乎，这是借用过多的资源并试图通过使所有“毫无价值的”开发人员永久地“延迟”来更快地完成工作的借口。

这位经理听起来像个剥削性的混蛋。

在一个新项目中，一个朋友必须编写测试，编写测试所需的时间是由他的非开发人员经理编写的Excel宏计算出来的。

存在用于估计项目（包括软件项目）完成时间的参数估计模型。通常，估算是针对生产代码的，但是我不明白为什么不能将其外推到估算编写测试代码将花费多长时间。但是，这些估算值仅与输入的估算值一样好。

假设所使用的方法是有效的估计模型，并且数据准确且有效，则没有理由不能由非开发人员经理编写的Excel宏得出良好的估计。

在这种情况下，开发人员是否应承担在计算的时间内编写和运行测试的责任？

在任何情况下，都不应盲目接受任何估计。不管是如何产生的，没有一个估算是完美的。由工程师来审查所有估计，确定潜在问题，评估其影响以及根据需要讨论和完善估计。

这些测试的结果值得信赖吗？

测试仅与设计和实施它们所付出的努力一样好。如果测试人员进行的测试质量低下，则缺陷会贯穿测试并进入项目的后期阶段。理所当然的是，进度压力会导致测试质量低下，因此，如果时间不足以设计适当的测试用例，然后再实施这些用例，则测试将不会有用。

听起来您在问两个不同的问题：

这些测试的结果值得信赖吗？

Excel是与我们合作的任何其他工具一样的工具，计算的编写内容实际上不会对算法本身的结果产生影响。估计来自Excel宏的事实与计算结果（即估计的有效性）是否有效无关。如果您在基础模型中有错误的假设，则使用什么方法都可以，因为基础假设不正确。

在这种情况下，开发人员是否应承担在计算的时间内编写和运行测试的责任？

如果开发人员要求在指定的时间内完成工作，那么只要估算是合理的，他们就无济于事。这就引出了下一点：如果计算给出了合理的时间，并且它们与开发人员将给自己的估计相似，那么没有理由不反对给出的时间表。实际上，这可能对开发人员有利，因为开发人员可能会影响模块中使用的假设，而与给定任意时间表无关。

如果时间表对于所需的工作量似乎不可行，那么显然他们应该提出这个问题，并尝试与经理合作以获得更切合实际的时间表，但是如果时间表可行，那么他们将很难反对。

是的，就项目管理和估计时间表而言，是可以做到的，但它高度依赖于所完成工作的性质。与编写针对测试用例的用例编写新代码相比，您可能会看到编写单元测试代码所需的时间（假设开发人员理解框架并已编写过）的准确估计数更高。对于。

我不想轻描淡写编写测试，但是该项目以前可能已经有多个开发人员编写了测试。如果基于这些数据进行估算，则它们可能比您的朋友所假设的更为准确。由于您的朋友离开了该项目，没有尝试创建相反的估算或查看它们是否可以按预期完成，所以我们永远不会知道。

他要做的就是完成一两个测试，以查看估计的准确性，然后带着合理的辩解回到经理那里。可能还有其他团队成员可能对估计的可靠性或落后的后果提供了反馈。有时候，一个经理不得不给老板一些“东西”，以使每个人都开心。开发人员将其视为一种错误的安全感。也许如果开发人员有一种运动来提供估计并显示完成任务的意愿，那么管理层可能会建立更多的信任。

我的猜测是，如果他能够在更短的时间内完成测试，他什么也不会说。再说一次，将自己从他不相信的实践中解脱出来，可能表明他的诚信水平很高。

简单而简短的答案：

您不在乎估算的来源。

您真正关心的是估算本身。它同意或不同意，并解释为什么又有多少你会估计。那是最重要的。

从理论上讲，开发人员永远不应该接受任何其他人做出的估算，无论它是如何得出的。原因之一是，给出比您的经理满意的更长的估计数会立即暴露出潜在的进度问题，或者可能会误解要完成的工作范围。

人们通常会发现编程时间估计比编程本身还要困难，因此，如果您的经理可以编写一个Excel宏可以解决该问题，则他可能可以构造一个宏来编写代码（不太可能）。

现在，在实践中，如果您理解这项工作并且估算看起来合理，则只需对通过的方法表示一些担忧，然后临时同意看看您是否可以满足他们，这是有道理的。稍后，如果这项工作花费的时间超过了估计的时间，则应尽早提请经理注意。准备根据您的实际实施经验讨论确切原因。希望到那时，您的经理不会变得不合理，并继续坚持要求您以机械方式生成估算值。

敏捷是最新的软件开发方法之一，而scrum是著名的敏捷框架之一。但是在这种方法中，开发人员（Scrum团队）负责计算完成任务或实现用户故事所需的时间。

我肯定地说NO。因为：

1. 非开发人员经理无法估计完成工作所需的时间
2. 估计完成任何工作所需的时间需要一些人的智能，而Excel没有
3. 通过接受这样的工作习惯，经理逐渐习惯于在估计时间上取代开发人员。这可能会导致灾难。考虑这种情况，您的经理说：

我想启动一个新的在线销售自行车项目，我知道您和约翰需要3周的时间才能完成。