如何进行计划扑克（分步指南）

计划扑克是一种基于共识的估算技巧：每位团队成员私下为某项任务的工作量选择一张卡牌，所有人同时揭晓，团队就任何分歧展开讨论，直至收敛到一个共同的估算结果。在敏捷估算研究中，它是应用最广泛的专家判断技巧。要进行计划扑克，你需要一支团队、一组待估算的条目，以及一套估算卡组，然后按照下面的七个步骤进行。

什么是计划扑克？

计划扑克（也称为 scrum poker 或 pointing poker）把估算变成了一场简短而结构化的游戏。它不再由声音最大或最资深的人来定调，而是让每个人私下给出自己的估算，并同时揭晓。正是"同时揭晓"这一条规则，让这项技巧真正发挥作用。

为什么有效：团队共同估算的科学依据

计划扑克之所以要求同时揭晓，是为了避免锚定效应（anchoring）——这是一种有充分文献记录的认知偏差，指最先被提及的数字会把其他所有人的估算都拉向它。在受控实验中，仅仅是在软件从业者估算之前向他们展示一个随意的数字，就会强烈地把他们的估算拉向那个数字。这种效应相当显著，即便是专门设计用来抵消它的培训工作坊，也只是削弱了这种拉力，而没有将其完全消除。长期以来，锚定效应一直被认为是软件估算结果偏低的重要原因之一。

以团队形式进行估算同样有帮助。在一项将计划扑克应用于真实项目任务的研究中，团队经过讨论后达成一致的估算，比直接对每个人的个人猜测取平均值要更不乐观，也更接近实际的工作量。（完整参考文献见下文。）

开始之前你需要准备什么

• 一支由实际执行工作的人员组成的团队（通常为 3 到 9 人）。
• 一份已排好优先级、待估算的用户故事或任务清单。
• 一套估算卡组（见第 2 步）。
• 一位主持人（通常是 Scrum Master），以及一位能够解答每个条目相关问题的人（通常是 Product Owner）。

如何进行计划扑克：7 个步骤

1. 搭建房间并邀请团队。 创建一个会话并分享链接。使用 Planning Poker Web 这款免费的计划扑克工具，任何人都可以无需账号即可加入：只需打开链接即可进入。主持小贴士：在开始之前，先就卡组和一个参照故事达成一致（例如"这个小 bug = 2 分"），这样所有人都能按照同一套量表进行校准。
2. 选择一套估算卡组。 确定团队投票时使用的量表（斐波那契数列、T 恤尺码等等）。小贴士：在各个 sprint 之间保持使用同一套卡组，这样你的速率（velocity）才能保持可比性。
3. 展示第一条用户故事。 Product Owner 朗读该条目并回答澄清性问题，介绍过程应尽量简短，因为细节会在后续讨论中逐渐浮现。时间限制：展示约 2 分钟。
4. 所有人同时投票。 每个人私下选择一张与自己对工作量判断相符的卡牌，此时还不能说出任何数字。小贴士：把所有参与实际工作的人都纳入进来，包括测试人员和设计师，而不仅仅是开发人员。
5. 一起揭晓。 当所有人都完成投票后，同时揭晓。这是防止锚定效应的关键一步：每个人的投票都不会受到他人的影响。
6. 讨论异常值。 如果估算结果出现分歧，投出最高分和最低分的人分别解释他们的理由，这往往能揭示出隐藏的假设、遗漏的任务和潜在风险，常常是整场会议中最有价值的部分。时间限制：约 3 到 5 分钟，如果超时，说明这条故事可能太大了。
7. 重新投票，直至达成一致。 讨论之后再次投票，重复这一过程，直到团队确定一个共同的数字，记录下来后转到下一个条目。小贴士："达成一致"指的是足够接近、可以认可，而不是完全相同，因此不必追求一张完全一致的卡牌。

实例演练：估算一条用户故事

假设这条故事是"用户可以通过邮箱重置密码"。Product Owner 朗读了它，一位测试人员询问限流（rate-limiting）是否在范围之内（答案是肯定的）。团队使用斐波那契卡组投票并揭晓：

这位测试人员（投出 8 分）解释道：密码重置流程需要限流、邮件模板相关工作，以及过期令牌的边界情况处理，这些都是其他人没有想到的。这正是计划扑克旨在揭示的隐藏工作。经过讨论后，团队重新投票（5、5、8、5），并一致同意为 5。相比最终的数字，更重要的是整个团队现在对这项工作已经有了相同的认知。

远程 vs. 面对面进行计划扑克

基本机制是相同的，不同的是主持方式。

• 面对面： 实体卡牌可以正常使用，但需要有人手动记录结果，也没有自动生成的历史记录。要留意那些揭晓较慢、可能影响他人的情况。
• 远程或分布式团队： 共享的在线房间必不可少。揭晓环节由工具强制执行（没有人能提前看到投票），结果和历史记录会自动保存，异步投票还能让跨时区的团队无需实时通话也能完成估算。这正是 Planning Poker Web 这类工具能够完全取代实体卡组的地方。关于实时和异步的具体设置，参见我们的远程团队计划扑克指南。

什么时候不应该使用计划扑克

计划扑克并不总是合适的工具。在以下情况下，可以跳过它，或选择更快的方法：

• backlog 规模巨大（50 个以上条目）。 逐项投票太慢了，可以先用亲和估算法或桶分法完成第一轮，然后只对不确定的条目使用计划扑克。
• 某项工作明显由一个人负责。 在缺乏多元视角的情况下，团队仪式相比快速的专家估算带来的价值有限。
• 团队已经拥有清晰一致的认知模型。 对于已被充分理解、重复性强的工作，估算结果很少出现分歧，讨论也就揭示不出太多信息。
• 你是在为一个长期路线图而不是一个 sprint 做估算。 粗略的估算（例如 T 恤尺码）就已足够，在那么长远的时间跨度上，精确的相对点数只是在浪费精力。

对此保持诚实有助于建立信任。把计划扑克强加在不合适的场景中，正是团队开始厌烦估算这件事的原因。

棘手场景（以及应对方法）

• 团队经过两轮投票仍无法达成一致。 这条故事通常是太大或太模糊了，应将其拆分，或退回给 Product Owner 进一步澄清。
• 某个人主导了讨论。 私密投票本身已经限制了这种情况，可以进一步强化：让投出最低分的人先发言，而不是最资深的人。
• 有人总是随大流投票。 可以要求他们在"观察场上气氛"之前先投票。在工具中，投票结果在揭晓前都是隐藏的，这就消除了随大流的诱惑。
• 估算结果持续偏低。 这是乐观偏差和锚定效应在起作用，应保留一个可见的参照故事，把新条目与它进行比较，而不是凭空估算。

计划扑克与其他估算技巧的对比

常见的错误做法

• 在揭晓之前说出数字，这会重新引入锚定效应。
• 用小时而不是相对点数进行估算。 相对估算更快，也更不容易产生偏差。
• 用取平均值代替讨论。 讨论才是重点，数字只是副产品。
• 让某一个人主导全场。 私密投票的存在正是为了防止这种情况。
• 没完没了地重新投票。 追求完全一致的卡牌只会浪费时间，"足够接近、能够认可"才是目标。

术语表：计划扑克常用词汇

• 故事点数（Story point）： 一种相对工作量的单位（而非小时数），综合了复杂度、不确定性和工作量。
• 卡组（Deck）： 团队投票时使用的一套卡牌（例如斐波那契、T 恤尺码）。
• 速率（Velocity）： 团队每个 sprint 完成的点数，用于预测，而不是用于团队间的比较。
• 锚定效应（Anchoring）： 最先被提及的数字会把其他估算拉向它的偏差，这也是投票需要同时揭晓的原因。
• 异常值（Outlier）： 最高或最低的投票，团队会优先讨论其背后的理由。
• 参照故事（Reference story）： 一个此前已估算过的条目，团队用它来比较新的故事，以保持量表的稳定。

常见问题

一场计划扑克会议需要多长时间？

对于一个正常的 sprint backlog，通常需要 30 到 60 分钟。除非估算出现分歧需要讨论，否则单个条目通常只需 1 到 3 分钟。

应该有多少人参加？

通常是实际执行工作的 3 到 9 人。少于 3 人会失去多元视角带来的好处，多于 9 人则会拖慢讨论速度。

我们应该使用哪种卡组？

斐波那契数列（0、1、2、3、5、8、13 及以上）是最常见的默认选择，因为不断扩大的间隔能反映出较大条目中不断上升的不确定性。T 恤尺码则适合早期、粗略的估算。

为什么所有卡牌要同时揭晓？

为了防止锚定效应——即最先说出的数字会把所有人的估算都拉向它。同时揭晓能让每个人的投票保持独立。

我们应该用小时还是点数来估算？

推荐使用相对点数（故事点数）。它们更容易达成一致，也比研究中显示的、以小时为单位的估算更不容易受到乐观偏差的影响。

如果团队无法达成一致怎么办？

先让投出最高分和最低分的人解释原因，然后重新投票。如果仍然无法收敛，说明该条目很可能太大或太模糊，应将其拆分或退回以进一步澄清。

可以异步进行计划扑克吗？

可以。借助在线工具，团队成员可以按自己的时间投票，等所有人都投完票后再统一揭晓，这对分布在不同时区的团队很有用。由于投票在揭晓前始终保持隐藏，防止锚定效应的效果依然成立。

谁应该参与，Scrum Master 应该投票吗？

所有实际执行工作的人（开发人员、测试人员、设计师）都应该参与。Scrum Master 通常负责主持而不参与投票，Product Owner 负责回答问题，但不参与估算。

计划扑克和 scrum poker 是同一回事吗？

是的，"scrum poker"和"pointing poker"是同一项技巧的常见别称。

参考文献

1. Moløkken-Østvold, Haugen & Benestad (2008). Using planning poker for combining expert estimates in software projects. Journal of Systems and Software, 81(12), 2106 至 2117。
2. Mahnič & Hovelja (2012). On using planning poker for estimating user stories. Journal of Systems and Software, 85(9), 2086 至 2095。
3. Jørgensen & Sjøberg (2001). Anchoring effects: an important cause of too optimistic effort estimates. Simula。
4. Løhre & Jørgensen (2016). Numerical anchors and their strong effects on software development effort estimates. Journal of Systems and Software。
5. Shepperd et al. (2018). An Experimental Evaluation of a De-biasing Intervention for Professional Software Developers. arXiv:1804.03919。