为什么估算用户故事时我们使用故事点而不是工时？

在敏捷方法（例如SCRUM）中，用户故事所需的复杂性/工作量是在故事点中衡量的。故事点用于计算团队在一次迭代中可以获取多少个用户故事。

引入一个抽象概念（故事点）有什么好处，在这里我们可以使用一个具体的度量，例如估计的工时？我们还可以使用估计的工时来计算速度，估计迭代的覆盖范围等。

相反，故事点更难使用（因为概念很抽象），也很难向涉众解释。它提供什么优势？

我认为主要优点之一是，特别是人类和开发人员在估算时间方面实际上很糟糕。也要考虑发展的本质-从开始到结束并不是线性的发展。通常是“在10分钟内编写90％的代码，然后花17个小时进行调试”。从时钟时序的角度来看，这很难估计。

但是使用抽象会使焦点从数小时或数天的实际时间中转移出来，而是将重点放在描述一个任务与其他任务相比的相对费用和复杂性上。人类/开发人员在这方面做得更好。然后，一旦掌握了这些点估计和一些实际的进展，就可以开始以经验为依据。

我怀疑时间估计也会产生观察者效应，而点估计不会产生观察者效应。例如，在基于点的系统中，通过间接忽略将估计和交付方式“提前完成”的动机。

如果您使用斐波那契数（或类似的数字），则它会在估计故事时限制选项的数量。我与一个仅使用低数字的小组一起工作：1、2、3、5、8和13。我们的参考故事是5。这使我们能够在进行Planning Poker时轻松地对故事的复杂性做出快速决策。 。另一个副作用是，评分为13的任何内容可能都没有足够的信息，需要进一步细分。我严重怀疑，如果我们使用原始时间，那会那么容易和直接。

您的产品负责人会说出您的利益相关者的语言，并且应该能够根据需要在故事点和工时（或其他单位）之间进行翻译。在担任PO的那段时间里，我掌握了一些硬数据，即1个故事点= 4个工时，但显然每个团队都是不同的。

编辑：

知道了1分= 4小时后，理论上您可以将Planning Poker牌组更改为4、8、12、20、32和52。但是这些数字很难处理。我认为我会在头脑上将这些值抽象为简单的东西，例如“少于一天”，“一个星期以上”等。如果我要这样做，我还是会坚持使用抽象单元-少讲故事。

这是为了使估算随着时间的推移而变得更好，而无需所有估算器都必须调整其估算。

而不是每个参与估算的人都必须像“好吧。看起来像2个工作日。.但是我们上次冲刺低估了所有内容，所以实际上是2.5个工作日。还是3个？”，它们的表现与往常一样。“ 5个故事点！”

然后，您可以根据先前冲刺中实际衡量的成就来调整对团队可以在冲刺中获得多少故事点的估计。“我们以前每次冲刺都在做90-110个故事点！”

我要说的是，这背后的理论是，与估计绝对值相比，开发人员在估计不同开发任务的相对复杂性方面更好。尤其是如果有多个人估计一个人可以完成的任务（并非每个人的工作速度都与其他人相同）。

愤世嫉俗的选择：我已经看到它说开发人员永远不会按时间估算。如果花费的时间比估计的时间长，那么您已经过去了。但是，如果有需要较少的时间比预计的，开发商可能用它拨弄，沉金板，或者只是放慢脚步，放松一下，因为他们已经拥有一个轻松的任务。将实际时间单位排除在估计之外可能会抑制这些趋势。结束愤世嫉俗的选择。

正如您所说，工时或工时是具体的。因此，当一项任务估计需要5个小时并且需要6个小时时，它现在是一个迟到的任务。

如果您的故事是3分，花了6个小时，花了6个小时，就不晚了，只花了6个小时。速度测量比一个冲刺中完成多少个点更重要，并且这个数字可能会波动，因为它不是具体的。您也不是在衡量每个任务，而是在衡量所有任务的总数。当您在每个任务上有几个小时时，就会有诱惑力来衡量每个任务。发生这种情况时，您将无法在该时间范围内完成冲刺，这是在任何给定任务的时间内完成任务的结果。

这可以是从观点出发的思考过渡。在我甚至介绍敏捷的二手T恤尺寸之前，我曾在一个地方工作过，目的只是为了了解工作量。要点仅是其扩展。

这并不是说没有争议，也没有对点进行任意分配。我们的团队成员几乎总是投票最低的数字，而当他们认为一项任务是1而我们认为是3时，他们抱怨我们正在遭受点通胀。

抽象就是重点。使用“劳动节”作为衡量标准存在许多陷阱，包括：

1. 如果团队不熟悉将要使用的技术，那么很难实时估计任务可能需要多长时间。他们更有可能给出良好的相对估计-例如“任务A所需时间可能是任务B的两倍”。
2. 不同的人以不同的速度工作！如果您使用“工作日”，那么当任务从一个开发人员传递给另一个开发人员时，您几乎必须更改时间估计。谁来定义多少工作构成了“劳动节”？

如果您要估算工时，则可以通过以下简单计算：

user points in story / average user points per developer per day = estimated man days

如前所述，故事点是相对复杂性的度量。一个人可以使用2阶幂（1,2,4,8,16 ...）或斐波那契标度（1,2,3,5,8,13,20 ...）进行估算。作为拥护者，开发人员非常善于说出这样的话：

功能A几乎是功能B的两倍

但是，很难说此功能需要多长时间才能实施。您让速度来平衡它。因此，如果某些东西估计为5，但结果却是13，则较慢的速度将对该迭代进行归一化（或者您可以重新估计）。

现在，还有另一种替代方法，称为“理想日”（有些类似于人工日，但我不确定这是否就是您的意思），而且我知道有很多团队更喜欢这种方式。理想的日子应解释为：

如果这就是我上任后要做的一切，只休息必要的时间，没有打扰，并且拥有我“实现故事”所需的一切，即没有会议，回信等外围活动，

迈克·科恩（Mike Cohn）是许多知名的敏捷传教士之一，他提供了以下故事要点和理想日子的比较

故事点

• 帮助推动跨功能行为，即团队从UI到DB一直到整个过程估计故事的总实现复杂性。
• SP的估计不会衰减，即从现在起的几个月后，一个5分的故事可能仍然是5分，但是理想的一天的估计可能会有所变化，具体取决于该特定程序员所获得的开发技能/速度
• SP是大小的纯粹度量，即，它们仅反映大小和复杂性。期。没有持续时间等，扔了它。那就是速度的工作。但是理想的日子并非如此。实际上，在理想的日子里，倾向于将其与日历日混淆。当SP保持抽象时，可以抗拒与现实进行比较的诱惑。只是尺寸的度量。废话
• 通常比理想的日子快。对于前几个故事来说，这可能有些棘手，但是一旦掌握了它，它就会更快。
• 对于完成故事，不同的开发人员在理想的日子里可能会有不同的看法。我可以在3中做同样的事情，而您可以在5中做同样的事情。SP或多或少在整体上是统一的。可以这么说，他们平整了比赛场地。

理想的日子

• 在团队之外更容易解释；出于明显的原因:)
• 如上所述，起初更容易估算。但是，一旦掌握了SP，它就会自然而然地

现在，选择哪个取决于团队。但是，作为这里的大多数答案和我的个人经验，我更喜欢讲故事。理想的日子并没有比SP带来太多好处（Mike Cohn还与许多其他敏捷福音派人士一起倡导SP）。

故事点还可以帮助您评估团队在一段时间内的绩效提升。此外，随着性能的提高，您无需重新评估所有内容。

举一个使用工时的例子：

团队根据工作日估算不同的任务。它可以工作一段时间，但是一段时间后，您会发现团队完成许多任务的速度比最初想象的要快。因此，团队重新估计了任务。它可以工作一段时间，一段时间后您会再次看到同一件事：团队可以更快地完成许多任务。因此，您需要重新估算，这个故事一次又一次地重复...

为什么？因为您的团队的绩效提高了。但是你不知道。

带有故事点的相同示例：

团队估计用户故事的大小。经过一些冲刺之后，您会看到团队可以为每个冲刺完成约60个故事点。稍后，您会看到团队获得了60多个故事点，也许是70个故事点。然后，团队继续这样，为下一个冲刺拉动更多的用户故事并交付它们。

为什么？因为性能提高了。您可以对其进行测量。而且，在团队绩效提高之后，您无需重新评估所有内容。

首先，人们相对估计要比绝对估计要好。巴比伦人对恒星的相对亮度进行映射和评级是一个很好的例子。他们没有得到正确的绝对数字，但是即使强度非常相似，顺序也很明显。

第二个优点是进行此练习的主要原因是促进对话。如果您在确切的日子开始讨论，对话可能会迅速脱轨。

正如拿破仑所说：计划毫无价值，计划无价。

第三，项目经理不必编辑所有估算，仅因为事实证明估算偏离了例如130％。

故事点反映了问题的复杂性，因此反映了估算准确性的置信度（或风险）。

故事情节高的故事告诉我，用户故事发生了很多不具体的事情。

这样做的目的是看到故事点之间的平衡。如果正在向我展示一个包含所有高故事点的故事的迭代计划，这使我不太有信心该迭代将按预期执行，并且我们需要查看其他故事以进行迭代或开始分解故事。

当与经理或产品负责人交流时，高谈点意味着他们何时获得特定功能将非常朦胧。解决此问题的方法之一是分解故事，希望您可以结合使用高故事点和低故事点，以便可以向产品负责人反复演示进度。

人工工作日估计完成某项工作所需的时间。当您估计的项目非常精确且可测量时，最好使用它们。具体的，众所周知的，可重复的任务可以在工作日中估算出来。

例如，如果一个销售人员平均每天可以打20个客户电话，我们可以计算每个电话花费多少时间，然后我们可以估算出打1000个电话需要多少工时。

在此示例中，因为可以假设所有呼叫实际上都是同一件事，所以可以用统计术语具体地考虑一次呼叫的中值长度。

故事点确定可以在迭代中完成的故事组合。它们用于将具有模糊边界的异构目标组合起来，并衡量在固定时间范围内可以完成多少个目标。他们估计彼此之间工作块的复杂性，以便能够将它们加在一起。

例如，您的团队在迭代1中开发了5个故事，共计23点，在迭代2中开发了8个故事，共计20分。据此，您可以估计，在迭代2中，您的团队将制作一些故事，其总分约为20分在迭代3。

请注意，我们无需确定一个点的大小，尤其是没有任何假设，即每个相同大小的故事将花费相同的时间来开发！我们只处理总和和每次迭代的点。我什至没有提到迭代有多长时间。

如果您走到街上的人那里，问“霸王龙有多大？” 即使大多数人都知道T-rex是什么，它的大小，答案也将有所波动，但没人能真正确定-因为我们没有相对于基线的相对规模。

这就是您要通过预测找出的认知行为，并且许多方法都以“ 我知道了！..我有准确预测的秘诀！ ” 自转周期向大众推销。当您实际进行预测时，您实际上是在大声地说“ 我将允许x天/小时/点来完成该任务 ”，从某种意义上说，这是为要在其中进行的活动创建“时间表”。

对我来说，积分只是在改变边界，除非您是一个乐于说“ *好吧，我们每个冲刺有3周，拇指吮吸 ...我想我们应该为在这个周期中要完成30点！谁与我同在！* “这就是您在预测建模中所能深入的-很好！..实际上，您只是在设定任意预算，仅此而已。然后，您还需要回顾性地看待完成的工作，感觉是“真是可笑，我们做了33pt的冲刺，这很酷”，对此您无能为力。您可以大声疾呼“ 我们达到15分了吗？我们可以”，使用速度来确定您的预算冲刺的中间冲刺。“但是这里存在的危险是您现在正在使用Velocity来衡量生产力而不是产能，据我所知，这是让响应式发布管理（理论要点）发挥作用的关键。

积分系统几乎太聪明了，以至于没有注意到您仍然需要附加相对时间，从商定的“冲刺周期”到您的日常站立状态，其中您围绕持续时间+复杂性制定了一些隐藏规则=“ Max花费了很长时间那个任务 “与生俱来的内在感觉团队代码红色时刻？

人脑无法预测，因为它涉及大量的工作记忆以及长期/短期的回忆，因此就像要求新手数学学生在脑海中进行分数而不是在纸上进行。这就是为什么其他行业从未就预测达成共识的原因，不断地在相对时间内验证预测结果（例如，地质学家永远不会停止预测模型，直到该立方米被挖出地面然后“完成”为止）。

我想说的是，如果您不进行预测的话，积分系统会起作用。您同意基于子块算法的大量工作，但这实际上是最可能的预测方法。实际上，您的发布管理人员会在适合主题的“待办事项”队列中寻找自然中断（即，在Silverlight中，我们的产品经理会等到完成待办事项并将我们最初设置的主题拼凑起来后再进行工作。）从来不知道工程团队在做什么，我们只是有一个基本的概述，然后我们会接手那项工作并围绕它开展营销活动（Microsoft Mix））

当您开始限制依赖速度+时间的冲刺周期内的速度期望值时，只有在这次情况变得更糟时，您才重新回到预测估计值，因为您正在玩“取决于游戏” ...更重要的是，还将杀死团队成长/职业成长的潜力。

您为点数对时间支付的税是点数，您需要点数来寻找替代的度量公式，以跟踪在职技能的开发/指导或开发人员的行为。

由于您仍然需要将“中级开发人员”视为理想的人来附加技能/工作，因此您可以将其他开发人员与此人作为基准，以确定他们如何在团队中持续发展。它还强调了“快速”开发人员占用大量水但却变得无聊甚至更糟的情况，因为他们竞争激烈的截止日期等，使他们工作了更长的时间，并且没有得到认可/报酬。站立的人实际上并没有发掘这一点。每个人说的话，就可以在团队中发现难闻的气味，例如“那个人正在挣扎，请帮助”

接下来还有“继续执行”故事，这些故事不会进入冲刺周期，而是会传播到下一个冲刺周期。如果您将时间因素考虑在内，那么可以轻松地产生连锁反应，但是当您将相对时间因素考虑在内时..再次，您只需回归到“基于时间的预测/估计”，同样，积分系统只是浑水。

如果您想获得积分，那么您将完全忽略时间，而我的意思是完全让时间慢慢流逝，您在构思/方法论。

我以传教士的身份环游世界，我看到很多团队发誓要付出他们亲爱的，因为他们破解了敏捷预测代码……但是，我总是用我的舌头笑着走开，带着“ 是的...你几乎做到了，但是那个情妇我们称之为“时间” ...她只是残酷的... “

迈克·科恩（Mike Cohn）的书“敏捷估算和计划”描述了用“理想日”或故事点进行估算的优缺点，因此，对您的问题的快速回答是，您不必用故事点进行估算。如果在理想的日子里估算更为自然，那就继续吧。

我认为，故事点方法比“人工日”方法至少具有两个重要优势：首先，在SP中更容易估算。SP是相对的，像我们这样的人在相对方面要比像人日方法那样的绝对估计要好。

其次，当您在SP中估算时，您将获得“ SP团队”而不是“个人工时”。当您问“此任务需要多长时间？”时，高级开发人员可以给您1天，而初级学生可以给您5天。那是由谁来完成任务的人日。如果所有者被迫更改（并且将会更改！），则您必须重新安排一切。使用SP，无论执行任务的人还是一样。

令我惊讶的是，还没有人提到帕金森定律。

工作会扩展，以填补完成工作所需的时间。

基本上，如果您估计大型任务的任何时间单位，开发人员将倾向于花费他们估计的时间来完成任务或结束任务。当您在诸如故事点数或衬衫尺码等模糊时间中进行估算时，可以避免这种陷阱。

故事点估计遵循斐波那契数列1,2,3,5,8,13,21 ...

人脑可以轻松地根据大小映射事物。例如：我们有一张明信片，并为其分配了一个故事点2，而三个明信片的大小将意味着2 * 3 = 6个故事点。

故事点6介于斐波那契数列5和8之间，其中5是更接近的数字，因此故事点将为5。