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

#1 楼

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

但是使用抽象会使焦点从实际的时间（以小时或天为单位）上转移，而是将精力集中在描述任务的相对费用和复杂性与其他任务相比。人类/开发人员在这方面做得更好。然后，一旦掌握了这些点估计值和一些实际进展，便可以开始更凭经验观察时间。

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

#2 楼

如果您使用斐波那契数字（或类似的数字），则它会在估计故事时限制选项的数量。我与一个仅使用低数字的小组一起工作：1、2、3、5、8和13。我们的参考故事是5。这使我们能够在进行Planning Poker时轻松地对故事的复杂性做出快速决策。 。另一个副作用是，评分为13的任何内容可能都没有足够的信息，需要进一步细分。我严重怀疑，如果我们使用原始时间，那会如此简单和直接。单位）。在担任PO的那段时间里，我掌握了一些硬数据，即1个故事点= 4个工时，但是显然每个团队都不一样。 1分= 4小时，从理论上讲，您可以将Planning Poker的套牌数更改为4、8、12、20、32和52。我认为我会在头脑上将这些值抽象为简单的东西，例如“少于一天”，“一个星期以上”等。如果要这样做，我还是会坚持使用抽象单元少的故事点。

#3 楼

这是为了使估算随着时间的推移而变得更好，而无需所有估算者都必须调整自己的估算。但是上次冲刺我们低估了一切，所以也许实际上是2.5个工作日。或者3个工作日？”，他们的表现一如既往。 “ 5个故事点！”

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

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

愤世嫉俗的选择：我已经看到它说开发人员永远不会按时间估算。如果花费的时间比估计的时间长，那么您已经过去了。但是，如果某些事情花费的时间少于估计的时间，则开发人员可能会摆弄它，镀金，或者只是放慢脚步，因为他们被分配了一个轻松的任务而变得轻松。将实际时间单位排除在估算之外可能会抑制这些趋势。结束愤世嫉俗的选择。

#4 楼

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

当您的故事是3分且需要6个小时时，则花费了6个小时，不是很晚，只花了六个小时。速度测量比一个冲刺中完成多少个点更重要，并且这个数字可能会波动，因为它不是具体的。您也不是在衡量每个任务，而是在衡量所有任务的总数。当您在每个任务上有几个小时时，就会有诱惑力来衡量每个任务。当发生这种情况时，您将无法在该时间范围内完成冲刺，这是在任何给定任务的时间内完成任务的结果。 。在我甚至介绍敏捷二手T恤尺寸之前，我曾在一个地方工作过，目的只是为了了解工作量。要点仅是其扩展。

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

#5 楼

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


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

如果要估计人工日，这是一个简单的计算：

#6 楼

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


功能A的难度几乎是功能B的两倍。


说此功能需要多长时间才能实施。您让速度平衡。因此，如果某个东西的估算值是5，但结果却是13，则较慢的速度会将其标准化，以进行迭代（或者您可以重新估算）。这被称为“理想的日子”（有些类似于“工作日”，但我不确定这是否就是您的意思），而且我知道有很多团队喜欢这样做。理想的日子将被解释为：



如果这是我上任后要做的，并且只做必要的休息，没有打扰，将拥有我所需要的一切以“执行故事”，即没有会议，回复邮件等外围活动，


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


帮助推动跨职能行为，即团队估算故事的发生率从UI到DB再到DB的总实现复杂性。
SP估计不会衰减，即从现在开始的几个月后，一个5分的故事可能仍然是5分，但是理想的日估计可能会有所不同该特定程序员获得的开发技能/速度
SP仅是尺寸的度量，即仅反映尺寸w.r.t.复杂。期。没有持续时间等，扔了它。那就是速度的工作。但理想的日子并非如此。实际上，在理想的日子里，倾向于将其与日历日混淆。当SP保持抽象时，可以抗拒与现实进行比较的诱惑。只是尺寸的度量。废话。
通常比理想的日子快。对于前几个故事来说，这可能有些棘手，但是一旦掌握了它，它就会更快。我可以在3中做同样的事情，而您可以在5中做同样的事情。SP或多或少在整体上是统一的。他们可以说出公平的比赛环境。由于明显的原因:)
如上所述，起初更容易估算。但是一旦掌握了SP的知识，现在就自然而然地

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

#7 楼

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

以使用工时为例，此示例：

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

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

带有故事点的相同示例：

团队估计用户故事的大小。经过一些冲刺后，您会看到团队可以为每个冲刺完成约60个故事点。稍后，您会看到团队获得了60多个故事点，也许是70个故事点。然后，团队继续这样，为下一个冲刺获取更多的用户故事并将其交付。因为性能提高了。您可以对其进行测量。而且，在团队绩效提高之后，您无需重新评估所有内容。

#8 楼

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

第二个优点是进行此练习的主要原因是促进对话。

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

第三，项目经理不必编辑所有估算，只是因为估算是相差约130％。

#9 楼

我很惊讶还没有人提到帕金森定律。


扩展工作以填补完成工作所需的时间。如果您估计大型任务的任何时间单位，开发人员将倾向于花费他们估计的时间来完成任务或结束任务。当您在诸如故事点或衬衫大小等模糊时间中进行估算时，可以避免这种陷阱。

#10 楼

故事点反映了问题的复杂性，因此反映了估计的准确性的置信度（或风险）。用户故事并不具体。

这个想法是要了解各个故事点之间的良好平衡。如果正在向我展示一个包含所有高故事点故事的迭代计划，这使我不太有信心该迭代将按预期执行，并且我们需要查看其他故事进行迭代或开始分解故事。 />
与经理或产品负责人交流时，高谈吐度意味着他们何时获得特定功能将非常朦胧。解决此问题的方法之一是分解故事，希望您可以结合使用上下故事点，以便可以向产品负责人迭代地演示进度。

#11 楼

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

例如，如果一个销售人员每天平均可以打20个客户电话，我们可以计算出每个电话需要多少时间，并据此可以估算出需要多少工作日。 1000个呼叫。

在此示例中，可以从统计角度具体考虑呼叫的中位长度，因为可以假定所有呼叫实际上都是同一件事。点确定可以在迭代中完成的故事组合。它们用于将具有模糊边界的异构目标组合在一起，并衡量在固定时间范围内可以完成多少个目标。他们估算出彼此之间工作量的复杂性，以便能够将它们加在一起。

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

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

#12 楼

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

您要通过预测来找出的认知行为以及许多方法用“我知道了！..我有准确预测的秘诀！”旋转周期向群众蛇油。当您实际进行预测时，您实际上是在大声地说“我将允许x天/小时/点来完成该任务”-从某种意义上说，这是在该活动中创建一个“时间表”。 br />对我来说，积分最终只是在改变界限，除非您所在的团队乐于说“ *嗯，我们每个冲刺有3周的时间，拇指吮吸...我想我们应该在该周期内拍摄30点才能完成！谁和我在一起！*”，这就是您在预测建模中所能达到的深度-很好！ ..实际上，您只是在设定任意预算，仅此而已。然后，您还可以回顾性地看一下完成的工作，感觉是“真可笑，我们做了33pt的冲刺，这很酷”，对此您无能为力。您可以大声疾呼：“我们达到15分了吗？”，您可以使用速度来确定您的预算冲刺的中间冲刺，但是您会增加相对时间，不是吗？危险在于，您现在正在使用Velocity来衡量生产力而不是能力，据我了解，这是影响响应式发布管理（故事点）的原因。
该点数系统几乎太聪明了请注意，您仍然需要将相对时间附加到方程式上，从您同意的“冲刺周期”到日常站立，其中您围绕持续时间+复杂性制定了一些隐藏规则=“ Max花费了很多时间去完成这项任务”固有的直觉红色的时刻？

人脑无法预测，因为它涉及大量的工作记忆以及长期/短期的回忆，因此就像要求新手数学学生在脑海中进行分数计算而不是在纸上进行。这就是为什么其他行业从未就预测达成共识的原因不断地在相对时间内验证预测结果（例如，地质学家永远不会停止预测模型，直到该立方米被挖出然后“完成”为止）。重新预测。您同意基于子块算法的大量工作，但这实际上是最接近预测的方法。实际上，您的发布管理人员会在适合主题的“待办事项”队列中寻找自然中断（即，在Silverlight中，我们的产品经理将等到完成待办事项并将我们最初设置的主题拼凑起来后再进行。）从来都不知道工程团队在做什么，我们只是有了一个基本的大纲，然后我们将把它作为工作基础并围绕它开展营销活动（Microsoft Mix））

在依赖速度+时间的冲刺周期内的速度期望值，只有在这次情况变得更糟时才重新回到预测估计值，因为您正在玩“取决于游戏” ...更重要的是，您还正在消灭潜力

要支付的积分与时间的税是积分，您需要寻找替代的度量公式来跟踪在职技能的发展/指导或开发人员的行为。 >
因为您仍然需要将“中级开发人员”视为与您的技能/精力相结合的理想人选，因此您可以将其他开发人员与该人作为基线，以确定他们如何在团队中持续发展。它还强调了“快速”开发人员占用大量水但却变得无聊甚至更糟的情况，因为他们竞争激烈的截止日期等，使他们长时间工作并且无人认可/报酬。在那里每个人说说就能发现团队中难闻的气味，例如在“那个人正在挣扎，需要帮助”中。

接下来还有“继续”故事，这些故事不会被冲刺循环，然后继续进行下一个冲刺循环。如果您将时间因素考虑在内，则可以轻松地产生连锁反应，但是当您将相对时间因素考虑在内时..再次，您只需回归到“基于时间的预测/估计”，并且积分系统只是

如果你要点，你会完全忽略时间，而我的意思是完全让时间慢慢流逝，这就是在构思/方法论。

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

#13 楼

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

#14 楼

我认为Story Point方法比Man-day方法至少具有两个重要优势：
首先，在SP中更容易估算。 SP是相对的，像我们这样的人在相对方面要比像人日方法那样的绝对估计要好。当您询问“此任务需要多长时间？”时，高级开发人员可以给您1天，而初级学生可以给您5天。那是由谁来完成任务的人日。如果所有者被迫更改（并且将会更改！），您必须重新安排一切。使用SP，无论执行任务的人还是一样。

#15 楼

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

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

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