敏捷扑克_敏捷扑克牌估算
- 3
什么是敏捷扑克/计划扑克？
敏捷扑克是一种基于共识的、用于估算产品待办列表项（如用户故事）相对工作量的团队活动。它通过使用一副特殊的扑克牌，将复杂的专家判断、讨论和类比估算过程游戏化，从而避免了个别权威人士主导估算结果，并促使团队对估算结果达成一致。
核心目标
1. 达成共识：确保整个团队（开发、测试等所有角色）对某个任务的工作量有一致的理解。
2. 激发讨论：通过差异化的估算值，暴露出团队成员对任务理解的不同之处，从而澄清需求、识别风险和依赖。
3. 提高估算准确性：相对于个人估算，集体的智慧和讨论能产生更可靠的相对估算。
4. 趣味性：以游戏的形式进行，让原本可能枯燥的估算会议变得更有参与感。
所需工具
* 参与者：整个开发团队（包括所有角色）、产品负责人（负责澄清需求，但不参与估算）、Scrum Master（作为引导者）。
* 一副特殊的扑克牌：牌上不是传统的A、K、Q、J，而是代表故事点或理想人天的数字序列。最常用的序列是修改后的斐波那契数列：
* `0, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? (问号)，☕ (咖啡杯)`
* 为什么用这个序列？ 因为对于越大的任务，我们的预估能力越不精确。这个数列的间隔越来越大，迫使团队在任务变大时选择更粗略的估算，或者将其拆分成更小的任务。
* “?” 牌：表示“我对这个任务完全不了解，无法估算”。
* “☕” 牌：表示“我需要休息一下！”或者“这个任务太简单了，不值1个点”。
操作流程（步骤）
1. 准备
* 产品负责人准备好需要估算的用户故事列表，并向团队简要介绍每一个故事。
* 每位团队成员都拿到一副敏捷扑克牌。
* 选择一个基准故事（通常是一个小而简单的故事），并赋予它一个基准点数（例如，2点），以便后续故事与之比较。
2. 开始一轮估算
* 第一步：描述故事。产品负责人向团队描述一个待估算的用户故事，并回答团队成员提出的任何问题。
* 第二步：私下选牌。每个团队成员基于自己对故事工作量（包括开发、测试、集成等所有环节）的理解，从自己的牌堆中私下选择一张代表其估算值的牌。关键：不要受他人影响。
* 第三步：同时亮牌。当所有人都选好牌后，由引导者（如Scrum Master）发出指令，大家同时亮出自己的牌。
3. 讨论与达成一致
* 情况A：估算一致。如果所有人或绝大多数人亮出的牌相同，那么恭喜！团队就此故事的估算值达成共识，记录该点数即可。
* 情况B：估算不一致。这是最常见且最有价值的情况！
* 请估算最高和最低的成员分享理由。例如，亮出“8”的成员可能会说：“我认为这里涉及一个我们不熟悉的技术难点。”而亮出“3”的成员可能会说：“我觉得这个功能很简单，因为我们上周做过类似的。”
* 团队讨论。基于他们的分享，团队进行简短的讨论，澄清误解、技术方案或潜在风险。产品负责人可能需要进一步澄清需求。
* 重新估算。讨论结束后，团队重复步骤2和3：再次私下选牌，然后同时亮牌。
* 重复这个过程，直到团队的估算值趋于一致（不需要完全一致，允许有小范围偏差）。
4. 结束一轮并继续
扑克游戏* 一旦达成共识，就将最终的故事点记录在该用户故事上。
* 产品负责人接着介绍下一个用户故事，重复整个过程。
敏捷扑克序列的含义示例
| 牌面 | 含义 含义解释 |
| :--
| 0 | 几乎不花时间，或者已经完成。 |
| 1/2 | 非常小、简单的任务。 |
| 3, 5, 8 | 中等复杂度的任务。团队对此有较好的掌控感。 |
| 13, 20 | 比较复杂的大型任务。需要考虑是否应该拆分成更小的故事。 |
| 40, 100 | 非常庞大、模糊的任务（史诗级）。必须拆分后才能进行开发。 |
| ？ | “我完全没概念，需要更多信息。” |
| ☕ | “我累了，需要休息！”或“这个太小了，不值一提。” |
优点
* 快速高效：相比无休止的争论，结构化的流程能更快得出结论。
* 民主公正：避免了“老板效应”或“资深员工效应”，每个人的声音都被听到。
* 知识共享：在讨论中，团队成员分享了不同的技术视角和对业务的理解。
* 承诺感：因为估算是团队共同做出的，团队对完成这些任务更有责任感和承诺感。
注意事项
* 估算的是“工作量”，不是“时间”：故事点是一个相对单位，衡量的是复杂性、工作量和风险的综合体，而非具体的小时或天数。
* 产品负责人不参与估算：他们只负责澄清“做什么”（What）和“为什么”（Why），而由团队决定“怎么做”（How）和估算其工作量。
* 时间盒：为每个故事的估算设定时间限制，防止在某个问题上陷入僵局。如果长时间无法达成一致，可以先标记出来，会后再议。
敏捷扑克不仅仅是一种估算工具，更是一种强大的团队沟通和知识对齐机制。 它是敏捷实践中“个体和互动高于流程和工具”这一价值观的完美体现。
