🏚️ 💅 👈 在故事点评估任务 🍧 😡 🖐🏽

几乎每一个接触过软件开发的人都知道什么是Story Points（SP）任务评估，但是，我偶尔会告诉其他部门或新来者的团队中从未遇到过这种方法的同事，为什么我们要使用SP以及为什么对团队方便并且对公司有效。

本文的目的是描述什么是SP，如何使用它们来评估问题，以及为什么这种技术如此普及。

问题

计算完成任务所需的时间是开发团队面临的非常简单且非常冒险的任务。

不正确的评估成为进度表崩溃甚至项目失败的首要原因之一。
问题在于企业将估值视为负债。开发人员将评级视为假设。

为了说明这一点，我将举一个罗伯特·马丁（Robert Martin）的书《理想程序员》中的虚构对话为例。

迈克（经理）：三天内可以管理的可能性是多少？

彼得（开发人员）：我可以解决。

迈克：你能说个数字吗？

彼得：百分之五十或百分之六十。

迈克：那么很有可能需要四天吗？

彼得：是的。甚至可能需要五到六个，尽管我对此表示怀疑。

迈克：您在多大程度上对此表示怀疑？

彼得：哦，我不知道……百分之九十五的人相信这项工作将在六天内完成。

迈克：大概是七个？

彼得：好吧，如果一切都出错了...该死，如果一切都出错了，可能是十天甚至十一天。但是这种巧合的可能性很小，对吗？

我认为以上对话对于任何开发人员或项目经理来说都相当熟悉。

不幸的是，成绩问题并没有就此结束。还应考虑其他陷阱：

等级与等级的相关性

给定的等级仅在等级的作者将执行任务时才有效。毕竟，很明显，高级开发人员和实习生在任务上花费的时间会有所不同。

不完美世界的理想评估

紧急会议，工作信函，使者和失败的任务经理进一步使本来已经很复杂的开发过程变得更加复杂，这使我们想像中的理想时机对试图组装快速老化的甘特图的项目经理有用处不大。

接下来，我们将考虑评估SP中任务的方法以及它如何解决上述所有困难。

替代解决方案

自然，使用SP的方法并不是解决所提出问题的第一个尝试，尽管它可能是最受欢迎的方法。

在这一部分中，我将讨论另一个包含任务评估方案的程序。该程序称为PERT，无需熟悉即可达到教科书的目标，因此您可以安全地继续进行下一个步骤。

计划评审技术

PERT Program Evaluation and Review Technique 50- XX .

:

O: . .

N: .

P: , , .

:

μ = \frac{O + 4 N + P}{6}

$\mu= \cfrac {O+4N+P} {6}$

, :

σ = \frac{P - O}{6}

$\sigma=\cfrac{P−O}{6}$

, :

\frac{1 + 12 + 12}{6} \pm \frac{12 - 1}{6}

$\cfrac{1+12+12}{6} ± \cfrac{12-1}{6}$

, . , , .

故事点

什么是故事点，它们如何帮助评估任务？Mountain Goat Software的敏捷传道者兼首席执行官Mike Cohn对此技术进行了非常简短和清晰的论述。

如果不是评估完成任务所花费的时间，而是评估解决该问题所需的努力，该怎么办？为此，我们将采用评级量表，并在其上执行需要评估的任务。

同时，所有可能影响它的因素都应包括在工作评估中：

所需的工作量；
任务的技术复杂性；
需求可能存在的风险和不确定性；

这听起来并不容易，但是让我们回想一下，我们不需要给每个任务一个明确的评分，我们只需要在其他要评估的任务之间的评分等级中找到其位置即可。

我想强调“故事点”方法的两个重要方面，它们可以解决我们在上一页中讨论的问题：

相对评估

任务是相对于彼此进行评估的，因此出现了不依赖评估者经验的通用等级量表。即使该任务由负责任的任务代替-它的评估将保持不变，请相对于此规模评估相当新的任务。

用抽象点代替手表

因此，我们从评估人员中删除了在数小时内评估任务的需求。相反，他以分数为单位进行评估，因此我们消除了开发人员和经理对评估的认识上的矛盾。而且，现在分心和不可抗力的情况不会以任何方式影响评估，因为它们不会改变解决问题所需的努力！

斐波那契数字，T恤和狗

是的，是的T恤和狗。您可以使用任何比例尺来评估任务。最常见的是斐波纳契数，这些都是清晰的数值，并且还具有很好的好处：该序列的元素很好地反映了由于估计问题的复杂性而引起的不确定性的增长。

但是，某些团队使用替代等级量表。当T恤衫（S，M，L，XL）的尺寸或狗的品种（吉娃娃，哈巴狗，狗）表明任务的复杂性时，最常见的评估是在T恤衫和狗中。因此，团队从评估的数字表示中更加抽象，在某些情况下甚至破坏了向临时评估的转换。

球队得分

团队评估和个人评估有什么区别？
为什么让整个团队参与评分很重要？

评估任务时可能犯的最大错误之一是自己做而不是征询团队成员的意见。也许他们对此有意见？是否要添加新的浏览器支持？质量检查人员对此有何看法？

人是最重要的评估资源。他们可以看到您看不到的内容。

但是如何进行团队评估？仅仅喊成绩并不十分有效，此外，听到您的成绩后，另一个团队成员可能会改变主意，不会发表自己的看法。

扑克筹划

在2002年，James Granning描述了一种后来变得非常流行的方法，以至于现在您甚至可以购买真正的扑克牌来进行扑克筹划。或使用其中一种在线服务进行会话；

该方法的本质如下：向团队的所有参与者分配等级评分表中的数字。然后选择一个任务并讨论其要求。经过讨论，主持人要求团队中的所有成员选择一张卡片并将其倒置。然后主持人发出信号以显示卡。

如果参与者的评分一致，则评分是固定的，否则将卡片归还给手上，团队成员将继续讨论该问题。最好问那些成绩不同的人：“您在这项任务中看到哪些困难？” 或“为什么您认为在实施过程中不会出现问题？”。

值得注意的是，同意不应是绝对的。您可以同意将一组邻近评级也视为同意。

备择方案

像评估方法本身一样，扑克计划也有其他选择。我将简要讨论其中之一。

您可以跳过此块，直接进入下一页。

仿射等级

« . , . , . — . , , , .

, . , . .

, , .

, „“ .

项目计划

Story Point'e有多少小时，我该如何建立甘特图？

因此，我们感谢您积压的任务，但您无法在Story Point'ah上建立项目计划。项目经理通常会提出一个问题：“如何将SP转换为小时？”。

这个问题的简短答案是：“没办法。”

当然，您可以使用秒表跟踪开发人员，并记录解决问题所需的时间，然后在图形中显示此信息。然后，您将获得经典的“钟”，如下面的块中的示例所示。正如我们在第一个图中看到的，有些任务花费更多的时间，有些花费更少的时间，但是总的来说，整个值将对应于一些正态分布。

2 SP中的任务也是如此，这在第二张图中显示。您是否注意到图形的“尾部”相交？是的，某些额定为1 SP的任务可能比额定为2 SP的最简单任务需要更多的精力。最后，还没有团队学会完美评估。另外，将SP转换成几个小时后，我们又回到了以前的样子，开发人员解决特定问题所需的时间在很大程度上取决于开发人员。

但是该怎么办，我们不能完全放弃计划。幸运的是，为此，我们不需要将每个Story Point转换成几个小时。真正重要的是开发团队可以为冲刺（迭代，发布）“关闭”多少SP。

通过收集有关团队速度的数据，您可以获得足够准确的数据以进行长期项目规划。另外，不要忘了大数定律，估计误差是相互补偿的，这适用于任务和迭代。值得注意的是，这有点乐观，因为错误通常与低估而不是重估有关。但是没有什么是完美的。

速度（或速度）是强大的计划工具和开发团队的主要指标。团队必须不断改进以提高速度。别忘了速度是SP的导数，因此也是相对的。您不能将两个团队相互比较，团队之间会相互竞争。

实践

您需要了解哪些细微差别？
可以避免什么错误？

总之，我想为那些第一次决定在其工作中尝试上述技术的人提供一些技巧。

从哪里开始

这是您的第一个扑克计划，团队不了解如何评估新任务。收集一些已经完成的任务，最好是熟悉的或典型的，并评估它们相对于彼此的复杂性。使用这些任务评估新任务。

您是否有一个新项目并且没有完成的任务？尝试使用上述的仿射等级，并将任务分配给等级量表。

不平均评分

有时，当两个团队成员对任务的评价不同时，很容易为任务分配平均分数并继续前进。不要屈服于这种诱惑，讨论是评估的重要元素，在此期间团队可以揭示任务执行过程中以前未知的功能。

但是，如上所述，您始终可以同意彼此接近的估计值不会成为进一步讨论的理由。

不要更改等级，

即使您在实施过程中意识到在计划中犯了一个错误，也不要更改等级。将来，您会在两个方向上都犯错。让这些误差相互补偿，不要干扰过程。

错误等级

我遇到了各种评估错误的方法。一些团队评估所有错误，但在迭代中执行新任务期间会出现那些错误。有些人不评估错误，这是因为团队的速度应该显示出增加到产品中的新价值这一事实，并且修正错误不应影响此指标的增长。

无论选择哪种方法，请保持一致。有关团队历史速度的信息不应受到使用不同评估方法的影响。

零评分

另一个没有明确答案的问题。有人认为，没有不需要付出努力的任务。其他人回答说，将点分配给简单任务会导致团队速度曲线的不合理增加。

您可以为此类任务输入1/2分的分数，并追溯监视此类任务的比例是否超出合理范围。但是主要建议是相同的，请保持一致。

在迭代之间重新评估未

完成的任务即使在最初计划时，也并非总是可以在一个迭代中完成任务。但是，在基于剩余工作量计划下一次迭代时，您不应更改其评估。计划时请牢记这一点，但不要对故事进行任何估算。

回顾性评分

如果您尚未进行回顾性评估，那么该开始了！这是提高团队速度和凝聚力的出色团队工具。但是，这是一个单独的问题。

在回顾过程中，请遍历迭代计划期间所做的估计，并讨论期望与现实之间是否存在较大的偏差。

您还可以从历史中获得具有相同评级的多个问题，并讨论所有这些故事是否确实需要付出相同的努力。

记录所有内容

如果您的任务管理系统不支持等级并且不能自动计算团队速度，那么您将必须手动进行。您可能已经猜到，历史数据是提高成绩的重要工具。

在故事点评估任务

问题