在冲刺中计划扑克的目的是什么？

我们的业务分析师和项目负责人告诉我们客户的故事要求。在每个Sprint计划中，我们（开发人员）都被要求玩计划扑克。

他们要求我们所有人考虑“复杂性”而不是“努力”。我们真的很困惑，我们在浪费时间开会。一位开发人员提出了一个问题：“我们真正要考虑什么？是关于我们在此需求（时间估计）中必须进行的代码/ DDL更改，还是关于我们是否已理解该需求？

但是，他们（业务分析师和项目负责人）真正的含义是“了解需求”并“举起名片”？

另外，我们为各个Scrum团队举行切片会议，每个开发人员都为每个Scrum团队估计完成给定任务的时间。那么，他们在计划扑克中真正谈论的是什么呢？

谁能用一个例子解释一下？当他们说“复杂性”和“努力”时，尝试区分他们真正在谈论什么。

考虑项目经理的观点

通过要求复杂性，他们想要一个可以与您的下一个冲刺进行比较的数字，以找到团队的速度。他们可能还试图使用它来将您的结果与其他团队的估算值相加，以提供有关何时完成所有故事的总体估算值。

项目经理正在寻找项目何时完成的估计，或者如果它们在时间函数成本三角形的其他侧面上都很灵活，那么可以动用其他离职人员以使其适应剩余时间。这不是不合理的。需要基于此估计来做出业务决策。问题在于，很难为软件估算出这一点。规划扑克是解决此问题的方法之一。与其将故事视为简单地将故事点数相加，不如将其看作是尽可能估算，执行工作，测量花费时间，迭代然后推断的更复杂的功能。

讨论比数字更重要

我发现讲故事会议最重要的部分是即将进行的讨论。如果团队中的任何人都不敢建议一个数字，那么他们可能无法完全理解故事，因此需要进行更多讨论。摘自《敏捷宣言》，“客户通过合同协商进行协作”。与其仅仅指定一个作为用户故事写的合同，并说团队如果没有按照您的意愿去做而失败，不如说客户真正想要什么，直到您理解它总是更好。

复杂性与努力

为了解决您关于复杂性与工作量的特定问题，每个人似乎对此都有不同的看法。Mountain Goat是制作计划扑克牌的人，他们背面有山羊，而老板Mike Cohn在敏捷/ Scrum世界中很重要。他们说这应该是努力的，而不是复杂的。

通常不认为这是时间的度量标准（请参见下面的示例作为反例），因为人们在估计时间上很糟糕，其他因素也会影响他们给出的数字：例如，保持数字较低以适应更多功能的压力如果遇到问题，请给更大的压力，给自己一些空间。构建软件很难。当您建造第100座房屋时，您可以估计需要多长时间，因为您在那之前建造了99座房屋。如果您要构建的软件与以前构建的程序相同，那么您可以复制和粘贴，尽管软件项目的价值不尽相同，所以会遇到您在一开始没有预见到的问题。

与包含隐藏压力的时间估计一样，衡量工作量也存在问题。如果初级开发人员估计其复杂性很高，他们可能会觉得自己很容易受到攻击，因为他们对其他方面的评估不够好，而其他人对此却给出较低的估计。这不仅不利于您的估计，而且不利于团队中的人员。

计划扑克号码不是“天数”或其他时间量度，它们是能够比较两个用户故事的相对量度。在新团队中需要做的第一件事是建立基线。选择一个位于复杂性范围中间的用户故事，并以团队的方式在您要为其分配范围的中间确定一个数字。现在，所有其他用户故事都可以相对于此故事进行编号。我发现这使它变得容易得多。

您无法估算的原因

当项目经理询问您何时完成项目时，他们需要了解他们所提出问题的复杂性。程序员不是工厂工人，他们的生产率可以通过打字速度和工作时间相乘来衡量。他们正在寻找问题的答案，这很难。通过玩计划扑克，您首先要确定团队中谁觉得他们无法回答分配哪个号码的问题，然后深入研究为什么他们不能回答该问题。我认为至少有四个原因：

1. 这个故事太大了。将其分解为更小，更具体的用户故事。记住，每个用户故事都应该为用户提供一个价值；输入-处理-输出=值。
2. 他们对问题域的理解不够深刻，无法说出要花多长时间甚至正确地提出所有问题。与那些对利益相关者域/编程此类应用程序了解更多的人进行交谈，无论您以前从未见过这种应用程序。如果这是不可能的，或者不能完全解决问题，那么您可以使用设计钉。你去实现原型解决方案，但仅适用于有限的和指定的时间量。定义原型制作阶段将持续多长时间，而不是太长，然后再次开会以分享您的新知识。
3. 您的利益相关者不够具体。“为我建云”不是一个可以接受的用户故事。“将我构建为可以按需启动VM的系统”会更好，因为它会进一步细分，但仍无法准确估计需要多长时间，因为隐藏了一百个该声明中您的利益相关者所拥有的假设，除非您向他们展示一些东西，否则您将不会发现。
4. 最后，即使您可以给出估计，第一次可能也会出错。估算是一个难题，而我所知道的解决难题的最好方法是使用科学方法。收集有关每个团队成员估计的数字的数据，然后收集有关其实际花费了多长时间或确实“复杂”的数据（尽管这比较困难），然后随时间进行比较。最终，您会感觉到谁被高估了，谁被低估了，然后您应该与团队分享这一点。人们可以互相帮助，从而更好地进行估算。这些数字也可以反馈到您的跟踪工具中，以帮助更好地预测故事需要多长时间。

结论

我认为重点应该在讨论上，但是如果您确实需要给某人一个数字，那么就尝试使其成为一个独立于哪个团队成员进行工作以及按什么顺序进行故事的工作即可。关键是要获得既有优先顺序又要优先处理的后备日志，以便按正确的顺序对其进行处理，并确定其大小，以便项目经理可以在截止日期之前大致了解可以容纳的数量。您应该能够在任何迭代结束时停止并附带已启动的所有已完成功能。

警告

您可以估计完成任务的时间，只要您自己掌握数字即可。一旦您允许任何数字逃离团队并被其他人看到，他们就会以您不希望的数字进行操作。他们将尝试使用它几天来完成任务。他们将尝试使您保持相对复杂度等级，并询问为什么完成一个用户案例要比花费相同分数的用户案例花费更长的时间。他们会将您的数字加在一起，然后将其与其他团队的数字进行比较，并询问您为什么另一个团队在一段时间内完成更多故事点后会“做更多的工作”。您可以'

在旁边

计划扑克数字组通常分布为使得数字之间的差距越来越大。我相信这是为了阻止人们争论用户故事是16还是17，如果大于13，则将其设为20。

例

我知道至少有一个团队仅使用数字1、2、3和4来规划扑克。按照惯例，与上述讨论相反，它们将这些天定义为编程天（实际上是成对编程天，也就是说，两个程序员在同一台机器上一起工作才能完成用户故事需要多少天）。如果团队认为需要花费4天以上的时间来完成用户故事，那么就没有故事要指出了，则要求产品负责人与团队合作以进一步分解故事或更准确地指定故事，以便可以被带到这个范围内以供将来的计划会议。但这是高级敏捷，可能只应由已经使用其他技术的经验丰富的人使用。

我认为弗兰克（Frank）和恩卡塔（Encaita）的答案几乎涵盖了这一点，但还需要考虑其他一些事项：

为什么要使用故事点

评估故事点的目的是为您的应用程序开发功能提供相对的复杂性。一种简单的思考方式是在即将进行的sprint中获取一个故事，例如url更改。您知道这在复杂性方面很简单，并且已经明确定义了接受标准，因此整个团队都同意，即使进行测试，它也是1（使用Fibo量表）。

下一个要估计的故事是聚合一组用户数据并将其可视化在前端。现在，作为开发人员，您立即知道，这比更改URL更复杂。您讨论了故事和验收标准，并且遇到了很多问题，并且看到了一些可行的解决方案。其他开发人员和质量检查人员也认为这很复杂。所以大家都同意这是一个34点的故事。值得注意的是，Fibo量表还允许您表明您对模拟的信心程度-数字之间的差异越大，表明您对估计的信心就越小

此时，您的Scrum管理员应该跳起来，说这是一个单一的故事，太大了，需要分解成更简单，更简单的故事。您可以通过执行所谓的SPIKES来解决此问题-这只是预留时间来调查某些事情。因此，对于本示例，您和其他开发人员都同意，您需要4个小时来讨论和研究可能的技术解决方案。

简而言之，您可以将这个大故事分解为另外四个分别为5、8、8和13分的故事。不记得这些估计都是关于相对复杂性的-他们不必将原始估计加起来，而且您现在拥有更多信息可以做出更准确的估计。

然后，您会以团队的方式同意，对于本次冲刺，您将致力于完成13点故事，一个8点故事以及您已经确定的1点网址更改。这样一共22分。在下一个Sprint中，您将获得27分，在接下来的Sprint中，您将获得18分。经过3个冲刺，您就可以开始对自己的速度有所信心（速度是您的团队可以在一个冲刺中完成的工作量）。要获得速度，请取先前冲刺的平均值。因此，在此示例中，平均值为（22 + 27 + 18）/ 3 = 22.3，因此将其四舍五入到Fibo标度的最接近值21。

现在，对于下一个冲刺，目标是完成21分。

不要为获得正确的故事点估计而烦恼-这不是一门精确的科学。您知道url更改要比汇总数据复杂得多，因此只需对它进行评分即可。

另外，以团队形式讨论这些事情是件好事。在冲刺审阅期间回顾一下您的估计，并讨论您是否对它们感到满意，然后将其输入到下一个冲刺计划会议中。

整个团队的估算

整个团队必须就每个故事达成一致的估计。一项功能要等到正式生产后才能完成。仅仅编写代码是绝不可能完成的。以我的经验，Scrum团队在团队合作中效率更高。以我现在与之合作的团队为例。当我加入时，他们参加所有的sprint会议并计划扑克，但是在sprint期间，过程是1. BA /产品所有者将需求定义为具有接受标准和接受测试的故事2.他们将这些需求交给开发人员，然后由开发人员编写代码3.开发人员将代码合并到开发分支中，以进行质量检查以进行测试4.对质量检查进行测试，然后他们开始提出问题，并且测试失败，因此重新投入开发。

这里缺少什么？前面没有足够的讨论，每个团队成员都只看到自己的任务。现在，BA / PO，开发人员和QA聚在一起，然后编写任何代码以详细讨论需求并预先提出问题，然后在整个sprint中继续进行讨论。这样效率更高，并能带来质量更高的解决方案。

计划扑克对这一过程有帮助，因为它迫使团队讨论该功能，并作为一个团队就该功能的交付复杂程度达成一致。在传统的软件开发中，项目经理负责项目的交付，但是任何有这种方法经验的人都知道它是行不通的，因为在很多情况下，人们不承担应用程序交付中的责任。在Agile中，您不需要项目经理，因为团队将整体负责交付应用程序。

按时估计任务

我认为与估计任务时间的团队以及仅做故事要点的团队合作是“不做时间估计”！他们实际上只是浪费时间。它们不像故事点那样准确，因为它们特定于个人而不是团队，并且每个人都会有不同的时间估算观念（如火如荼）。

故事情节接受事物（即需求）并一直在变化，因此您确实需要一个指标来说明团队可以在冲刺中完成什么。

一旦了解了速度，就可以及时测量可交付成果，因为您知道在每个冲刺中可以完成的工作，例如，每两周就知道可以交付哪些功能。您的Scrum负责人和产品所有者应该进行估算会议，以期展望未来的冲刺，然后您就可以了解未来几个月将完成的工作量。这样，产品所有者就可以在最终应用程序中包括哪些功能做出优先级决定。

我曾经让开发人员要求我们估计任务的时间以进行计划，但是我实际上不同意这种方法（实际上，我强烈不同意这种方法），因为它不准确，例如，这将花费我4个小时才真正意味着：一个开发人员可能只在任务本身上花时间，其他人则可能会花一些时间来做杯茶！

时间估算总是交给其他人报告，这也过分强调了提供功能的各个要素而不是整个团队的努力。

估计不是最大的问题

顺便说一句，弄清楚估计并不是我认为团队必须解决的最大问题。最重要的是，作为一个团队一起工作，以在整个sprint中完成任务，这样您就不必在最后一天交出所有内容进行测试。您希望在整个2周的冲刺中看到稳定的功能。我上面解释的团队动态是其中很大一部分。故事点估计将帮助您对此进行计划，因为您将看到哪些大故事需要分解为较小的故事，并可以定期进行测试。

维基百科很好地解释了如何规划扑克。让我重述一下您的情况：

为什么要计划扑克？

首先，大家都应该了解为什么要进行计划扑克而不是“正常”的估算。原因其实很简单：我们都吸大的时候，当谈到估计时间的任务。几乎每项研究都表明，人脑根本无法估计需要花费任何合理时间的任务。（这也是一个原因，为什么超出估计值2-3天的票证就其估计值而言几乎一文不值。）

为什么要复杂而不是努力？

这与上面的内容并驾齐驱。努力通常意味着时间，我们为此感到厌倦。相反，复杂度很难客观地量化，在这种情况下，这是一件好事。是您的直觉告诉您这个故事会变得很复杂。对于其他人来说，它可能不那么复杂。但是您不必确切地量化它到底有多复杂。您无需X花费如此多的复杂性-而不是费时的工作，最终您必须同意它花费X数天左右的时间。

为什么要隐藏卡？

具有您的复杂性的卡牌会被隐藏起来，然后立即全部显示出来。这样做是为了确保您在进行自己的初始估算之前不会受到他人意见的影响。如果每个人在复杂性方面都具有相同的直觉，那么您就完成了。如果出现了截然不同的数字，那么您知道那里隐藏着一些要讨论的东西。这样，您可以非常快速地处理每个人都对所需的复杂性/工作量有相同想法的故事。

为什么使用斐波那契数？

卡上的数字通常是斐波那契数字或某些其他类型的序列，这些序列中的缺口很大。这是为了让您完全相信自己的直觉。如果您必须在8到13之间进行选择，那要比选择9或10要声明的多得多。而且，如上所述，巨大的差异是隐藏问题所在的位置，因此，通过扩大差距，您就有更多机会选择更好地发现这些问题。

为什么这完全起作用？

有趣的是，前几次您做计划扑克都行不通。就这么简单。“ 3”或“ 5”甚至意味着什么？每个数字的含义（故意！）没有定义，这取决于整个团队来发现每个数字背后的实际含义。只有当您接受了以这些数字估算故事的机会之后，并且已经意识到其中的几个故事，您才可以更好地了解何时应该提高5以及何时提高8。

一旦将其与速度概念结合起来并通过这些故事点来衡量冲刺进度，您便拥有了一个全新的效率等级，该等级或多或少地独立于传统的时间估计。

不过，对我个人而言，计划扑克最有益的一点是，通过使用斐波那契数而不是时间估计，您可以更轻松地检测不确定性。使用经典的时间估算，您不会被迫做出这样的“极端”（由于数字鸿沟）的决定，因此，估算可能相距甚远，团队可能会错误地认为他们对故事的理解足够好。

例

通常发生的一个简单示例是，讲述一个故事，然后人A提出异议。这是“请不要忘记此功能会影响X，这可能意味着它比我们目前所认为的要昂贵得多”。主要问题是桌子上总是有这个人A。总是有人担心。如果您进行公开的前期讨论，那么您根本不知道X到底有多大的担忧。

如果您根据时间进行隐藏的估算，则效果会更好一些。但是，仍然可以有效反对一个人A的估计值。另一方面，通过计划扑克，人A必须更多地考虑实际问题X的多少。对于两个不同的问题，您无法通过上述“反对意见的文字”正确区分它们的重要性。即使有时间估计，也很难看出哪一个问题更大。这里使用规划扑克的希望是，你最终有一个异议是从别人的估计只有2-3点不同，但最终5个或8点远离中间其他异议可能只是在最重要的不确定因素您的Sprint计划。

在我的团队经过数十次迭代之后，我们发现故事的重点主要是关于中期项目指导。它们使产品所有者可以提前计划自己的2或3个冲刺，并根据平均速度从本质上做出有关发布的业务和范围决策。

我们发现故事点在sprint级别上没有太大用处，因为没有两个sprint相似，并且预测将要完成的工作量是不可能的。因此，我们决定不应该沉迷于估算部分，而只是将计划扑克会议作为有关功能对话的借口。

这与Mike Cohn 在这里提出的观点是一致的。

附带说明，对于给定的团队来说确实如此，但是关于故事要点将如何帮助您没有任何规则。我建议您首先坚持使用该方法，但是尝试自己快速找出它们是否有用以及如何发挥作用。回顾将帮助您对此进行反思。

这里的根本问题是它已损坏。PM希望使用计划扑克来了解每个故事的复杂性，以期大致了解一个冲刺中可以容纳多少个故事（团队的速度）。

结果，它的“不是基于时间”即“基于时间”。难怪每个人都会感到困惑。

有多种方法可以帮助您。首先，不要去努力，而要关注复杂性。忘记所有发展和专注于每个故事所影响领域的时间。如果您有一个更新数据库，服务器代码，客户端代码和客户端文档的故事，那么您可以说这是一个4点故事。如果仅是对DB sql的更改，则其为1点故事。这使您可以更轻松地了解故事之间的相对复杂性。（您必须提出一些适合您情况的指标，例如测试覆盖率要求或UI复杂性）

我的看法通常是，它毫无意义地浪费时间，只是在鼓励进行Sprint计划，就好像它们是小型瀑布项目一样。谁真正在乎您可以在冲刺中容纳多少故事点？如果在冲刺结束时有遗留的故事，则只需在下一个故事中进行处理即可。鉴于此，您不妨将您的待办事项积压成拥有的每个出色故事的大小，然后逐渐减少它们的数量。交付所需的时间长（但是如果您不浪费20％的时间在积压和冲刺计划会议中，这样做会更快）。在项目结束时，没有人关心交付了多少故事点。人们关心的是已交付的项目。

此外，用户故事指向还可以使企业提前了解是否需要重新谈判。如果您有一个月的时间完成某些工作，而您获得100分，则可能会遇到麻烦。它还使您有机会将史诗般的故事分解为更有价值的小故事，并且可以在冲刺中完成。