计划POKER或SCRUM POKER你需要知道的一切
嗨，本周我将讨论Planning Poker或Scrum Poker; 使用基于共识的估算的策略。来自世界各地的敏捷团队使用计划扑克技术来估计他们的产品积压。Scrum Poker可用于故事点 (Story Point)，理想日期或任何其他估算单位。
计划扑克中的Scrum带来了一个项目的敏捷估计多专家意见一起。这种敏捷计划包括每个人：程序员，测试人员，数据库工程师，分析师，用户交互设计人员以及项目中涉及的所有其他人员。由于这些团队成员代表软件项目的所有学科，因此它们最适合于估算任务。
扑克策划如何运作
一个扑克规划，或争球扑克会话涉及 产品的业主或客户和编辑。会议开始于每个估算员按顺序持有一副基于价值的卡片。我们建议使用以下内容：0,1,2,3,5,8,13,20,40和100.这些值表示团队估计的故事点数，理想天数或其他单位。
该产品所有者或顾客要么读一个敏捷的用户故事或描述特征的估计。
估算人员会讨论该功能，并在需要时询问 产品所有者的问题。当估算人员完成讨论后，他们每人都会私下选择一张卡来代表他或她的估计。然后同时显示卡片。
如果估算器选择相同的值，则该数字成为估计值。如果他们的价值不同，估计者会讨论他们的理性。那些选择最高或最低值的人应该在每个估算师选择另一张估算卡之前与该小组分享他们的推理，重复这个过程。
估算人员继续进行扑克规划流程，直到达成价值共识。如果他们不同意，估算人员可以选择推迟敏捷估算和计划特定项目，等待附加信息。
什么时候我们应该参与规划扑克（或Scrum扑克）
在编写初始产品积压后不久，大多数团队将举行扑克策划会议。这些会话可能需要几天时间，用于创建初始估计值，这些估计值可用于确定项目的范围或大小。
由于产品积压项目（通常以用户故事形式）将继续在整个项目中添加，因此大多数团队发现每次迭代进行一次后续敏捷估算和计划会话非常有用。
它们通常在迭代结束前几天举行，并且在每日站立之后立即举行，因为整个团队仍然在一起。
在Scrum中规划扑克的技巧
以下提示可帮助团队应对Scrum扑克规划中的常见挑战 ：
让讨论富有成效： 两分钟的计时器是一个有用的工具，用于教会团队如何更快地进行估算。要使用计时器，当组中的某人开始一轮时，将设置计时器。当沙子耗尽时，将播放下一轮规划扑克牌。
分成较小的会话： 尽可能将理想的大型团队分成更小的子团队是理想的。当有许多故事要估计时，这是运行会话的好选择; 通常发生在新项目的开始。
何时上场： 通常情况下，估计团队需要在两个不同的场合进行计划扑克：在项目开始之前的第一次迭代期间以及在正在进行的迭代期间识别新故事时。
规划扑克很棒的三大理由
- 它通过吸引整个团队来促进协作。
- 它使用共识估计而不是单人估计。
- 通过讨论每个用户故事，它会在项目早期暴露问题。
在扑克策划会议期间观看成功的团队将清楚地展示列出的三个主要原因。扑克策划是一个很好的工具，有许多好处，但还有其他方法可以帮助改善这个过程。
大多数人都会错过的小步骤可以用来改善这个过程。了解这些提示将使成功的教练或值得信赖的团队成员能够帮助他们的团队改进。那些智慧的金块是什么？
那些做这项工作的人应该投票。
敏捷团队经常投票，无论他们在项目中的角色如何。只有积极参与故事的人才应该投票。
经理不投票
管理人员通常希望工作花费更少的时间，因此他们通常投票率很低。但是，他们比普通团队成员有更多的经验。通过赋予经理在一个特定情况下对团队共识的否决权，他们可以要求团队考虑可能增加规模的事情。
永远不要让管理者给出低规模或说服团队缩小规模，因为他们的意见过重。经理的观点将充当锚点，并在他们积极捍卫自己的位置时拖下尺寸。
如果连续两种尺寸的投票中存在平局，则选择较大的尺寸并继续前进。
如果使用Fibonacci序列进行大小调整（1,2,3,5,8,13），则连续大小可能为5和8。平均分割通常需要很长时间才能解决，因此，使用较高的数字。根据我的经验，没有人同意中间数字，通常在讨论结束时选择最大尺寸。使用这些事实是有利的并且将加速该过程。
在实施讨论太深之前停止实施讨论。
在讨论用户故事时，团队通常会非常熟悉细节。虽然这在一定程度上是好的，但应该严格限制。讨论不应该花太长时间。参与尺寸测量的人员应该已经有了最简单，合理的解决方案的想法，并根据该场景选择尺寸。
虽然许多人认为更多的讨论会使尺寸更准确，但事实并非如此。这部分是为了鼓励团队做出最好的猜测并继续前进。但是，明显缺乏精确度，因此规模不是精细的。
使用“我需要休息”卡
团队经常参与他们的扑克计划会议，当一些团队成员需要休息时他们没有意识到。团队中的某个人可以使用“我需要休息”卡片来吸引所有人注意休息的需要。
使用某种计时器来限制讨论
使用计时器限制讨论是不言自明的。讨论应限制在不超过一分钟。
如果在第三轮投票结束时无法达成共识，请选择最大规模并继续前进
经过两轮讨论，进一步的尝试不会产生更大的结果和浪费时间。通过选择最大的尺寸，团队有改进的空间，并且不会有任何耗尽时间的危险。团队试图避免的最大问题是时间不多了，所以这个快捷方式应该可以解决这个问题。
在玩规划扑克之前，创建用户故事的人是否与QA和开发主管会面
用户故事应该准备好最明显的问题的答案。准备好答案后，团队可以专注于规模，而不是收集信息。
记住基线
无论团队选择什么作为基线，它都需要从迭代到迭代保持一致。如果理想的一天是第一个，那么所有迭代都需要使用该参考点。如果用户故事的大小为一或三，则需要在迭代期间保持一致。
有时，重新解决基线并与团队讨论他们认为尺寸确实是什么是有帮助的。如果不这样做，最终可能会导致“规模爬行”这个术语，当团队随着时间的推移在心理上改变他们的基线时，他们会使用更大或更小的基线。这通常发生在团队无法满足他们对多次迭代的承诺时，即使所有内容看起来都差不多。
玩得开心！
玩规划扑克应该是一个有趣的协作练习。太多的团队试图将它磨掉一两个小时而忘记享受他们的工作。有很多方法可以注入乐趣。我喜欢玩大小真正的扑克来增加乐趣。
要玩，每个大小的故事都算作一张扑克牌，每五个故事就是扑克牌。在开始之前，每个人都试图选择哪一只手是最好的。这鼓励团队提前查看用户故事，然后尝试猜测哪个集合将成为直接或四个类型。获奖者甚至可以获得小奖。