规划扑克是一种让团队集体估算工作量的方法：每位参与者先独立出一张代表相对投入的牌，再同时亮牌，围绕最大与最小估算的差异讨论依据，多轮收敛后形成团队认可的估算值。它估算的是相对规模，结果主要用于排期、任务拆分和暴露风险；实际工时填报与产能分析属于另外的管理环节。估算结论要落到工作项和记录上时，可以借助 ONES 这类研发管理工具承载。
要点总览（TL;DR）
- 规划扑克是团队集体估算相对投入的方法：独立出牌、同时亮牌、讨论分歧、多轮收敛，产出的是团队共识而非精确工时。
- 牌面数字没有单位，只表示需求之间的相对大小；结果主要用于排期、任务拆分和暴露需求不清、方案未定等风险。
- 它只覆盖投入预估环节，实际工时填报与审核、产能与投入产出分析属于另外的管理环节，估算值也不等于交付承诺。
- 与单人估算、三点估算、直接填人天相比，规划扑克精度预期更低但共识度更高，可与三点估算、历史速度换算组合使用。
- 常见误解是把牌面当工时、把分歧当不专业、把一次估算当永久有效；分歧往往指向信息缺口，需求变化后应重新估算。
规划扑克一句话说清：它估算的是什么
规划扑克（Planning Poker）是敏捷团队常用的一种集体估算方法。它的核心动作可以概括为四步：需求讲解后，每位参与者独立选择一张牌；所有人同时亮牌；针对最高与最低估算之间的差距，各自说明依据；再重新出牌，直到团队对某个数值形成共识。
它估算的对象是相对规模或相对投入，比如一个需求比另一个需求大多少、复杂多少，而不是精确到人天的绝对工时。牌面数字本身没有单位，它的意义来自团队内部的横向比较：一个标为 5 的需求，大致是一个标为 2 的需求的两倍多工作量。
这种估算结果有三个主要用途。第一是排期：团队知道一批需求的相对大小后，可以结合历史速度判断一个迭代能装下多少。第二是任务拆分：估算偏大的需求往往需要拆成更小的条目再进入开发。第三是风险暴露：出牌分歧集中的地方，通常正是需求描述不清、技术方案未定或依赖关系复杂的部分，讨论过程本身就在帮团队发现问题。
需要说明的是，规划扑克产出的是团队对投入的共同判断，它服务的是计划与沟通，精度预期停留在“量级”层面。把它当作精确工时表使用，会超出这种方法的设计范围。
规划扑克的边界：哪些事不归它管
规划扑克只覆盖“投入预估”这一个环节。理解它的边界，比记住它的流程更能避免概念混用。下表按环节对照说明。
| 环节 | 是否属于规划扑克 | 说明 |
|---|---|---|
| 团队对需求相对规模的集体判断 | 属于 | 独立出牌、同时亮牌、讨论分歧、多轮收敛 |
| 需求澄清与验收标准讨论 | 部分相关 | 讲解需求是估算的前置动作，但需求文档的定稿不属于估算环节 |
| 实际工时填报与审核 | 不属于 | 成员每天或每周记录实际投入，由项目经理审核，属于执行跟踪环节 |
| 团队产出指标与产能分析 | 不属于 | 速度、利用率、负荷度、投入产出比等指标基于历史数据统计，属于效能分析环节 |
| 承诺交付时间 | 不属于 | 估算值是排期输入之一，交付承诺还要考虑人员可用性、依赖和外部约束 |
把这几件事分开看，能避免两类常见问题。一类是把估算牌面直接当工时用，导致计划失真；另一类是拿估算值去考核个人产出，让参与者在出牌时倾向于保守或迎合，估算失去讨论价值。
估算结果与工时记录之间可以建立衔接：估算给出相对规模，排期确定计划投入，执行中记录实际工时，事后用实际数据校准团队对规模的判断。这条链路里，估算只是起点。ONES 的资源和工时管理解决方案支持统计项目工时、查看项目和团队的资源利用率及负荷度，也支持查询和导出工时登记日志明细，适合承接估算之后的执行跟踪与投入分析；具体可用功能取决于所购模块组合。
一副牌怎么跑完：规划扑克的组成与流程
规划扑克之所以能收敛出共识，靠的是“先独立判断、再公开讨论”的机制：独立出牌避免从众，同时亮牌让分歧无处隐藏，讨论把分歧转化为对需求的理解。
牌面体系
常用牌面是一组斐波那契式数列，例如 1、2、3、5、8、13、21。数值间隔逐渐拉大，是因为估算精度随规模增大而下降，没必要在 13 和 14 之间纠结。除数字牌外，通常还有几张特殊牌：
- 问号牌：表示出牌者信息不足，无法判断，需要先补充需求说明。
- 咖啡杯牌：表示需要休息，或这个条目需要拆开单独讨论。
- 无穷大牌：表示这个需求大到无法在当前粒度下估算，必须先拆分。
角色分工
| 角色 | 主要职责 |
|---|---|
| 主持人 | 控制流程节奏，组织出牌与讨论，防止个别人主导讨论，记录最终结论 |
| 需求讲解者（通常是产品经理） | 说明需求背景、范围和验收标准，回答提问，不参与引导结论 |
| 出牌者（开发、测试等执行成员） | 独立判断并出牌，说明自己估算的依据，参与讨论 |
标准流程
- 讲解需求：讲解者介绍一个需求条目，说明目标、范围和验收标准。
- 答疑：出牌者提问，澄清不清楚的地方。信息不足时先补充，不急于出牌。
- 独立出牌：每人选择一张牌，扣在桌上或私下选择，互不影响。
- 同时亮牌：所有人一起亮牌，避免后出牌者被前面的数字影响。
- 讨论分歧：请出最大和最小的人分别说明理由，重点讨论差异来源，而不是争论谁对。
- 重新出牌：讨论后再次独立出牌，通常一轮讨论就能明显收窄。
- 记录结论：达成共识后记录估算值，进入下一个需求。
多轮收敛的停止条件
停止条件需要事先约定，常见的有三种：所有人出牌一致；分歧收敛到相邻两档且讨论已充分；主持人判断剩余分歧属于信息不足，转为拆分需求或另行调研。一般建议最多三轮，超过三轮仍无法收敛，说明问题不在估算方法，而在需求本身。
估算结论需要落到具体条目上，才能被后续排期引用。ONES 的项目管理模块可以把需求作为工作项管理，估算结论记录在工作项上，与状态、负责人一起进入迭代计划；估算结果如何与排期视图联动，建议在实际产品中核验。
容易混淆的相邻概念：规划扑克与几种常见估算做法
规划扑克常与几种估算做法混用或混称。它们回答的问题不同，适用场合也不同，下表按同一口径对照。
| 方法 | 估算对象 | 是否依赖集体讨论 | 典型适用场合 |
|---|---|---|---|
| 规划扑克 | 相对规模 | 是，核心机制就是集体讨论 | 迭代计划会，团队需要对一批需求形成共同判断 |
| 单人/专家估算 | 相对规模或工时 | 否，依赖个人经验 | 需求少、团队小，或需要快速给出初步判断 |
| 三点估算 | 工时区间 | 不一定 | 需要给出乐观、最可能、悲观三个值并计算期望与波动 |
| 直接填人天估算 | 绝对工时 | 不一定 | 合同报价、跨团队资源申请等需要绝对数字的场合 |
与单人估算相比，规划扑克的价值在于把不同角色的视角放进同一个讨论：开发关注实现复杂度，测试关注验证成本，产品关注范围边界。分歧本身就是信息。
与三点估算相比，规划扑克给出的是一个相对档位，不直接产出概率区间；三点估算则明确处理不确定性，适合需要量化风险的场合。两者可以组合：先用规划扑克定相对规模，再对高风险条目单独做三点估算。
与直接填人天相比，规划扑克的精度预期更低，但共识度更高、讨论成本更集中在需求澄清上。需要对外承诺绝对工期的场景，可以在规划扑克结论的基础上，结合团队历史速度换算为时间范围，再留出缓冲。
一个具体例子与三个常见误解
以下为情景演示，用于说明流程如何运行，不代表任何真实团队的数据。
示例：一个需求从讲解到收敛
某团队在迭代计划会上估算“订单列表增加按时间范围筛选”这个需求。讲解者说明范围：只做前端筛选与后端查询参数，不改动导出功能。第一轮出牌，开发 A 出 3，开发 B 出 8，测试出 5，出现明显分歧。
主持人请出 8 的 B 先说明：现有查询接口不支持时间范围参数，需要改接口并补兼容逻辑，还要考虑历史数据的时区问题。出 3 的 A 则认为只需在前端加控件、后端加一个条件。讨论后团队发现，分歧来自对“是否包含历史数据迁移”的理解不同。讲解者确认本次不含迁移，但接口改造确实存在。第二轮出牌，结果集中在 5 和 8，再简短讨论后统一为 5，记录在工作项上，并标注“接口改造需与后端确认时区处理”作为风险项。
三个常见误解
- 误解一：牌面数字等于工时。牌面上的 5 不是 5 小时或 5 天，它只表示相对大小。把它当工时直接排期，会让计划建立在错误的精度假设上。
- 误解二：分歧大说明团队不专业。分歧往往说明需求信息不足或技术方案未定，这正是估算要暴露的问题。压制分歧、追求快速一致，反而会让风险留到开发阶段。
- 误解三：估算一次就永久有效。需求范围变化、技术方案调整、团队人员变动，都会让原有估算失效。估算应随需求变更重新进行，或在迭代回顾时用实际数据校准团队的判断标准。
估算结论记录之后，执行阶段的工时登记与投入分析是另一条链路。ONES 的资源和工时管理解决方案提供资源规划视图，管理者可以按业务优先级安排团队资源，并多维度查看项目和成员的资源投入情况，让估算、排期与实际投入形成可对照的记录；具体模块组合以实际采购与配置为准。
常见问题
团队第一次引入规划扑克，需要先准备什么？
先准备三样东西：一套牌面（数字牌加问号、咖啡杯等特殊牌）、一位愿意控场的主持人、以及讲解清楚的需求条目。更关键的是事前约定规则：出牌是否匿名、最多讨论几轮、分歧到什么程度算收敛、估算值记录在哪里。规则先定好，讨论时才不会把时间花在流程争议上。
另外要提前和团队说明估算结果的用途——用于排期和拆分，不用于个人考核。这一点如果没说清，参与者出牌时会倾向于保守或迎合，估算就失去讨论价值。
远程或分布式团队怎么开展规划扑克？
核心机制可以保留：每人先私下选择、再同时公开。线上可以用支持同时揭晓的投票工具，或者约定倒数后一起在聊天窗口发出数字。主持人要额外注意两点：一是确保每个人都有发言机会，避免声音大的成员主导讨论；二是把讨论依据记录在共享文档或工作项里，方便缺席成员回看。
远程场景下需求讲解更容易出现信息遗漏，建议讲解材料提前发出，把答疑时间留足，减少因信息不足导致的无效出牌。
估算分歧一直收敛不了，应该怎么处理？
先判断分歧的性质。如果分歧集中在需求范围（比如是否包含历史数据迁移），说明需求本身没讲清，应暂停估算、补充说明后再来；如果分歧集中在技术方案，可以安排一次小范围技术预研，把方案定下来再估；如果分歧来自对同一需求的理解粒度不同，通常需要先拆分条目。
建议事先约定轮次上限，比如最多三轮。超过上限仍无共识，把它标记为待澄清或待拆分，比强行取平均值更诚实——平均值会掩盖真实的不确定性。
估算值和后来的实际工时对不上，是不是方法有问题？
两者本来就不是同一口径：估算给的是相对规模，实际工时记录的是执行投入，中间还隔着排期、人员可用性和需求变更。对不上是常态，关键看偏差是否有规律。如果某个类型的需求总是被低估，说明团队对该类工作的判断标准需要校准；如果偏差来自范围变更，那属于需求管理问题，不是估算方法失效。
可行的做法是在迭代回顾时对照估算与实际投入，讨论偏差来源，逐步调整团队对规模档位的共同理解。ONES 的资源和工时管理解决方案支持统计项目工时、查询和导出工时登记日志明细，可用于这类事后对照；具体可用功能取决于所购模块组合。
规划扑克适合所有团队和所有需求吗？
它更适合需要团队共同判断、且需求可以按相对大小比较的场景，比如迭代计划会上对一批需求做批量估算。需求很少、团队很小，或者只需要一个快速初步判断时，单人估算的成本更低。对外合同报价这类需要绝对数字的场合，也不宜直接用牌面数字，应结合历史速度换算并留出缓冲。
另外，如果团队还没有稳定的迭代节奏和历史数据，规划扑克的相对档位缺少参照，可以先跑几轮积累比较基准，再用于排期。
