个人能力应该从故事的角度考虑吗？

Question

我对故事估计的理解是，人们应该估计一个故事的大小，就像一个虚构的、普通的开发者一样--有点像法律上的“合理旁观者”的概念。也就是说，假设你必须这样做，你就不应该估计故事的大小。

举个例子:在我以前的工作中，我是一个团队的一员，在那里我一直是最自信的Ruby开发人员。我的队友通常会估计Ruby相关的故事要比我大得多，争论说：“嗯，我不知道X在Ruby中是如何工作的，所以这需要我花很长时间才能做到。”

我反对这一点的理由是，冲刺计划是团队能力发挥作用的地方。这是正确的论坛说，“我们的能力这个冲刺将略低于通常，因为大多数任务是基于Ruby的，我们只有一个强大的Ruby开发人员。”在估计过程中考虑到这一点将使这个方面加倍。

我希望有权威的答案参考，但简单的意见也会很好。

Answer 1

故事要点是一种相对估计。所以两倍的分数意味着两倍的努力。相对估计较少受技能水平变化的影响。问题不在于你花了多少时间来获得1分，而是那2分需要2倍的潜在努力。如果你选择理想日子而不是故事点，技能水平可能会更重要，因为你假设一个人的生产力水平。

相对估计更为稳健。此外，故事点评估不应由个人执行，而应由集体团队努力执行。对于不那么复杂的故事，通常会很快达成一致。对于更具挑战性的故事，团队将带来大多数成员都同意的结果，因此隐含地考虑到团队的集体技能水平。

最后，故事评估是在团队内部的任务不一定已经确定的时刻执行的。这是另一个不考虑个人技能水平的论点。对于短跑计划，您将使用团队的故事点能力，这是一个基于实际绩效数据的数字，以便它能够自我调整以适应团队的全球技能水平。

总之，评估不应考虑个人能力。但是，即使这样做，由于集体的估计，和稳健的相对方法，这不会有多大的关系。

Answer 2

典型的答案是，您不应该更改每个开发人员的估计值。这意味着你每次冲刺得到的分数比你的同行多得多，这很好，因为点数衡量的是团队的速度，而不是开发人员。业务可以估计团队将生产多少，以获得交付的粗略期望，而且一切都很好。

然而，这在实践中却造成了各种各样的麻烦。如果你那个星期在度假会发生什么？当复习时间到了，你意识到你能创造200%的平均故事分数，而平均工资的110%，会发生什么呢？当企业开始认为团队的速度除以人实际上是一个精确的近似时，会发生什么？当企业意识到你比你的同行产生更多的bug(而忽略了你产生的功能)时，会发生什么呢？什么是“咬大小”的故事，当人们有这样不同的咬伤？

在我的职业生涯中，我发现这在很大程度上并不重要。过程是为你服务的，而不是反之亦然。如果您的组织需要评估开发人员是否超载，那么每个开发人员的故事点就是一个很好的解决方案。如果你的组织需要衡量团队的速度，那么不可知的故事点将提供一个更清晰的画面。然而，它们总是近似值，总是会被滥用和曲解。

最后，它们是为您需要适应您的环境所需的组合过程而组成的。

Answer 3

博士我们应该总是假设只有有能力的开发人员才会被分配到特定的故事中。能力(或缺乏能力)不是侮辱。这仅仅是对开发人员的技能的合理衡量，他们既没有落后，也没有特别的经验。

这可能是一个特定公司的方法问题。我见过一些公司为特定的开发人员量身定做估算。我还见过一些公司实施了一个系统，其中三个随机选择的开发人员在几乎随机分配开发人员(而不是最初的三个开发人员之一)执行任务之前，进行了故事评估。

每个系统都可以工作，每个系统都可能失败。问题不在于哪个系统更好，而在于公司能够/愿意处理哪些缺陷。

原则上，不应包括掌握语言/框架的学习时间。小切线:虽然它们不应该存在于一个理想的世界中，但研究项目或故事中的障碍的时间应该包括在内。

这样做有很多理由，但我相信这种做法通常是一个更好的选择，因为它始终符合估计工作量的意图。这可能只是我的看法，而不是客观。我说不准。

学习时间是私人的。它适用于需要在特定技术上工作的特定开发人员。在评估用户故事的工作负载时，它与此无关，因为用户故事只存在于应用程序的范围内(以及它使用的技术)。

学习时间一般不堆叠。假设我们的菜鸟对C#知之甚少，我们估计他需要额外三天才能完成工作。正如在我工作过的许多公司中常见的一样，我们现在正在开会，我们需要估计几个用户故事(单独的)。举个例子，假设我们有三个故事要处理。

• 我们给每个故事加三天吗？如果这三个故事都有一个相似的技术重点，这意味着新秀实际上不需要额外的时间在第二和第三个故事。我们把这项工作高估了六天。
• 我们给每个故事加一天吗？这也不对。如果我们只把新手分配给三个故事中的一个，那么我们就缩短了他需要的两天学习时间；我们给了其他开发者两个不必要的学习时间(S)。
• 我们给一个故事加三天吗？我们如何保证这件事会在其他两人之前被处理？创建单独的用户故事的全部意义在于，这些故事通常可以相互独立地处理。我们现在估计的正确性取决于两个假设，即我们的菜鸟将完成这项工作，以及分配给他这些任务的顺序(如果这很重要，例如，如果合并的工作量超过一个sprint)。

注意: 还有其他情况下，学习时间确实是堆叠的，例如，如果这三个故事的主题非常不同，并且需要不同的skills.，但是为了确定是否是这样，我们需要同时查看所有三个故事，这慢慢地违反了拥有独立用户故事的原则。如果我们在单独的会议中处理这些估计，可能会有不同的开发人员在场；我们将无法准确地估计故事之间的重叠。

因为我们不能保证哪些故事最终会被完成(客户可能会拒绝一个很大的估计)，以及谁会被分配给他们，试图解释一个特定的开发人员被分配到一个特定的故事是徒劳的。结果只会把水弄混。

相反，我们应该给出一个工作量的估计假设新秀已经被培养到了速度(因此是一个与他的同事一样的开发人员)。

这样的估计与开发人员无关，因此，评估的正确性并不取决于哪个开发人员最终被分配到故事中。

注意，承认一个特定的开发人员可能需要额外的时间来学习，然后才能处理一个特定的故事，这仍然是相关的。这仍然是一个非常相关的考虑。但是这种考虑不应该附加在故事中，而应该是将这个特定的开发人员分配给这个特定的故事。

但是，正如我一开始所说的，这可能因公司而异。有些公司可能对学习时间不那么在意(例如，如果开发者不可避免地要学会使用这项技术)。其他人可能在很大程度上依赖于这些估计的准确性，因为它会影响对客户的计费。

最后，这是一个挑选你的毒药的问题。所有这些方法都不能保证比其他方法更准确。