假设您是项目经理。您可以在几天内为特定开发人员估算特定任务的工作量。执行估计后，您会获得一些最小值和最大值。
在此之后，您将任务委派给开发人员。实际上，您还设置了截止日期。
设置截止日期时使用哪种估计更好：最小值还是最大值？
正如我所见，最小估计可能会给开发人员带来压力，最大估计可能会导致使用分配给开发人员的所有时间，即使任务可以更快地完成（所谓的学生综合症）。两种方法还有哪些优点和缺点？
编辑：
小澄清：我说的是在委派任务时为下属设置截止日期，而不是向我的老板报告。
编辑：
再补充一点：我可以记住我的真实估计，给老板提供稍微大一点的估计，给下属 - 稍微小一点。这个问题涉及到以下问题：提供给开发人员低估以使他更加努力地工作是否是个好主意？
您应该使用最佳猜测，它是最小和最大估计的函数* - 而不仅仅是简单的平均值 -
best_guess = (min * min_weighting + max * max_weighting) / 除数*
* Tom Neyland 建议应该是(min_weighting + max_weighting). 实际上我不确定这是否正确，但它可能比我原来的除数更正确2.0。
您赋予最小值和最大值的权重将取决于任务的复杂性、与任务相关的风险、风险发生的可能性、开发人员的技能等，并且会因组织和组织而异。项目到项目。如果您记录您之前的估计和每个实际花费的时间，您将能够随着时间的推移细化这些估计。
在与高级管理层和客户交谈时，您还应该使用这些值以及信心值。虽然给予最大和尽早交付与给予最低和延迟交付不同，但它仍然表明您无法控制您的开发。
给出信心值和风险概念也将有助于管理预期，因此如果出现问题，它们不会出乎意料。
* 这些最小和最大估计值将通过各种方式获得 - 询问开发人员、过去的经验等。如果轮询开发人员，则实际的最小和最大值应被视为异常值，并以某种方式丢弃或修改。我的意思是您从诸如“如果一切顺利将需要 2 周或如果遇到一些障碍需要一个月”之类的短语中获得的价值。因此，您插入公式的值不是原始数字。
而是要求最好、可能和最坏的情况估计。然后使用程序评估和审查技术。但是，您可能想先看看一些PERT 评论。
对于单个任务或构成关键路径的任务，进行最佳案例估计是不明智的。这就像说这个项目完全没有任何风险和不确定性。如果实际工作不是最好的情况，那么你最终会破坏时间表。最好是手头有一些额外的时间，并通过实施一些不错的东西来打发时间，而不是晚上和周末工作。
另一方面，如果经理们大多采用最坏情况估计，而在软件世界中，它们很容易比最佳情况数字大一个数量级，大多数项目永远不会超过可行性和规划阶段。并非所有风险都会成为现实。
寻求最佳案例估计无助于对抗学生综合症。包括临时里程碑和可交付成果，除了有助于对抗学生综合症之外，它们是获得有关项目进度的可靠数据和及早发现任何潜在问题的先决条件。
既不使用最小值也不使用最大值，而是介于两者之间。
在高估方面犯错更好。从长远来看，它的成本行为要好得多。
为了克服低估造成的压力，人们可能会走从长远来看无益的捷径。例如，承担额外的技术债务最终必须偿还，并且会带来利息。成本呈指数增长。
由于学生综合症导致的效率低下的额外成本呈线性变化。
估计和目标不同。您（或您的经理和客户）设定您需要实现的目标。估算告诉您实现这些目标的可能性。截止日期是一种目标。您选择的截止日期取决于您愿意接受的置信水平（不符合截止日期的风险）。P50（满足截止日期的概率为 0.5）是司空见惯的。有时您可能希望使用 P80 或其他一些置信水平进行安排。请注意，概率曲线是一条长尾曲线，您想要的信心越大，您需要为项目分配时间的时间就越长。
总的来说，我不会花太多时间跟踪单个任务。对于 P50 目标，其中一半无论如何都会迟到。最重要的是聚合的行为方式。当将单个任务估计组合成一个聚合时，最小值或最大值都不合理。所有任务都以最短时间（很可能是 P10 时间）或最长时间（例如 P90 时间）完成的可能性极小：对于 n 个 P10/P90 任务，概率为 0.1^n。
PERT 有一些技术可以得出合理的任务持续时间概率分布并将它们聚合成更大的整体。我不会在这里讨论数学。这是进一步阅读的一些指针：
Steve McConnell：软件估计——揭开黑色艺术的神秘面纱。它非常易读和实用，但至少我的第一版在数学和其他方面有一些怪癖。
Richard D. Stutzke：估计软件密集型系统 - 项目、产品和流程。它更具学术性，更难阅读，但例如更好地解释了数学。
Something which has been missing in many of these answers (perhaps because it's slightly off-topic) is frequent updates. With younger/newer developers this is even more important - read the code they commit, and/or check in daily to ask them for specific, detailed reports.
This also allows you to set tight deadlines for developers without giving them too much stress, because they will know you're around to help adjust deadlines when needed.
Frequent updates give you the most important tool in setting customer/management expectations - early warning of issues which might delay things, and I prefer having that over any formula.
开发人员是否会回到洞穴进行开发，或者在项目过程中是否有很大的机会改变需求？我认为大多数项目都有很大的机会不会顺利进行，因此尝试尽早而不是稍后建立原型可能会更好。
至于最初的问题，我想我会将其分解为几个不同的结果并考虑每一个：
严重低估 -> 这导致了还有很多工作要做，经理似乎无法做出合理的估计。
轻微低估 -> 在这种情况下，要么有扩展，要么范围被削减，要么版本中有一些错误，但这比前一种情况要好。
以质量按时按预算按时完成最后期限-> 尽管一切顺利，这似乎是最佳选择，但我认为这可能不是最好的结果。
轻微高估 -> 在这种情况下，有一些喘息的空间，这意味着事情要么提前完成，要么增加了一些额外的工作。这里的一点是，这似乎比之前的案例提供了一个稍微好一点的结果，比如一些公司将如何尝试将盈利预期小幅超出预期以做得好于预期。
严重高估 -> 我认为这将是最坏的结果，尽管它与第一个类似，因为有人无法提供合理的估计。
这只是我对每个人的看法，其他人可能对它有不同的看法。
如果你试图让开发人员保持他们的最低估计，那是愚蠢的。在任何行业中，没有人能始终如一地达到他们完成某件事的最短时间估计。最终，他们将学会显着填补他们的最低估计值，然后他们将永远不会达到旧的最低值，因为所有估计值都将高于此值。
在敏捷/Scrum 中，您没有设定严格的截止日期，而是设定“这项任务还剩多少小时”。每天，您都会更新剩余时间。您不会跟踪花费的时间，但会跟踪估计的剩余时间，并且您尝试保持诚实。
如果您有懒惰的开发人员，那就不好了，因为他们可以轻松地玩弄那个系统。如果您有物有所值的开发人员，那就太好了。他们很快就会在估算方面做得更好，作为项目经理，您会了解他们的估算有多可靠，并且您会更好地了解根据各个开发人员的估算将哪些估算传递到链上。
稍微转向敏捷，当你发现哪些是哪些糟糕的开发人员时解雇，奖励那些真正付出的优秀开发人员，并拥有一个更高效、更快乐的团队，同时能够向你的上级报告更准确的期望。
如果 min 和 max 之间的差异很大而不是使用一些黑魔法公式，我认为最好的办法是回到开发人员那里并要求他们进行更精细的分解和原型设计，这将导致更好的估计在哪里最小值和最大值之间的差距并不大。
注意问题：在我看来，估计应该由开发人员/架构师完成，因为他们拥有最好的技术知识，能够分解成任务并估计这些任务。
如果您正在为特定开发人员进行估算，并且您知道您的估算对于该开发人员通常是准确的，那么最小值就是逻辑上的截止日期（最初）。在项目过程中，您将根据情况调整截止日期。
如果你对某个特定的开发人员没有什么经验，我深爱的一位以前的经理会要求开发人员自己进行估算，并将初始截止日期设置为该开发人员的最小值和最大值之间距离的三分之一，挑战开发人员击败它。
如果对承诺和过度交付有疑问：您希望成为交付超出预期的人，而不是更少。基于此，总是选择更高的任何估计。
稍微复杂一点：
对于给定的潜在交付，如果您绘制交付时间与它们发生的机会，您将得到一条曲线，它是正态分布的变化，您可以假设开发人员的最低估计将是曲线左侧某处，其最大值朝右侧。
您选择作为估算值的单个数字左侧的曲线下面积代表您在该估算值之前或之前成功交付的概率。因此，如果您在最左侧给出一个数字，那么您击球的机会实际上是零，如果您在最右侧给出一个数字，那么您的机会实际上是 100%。
不太常见的情况是，如果您给出平均值（假设您的最小值和最大值平均得出的值接近实际平均值），您只会在 50% 的时间内达到该截止日期。实际上，如果您使用平均值，您将有一半的时间错过最后期限。我不了解你，但我不喜欢被视为错过一半截止日期的人。
所以你想要一个数字，它会给你一些你击中的东西，比如说，90% 的时间。方便地 95% 代表平均值 + 两个标准差，但如果你不能计算出这个值（而且我们大多数人可能没有数据），我的经验表明：
(3 x 最大值 + 1 x 最小值) / 4
给出合理的结果。
顺便说一句，您告诉开发人员的最后期限完全是另一个问题。就我个人而言，我会在 ((2 x max + 1 x min) / 3) 左右的某个地方给他，其余的作为应急。
大多数估算人员在设置截止日期时使用的第一个错误是假设开发人员每天都会全职从事该任务，这是一个灾难性的错误。即使您使用高估来计算截止日期，这也可能导致无法满足截止日期。低于工作时间但超过了你告诉客户的最后期限是一个大问题。人们请假，生病，履行陪审团职责，必须参加一些新的人力资源政策的必要会议，当有人被卡住时被召集来帮助另一个项目，当他们的旧计算机坏了时必须在新计算机上加载软件，必须研究他们最近部署的代码的生产问题等。如果您估计每个人每天在项目上花费的时间超过 6 小时，那么您在项目开始之前的截止日期已经遇到了麻烦。当我做人力研究时，在计算任何工作需要多少人时，我们使用了一个相当于每天直接工作略多于 6 小时的数字。我们做了很多统计分析，作为我们使用的数字的基础。
我认为您必须根据具体情况决定使用哪些。我们有一些项目，我们知道最高估计可能仍然有点低（通常当管理人员无法用真实估计面对客户时），我们还有其他一些我们正在做一些新的事情，我们知道估计更多可能会关闭，在这种情况下，请使用最大值。但是对于您之前所做的工作是明确定义的，并且您知道分配的开发人员不会学习新技能，然后更接近最低要求（但永远不要真正使用最低要求，路上会有意想不到的颠簸） . 此外，项目越短，您就越有可能满足最低要求，对于为期一周的项目比为期一年的项目更容易获得良好的估计。
更重要的是每次情况发生变化时都会改变估计和截止日期。如果客户增加工作，延长期限和估计，不要只是这样做。如果您最好的开发人员退出并且您必须让新的人参与该项目，请延长截止日期，因为该人必须有时间赶上进度（尽管您可能不得不吃时间，客户可能不同意为此付费时间。对此至关重要的是立即告诉客户。他们往往更倾向于推迟截止日期（尽管不高兴），而不是错过一个截止日期或完成交易，但产品并没有像他们期望的那样工作。太许多项目经理只是希望问题消失，而不必面对与客户的对话。
你用这些估计做什么？具体来说，如果您通常低估，为什么开发人员会感到压力？
如果你试图安排某件事可能需要多长时间，你会选择一个中间值。可能是长期的，因为人们通常会低估。在任何情况下，您都不应该将这些估计用作开发人员的坚定目标，因此他们不应该过度紧张。
如果您使用这些估计来建立承诺，那么您需要在高估方面犯错。给开发人员足够的时间会导致倦怠，无法维护的错误代码不能完全满足用户的需求，以及士气低落和高流动率。设定可实现的承诺，并鼓励开发人员尽早完成。
这取决于项目。
有些项目可能需要快速开发，如果截止日期已经确定，并且没有很好的机会来延长开发时间，那么就没有其他选择了。典型问题：营销活动带来新服务。这样的截止日期对于正常的开发来说已经足够了，但在某些组织中，它是如此接近，以至于开发人员在压力下工作并犯了许多在生产阶段得到修复的错误。当开发人员必须以最高效率工作并且他们最好在成功时获得良好的奖励时，这是一种项目。
有些项目计划准确，在这里您可以使用您拥有的所有分析：历史数据、一些开发人员在子任务上的时间指标、计算风险等。
但无论如何不应使用 MAX 时间：它是最不准确的度量，通常会导致花费更多时间。这里有一个简单的原因：当开发人员只是放弃这个 MAX 时，他几乎没有测量。他只是放弃了当时几乎没有信息的直觉。但如果他至少花半个小时，他就会了解他的任务细节，他甚至可以将其分解为子任务并提高他的准确性。所以你可以给开发人员一些偏见，比如“嘿，伙计们，想想什么时候你会在这里提供稳定的代码”，但让他自己测量。对工作有好处，对程序员自己也有好处。