谁应该参加时间估算？

在一个IT项目中：

1. 谁应该参加时间估算？开发人员，团队负责人，Scrum主管等？
2. 谁的票数最多？

与所涉及的人员无关的只是需要呈现的技能：

• 充分了解问题域-当需求含糊不清或较高水平时，这一点尤其重要。作为从未在旅行中工作过的程序员来估计飞机上机票舱位的工作，他们会假设有3或4（经济，商务，头等），但是如果您在旅行中工作，就会知道那有几十个。这可能意味着要涉及业务分析师或专家用户，尽管随着时间的推移，开发人员自己将积累这种知识。

• 对技术和将要涉及的工作的理解-通常是开发人员，尽管是具有最新经验的经理，并且对团队充满信心，但通常可以胜任。理想情况下，尽管您找到了将实际从事这项工作的人，但这样他们才被纳入估算。

• 了解估算过程-这是关键。需要了解如何进行合理的估算，如何确保估算正确，检查适当的应急费用，检查重复计算或填充过多。通常，由PM，开发经理或高级开发人员来带这个，尽管在某些过程中，可靠的评估模板可以提供必要的指导。

这些技能可以是一个人，尽管有时需要三个或三个以上，但是关键是要确保这些技能存在，而不是特定的人存在。

就是说，虽然我通常会寻找两个以上的人，但是您想要两个或两个以上互相检查工作的人的额外保证。

就得票最多的人而言，它并非如此。这是一次讨论和谈判。如果经理认为开发人员的估计值过高，则需要解释原因并向开发人员提出要求（而不是施加压力）以证明其合理性，他们需要达成共识。万一您不能达成协议，根据经验我会说两件事：

（a）不要随便加上您想要的数字，它只是在问麻烦，而您想要的东西对完成工作的速度没有实质性的影响。

（b）在几乎每种情况下，我都看到开发人员被超出了估计的范围，最终数字比开发人员认为的更接近开发人员的想法-主要是因为他们忽略了（a）点以上。

（我相信这是敏捷的，当然，在XP中也是如此，规则是开发人员控制估算，这是最终的。如果用户想降低估算，则必须将要求更改为更简单的要求。）

我不知道这个问题是否有千篇一律的答案。在我工作的地方，通常会有团队中的两名工程师来实施可提供估计的功能/修复。因此，两名工程师分别提供了“最小”，“最大”和“预期”估算值。通常，我们希望两个估计值都可以合理地保持一致，因此，如果它们之间存在巨大差异，则可能需要进行进一步讨论（也许一个工程师已经做出了假设，而另一个则没有）。

在我们的情况下，没有人的“票数”是这样计算的。我们通常只对这两个估计值求平均（请记住，如果它们不在同一范围内，那么我们将两者拒绝，然后重新开始讨论，因此取平均值并不是一个大的飞跃）。毕竟，估算值只是估算值，因此它们不必很精确。

根据我的经验，估计通常由最有可能自己完成任务的人来完成。SCRUM团队应该努力实现跨职能，但是过一会儿，某些类型的任务通常是由同一个人完成的。

至关重要的是要使团队接受所有评估。如果开发人员认为自己拥有估算，他们将努力实现。如果开发人员得到了他们自己没有做，没有投入或影响力的估计，他们将不会对此负有同等的责任，透支将用“我告诉过您将需要更长的时间”进行解释。

项目的业务要求和截止日期自上而下。这些是第一次迭代的“给定估计”。

这些需求必须划分为具有100％已知成本的最大任务（例如“启用日志记录” = 2小时=“下载log4j / SLF4J并插入”）。

估算应该在已经具有足够技术专长的可能的最高水平上进行。

校正后的估算必须以“业务可见特征” =“此时间量”的形式返回，直到达到合适的水平，能够放弃/更改需求或放松期限。然后放下。直到最终收敛。实际上，人们倾向于忽略或简化此阶段，这反过来可能会带来与错过截止日期和机会相关的风险。

谁或谁应该参与时间估算？开发人员，团队负责人，Scrum主管等？

我希望所有人都在时间估计中，我们在这里做同样的事情

谁或谁的票数最多？

开发人员，但仍然是团队工作的全部内容

开发人员对项目的实施充满信心！没了！

真正能够实际工作的开发人员和开发团队负责人是唯一能够正确估计实际需要多少时间的人。只有熟悉实际代码库的程序员才能理解在开发过程中可能遇到的潜在困难和陷阱。其他人都是“旁观者”。

此外，可以信赖的开发人员提供准确估计的唯一方法是，当商人信任他们并依靠他们的专业知识时，开发人员就会知道，如果他们的估计不符合业务的期望，他们将不会受到惩罚。

经验法则：对于任何不十分熟悉动手开发和相关代码库挑战的项目经理或业务人员，估计至少需要3倍的时间。

作为从事开发人员兼职开发人员以及在大型公司中工作了近20年的人，我非常确定地说出这一点，并从许多痛苦的经验中受益。