scrum估算扑克
Planning Poker is an estimation technique which helps developers provide good estimates for project tasks. It comes from the world of Agile software development, but can be used in isolation or with other methodologies as well.
规划扑克是一种估算技术，可帮助开发人员为项目任务提供良好的估算。 它来自敏捷软件开发领域，但也可以单独使用或与其他方法一起使用。
When you use Planning Poker to estimate your project, it is very important to give each developer a voice; allow them to make their own estimates without being influenced by the opinions or agendas of anyone else. When this is the case, Planning Poker enables you to do two very valuable things:
当您使用Planning Poker评估您的项目时，给每个开发人员一个声音是非常重要的。 允许他们自己进行估算，而不受其他任何人的意见或议程的影响。 在这种情况下，Planning Poker使您能够做两件非常有价值的事情：
You can look at the various estimates for the same task and gain a clear sense of how long this task will take. Since developers tend to under- or over-estimate, you may need to adjust this number. 您可以查看同一任务的各种估算值，并清楚地了解此任务将花费多长时间。 由于开发人员倾向于低估或高估，您可能需要调整此数字。 It becomes possible to spot tasks where the developers’ estimates differ wildly from one another. When this happens it means the task is not well defined. The unknown elements cause different developers to make different assumptions; the task needs to be amended until everyone is able to estimate. 可以发现开发人员的估计彼此之间截然不同的任务。 发生这种情况意味着任务定义不明确。 未知的因素导致不同的开发人员做出不同的假设。 在每个人都可以估计之前，该任务需要进行修改。In this article I’ll show you how using Planning Poker with a team can help you make better estimates for the projects you work on.
在本文中，我将向您展示与团队一起使用Planning Poker可以如何帮助您更好地估算所从事的项目。
First of all you will need:
首先，您需要：
some players (two minimum, three is awesome, and it works with up to five or so) 一些玩家(最少两个，三个很棒，最多可以有五个左右) a chairperson or facilitator 主席或主持人 some Planning Poker cards 一些规划扑克牌 a list of tasks you want to estimates for 您要估算的任务列表You can purchase special Planning Poker cards (I have a rather nice set from moo.com), make them from index cards, or improvise with an iPhone or Android card app.
您可以购买特殊的Planning Poker卡(我在moo.com上有一套不错的卡)，可以从索引卡上制作，也可以即兴使用iPhone或Android卡应用。
The exact selection may differ, but typically you’ll have cards with the values 1/2, 1, 2, 3, 5, 8, 20, and a question mark or unknown value. These are measurements for a task in story points (story points are an imaginary unit, where the simplest task is half a story point, and the bigger the task the more points it is worth). Each person is dealt one of each value. Different teams play with different variations, for example it is fine to treat them as hours spent coding to get started.
确切的选择可能会有所不同，但是通常您会得到的值是1 / 2、1、2、3、5、8、20的卡片，以及问号或未知值。 这些是以故事点为单位的任务的度量(故事点是一个虚构的单位，其中最简单的任务是故事点的一半，而任务越大，价值就越多)。 每个人被赋予每个价值之一。 不同的团队使用不同的变体，例如，可以将它们视为花在编写代码上的时间作为入门。
The facilitator describes the task to be estimated and everyone selects, but does not show, the card that represents their chosen estimate. On a given signal, everyone reveals their card at the same time. If the numbers are all the same or similar, then accept that (or average them) as the estimate and move on to the next task.
主持人描述要估计的任务，每个人都选择但不显示代表他们选择的估计的卡片。 在给定的信号下，每个人都同时显示他们的卡。 如果数字都相同或相似，则接受该数字(或取其平均值)作为估计值，然后继续进行下一个任务。
If the numbers differ wildly, then something is amiss with the task or people have made different assumptions about it. For example, one person might think that to show a list of products she would also need to include the search and sort features for the list page; someone else might not have factored that in to his estimate. When this happens, the high estimator and the low estimator are asked to justify their estimates. It is very important that even if it’s the most junior member of the team who made the non-matching estimate that he should have his soapbox to justify things. The point of the exercise is to give everyone a voice, so pulling rank is not allowed! Figure out if the task or user story needs to be broken down or a better description, or if one of the players has misunderstood something. Re-estimate if you need to, and then move on.
如果数字差异很大，则说明该任务存在问题或人们对此做出了不同的假设。 例如，一个人可能认为要显示产品列表，她还需要包括列表页面的搜索和排序功能。 可能没有其他人将其纳入他的估计。 当这种情况发生时，要求高估计量和低估计量证明其估计值是正确的。 非常重要的是，即使是团队中最年轻的成员做出了不匹配的估计，他也应该拥有自己的肥皂盒来证明事情的合理性。 练习的重点是让每个人都有声音，因此禁止拉高等级！ 确定是否需要分解任务或用户故事或进行更好的描述，或者其中一个玩家是否误解了。 重新估计是否需要，然后继续。
The process is repeated, with the agreed estimate numbers being recorded by the facilitator, until all the tasks have been estimated.
重复该过程，并由协调员记录商定的估算数量，直到估算出所有任务为止。
It’s often the case that tasks get more difficult to estimate as they get larger, and there should certainly be an upper limit for estimates. Personally, I recommend anything more than a day long is too big and should be split into smaller tasks. This approach fits in well with the daily stand-up style meetings where everyone is asked what they’ve done and what they’ll be working on next.
通常情况下，任务越大，任务就越难以估计，并且肯定应该有一个估计上限。 就个人而言，我建议任何一天以上的事情都太大，应该分解成较小的任务。 这种方法非常适合日常站立式会议，在这种会议中，每个人都被问到他们做了什么以及接下来将要做什么。
Be militant about not allowing any discussion except over a specific estimate mismatch. And even then, don’t let people get sidetracked. It is very important to keep the meeting from dragging on. Some things can’t be estimated for; if you talk about any one point for more than three minutes, forget it and move on. It is not a spec-writing exercise; that should have been done already. That feature will have to be better described or more investigation needed before an estimate can be made and you don’t want to waste meeting time (you have at least four members of your team in the room and that’s a lot of resource to be burning!) when one person could sort it out later.
好战的是除了特定的估计不匹配外，不允许进行任何讨论。 即使那样，也不要让人们陷入困境。 防止会议继续进行非常重要。 有些事情无法估算； 如果您谈论任何一点超过三分钟，请忘记并继续前进。 这不是规范编写工作； 那应该已经完成了。 在做出估算之前，必须对该功能进行更好的描述或进行更多的调查，而您又不想浪费会议时间(会议室中至少有四名团队成员，这需要消耗大量资源！)，当一个人可以稍后对其进行整理时。
Either limit the meeting time to an agreed length, or run a humane format. It’s common to let the meeting run for 50 minutes, then break for 10 so people can visit the bathroom, get a drink, take a phone call or whatever they need to do. You can then restart and run the meeting for another 50 minutes, and so on, until it is done. If it’s lunchtime, make sure you either have a longer break or order in food. For a 2-week sprint, the meeting should not run for more than 2-3 hours as a rule of thumb.
将会议时间限制为约定的长度，或者采用人性化的格式。 通常让会议运行50分钟，然后休息10分钟，这样人们就可以去洗手间，喝一杯，打个电话或做任何需要做的事情。 然后，您可以重新启动会议并再运行50分钟，依此类推，直到完成。 如果是午餐时间，请确保您有较长的休息时间或订购食物。 对于2周的冲刺，根据经验，会议的召开时间不得超过2-3小时。
Planning Poker is just one tool in the box but I find that using it enables getting the best out of the “hive mind” within a limited timescale. Once you have decent estimates, you can plan your project more accurately.
计划扑克只是包装盒中的一种工具，但我发现使用它可以在有限的时间内充分发挥“蜂巢”的作用。 获得合理的估算后，您可以更准确地计划项目。
Don’t be alarmed if the estimations are significantly bigger than you would usually expect from a project of similar size! My experience is that the overrun is much smaller when you use a detailed, distributed estimation approach like Planning Poker, so your project will deliver in approximately the same time as normal but you’ll have a much clearer idea of what that timescale is.
如果估算值比同等规模的项目通常所期望的要大得多，请不要惊慌！ 我的经验是，当您使用诸如计划扑克之类的详细的分布式估算方法时，超支的情况要小得多，因此您的项目将在大约正常的时间交付，但是您会更清楚地知道该时间表是多少。
If you already use this technique, or have adopted it now after you’ve read this article, I’d be interested to hear what you think of it and whether you changed the process above in any way. Leave a comment, please :)
如果您已经使用了这种技术，或者在阅读本文后立即采用了这种技术，那么我很想听听您对它的看法以及您是否以任何方式更改了上述过程。 发表评论，请:)
Image via Charles Taylor / Shutterstock
图片来自Charles Taylor / Shutterstock
翻译自: https://www.sitepoint.com/planning-poker/
scrum估算扑克
相关资源：Scrum评估故事点方法-计划扑克