BY ERIC ISOM 沈义 · 沈潇灵 译
计划扑克的麻烦是斐波那契数字系列。这是一个令人着迷的系列，有惊人的应用程序，但计划扑克不是其中之一。
在计算产品待办事项中的任务时以及进行sprint计划时，会使用计划扑克。 整个开发团队收集并使用基于Fibonacci数字系列的规划扑克牌。每个人通过选择具有他们认为最能代表相对努力程度的数字的卡来估计完成用户故事的努力。
每个人独立完成，然后每个人同时分享他们的估计值，以便他们的初始估计不受其他团队成员的影响。 然后，团队讨论异常值，经常发现问题 – 有时甚至是简化。
什么是斐波纳契数？
斐波纳契数是一系列数字，其中每个数字是它前面两个数字的总和。
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144,…
这一系列的数字已被采用和修改，用于计划扑克。 卡片组通常包括：
0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, ?, ☕️
我们估计的能力很糟糕
正如Jeff Sutherland在他书中指出的那样，Scrum: The Art of Doing Twice the Work in Half the Time，我们在估计做某事需要多长时间方面真的不怎么样。
就像在这旧的计算机编程谚语中表示的：
“一个不小心计划的项目需要比预期三倍更长的时间完成; 精心策划的项目只需要两倍的时间。”
（原）“A carelessly planned project takes three times longer to complete than expected; a carefully planned project will take only twice as long.”
更好的方式：故事点和速度
但我们擅长估计相对努力，即判断一项任务是否比另一项任务更多努力或更少。
因此，故事点的想法诞生了。使用相对大小而不是实际时间来估计任务。Fibonacci数字系列已成为用于规划扑克的一系列流行数字。
故事点用于测量和跟踪速度，速度是团队在sprint/迭代中完成的故事点数。适当应用，敏捷/ Scrum原则将产生团队的速度随着时间的推移而增加。
然后将速度用于两个主要目的。首先，预测完成项目需要多长时间。其次，衡量团队生产力随时间的提高。
Fibonacci数字的利
- 是衡量速度的绝佳方法; 用于持续改进以及提供管理日期。
- 相对大小的任务。
- 估算与团队或个人技能水平无关。更有经验的团队将能够更快地完成任务，但这不会改变任务的相对大小。
Fibonacci数字的弊
- 太精确了。讨论任务是1/2还是1，1或2，a 2或3，还是3或5等等，就浪费了太多时间。团队经常开始在这些微小的区别上浪费太多时间。后来他们对这个过程感到沮丧就放弃。
- 学习曲线。人们对使用“毫无意义”的数字进行估算感到不舒服。人们习惯于估计时间，并且很难转向相对测量。他们经常将Fibonacci数字视为小时数。这破坏了速度测量。随着项目后期添加新项目，团队速度的提升将被低估。
- 跨团队不一致。 一个团队的5人将是另一个团队的20人。这使得难以衡量多个团队和多个项目的工作量和速度。
- 漂移。对于抽象数字，没有度量单位，团队估计很容易随着时间的推移而变化。随着团队生产力的提高，他们可能会估计与项目早期估计的类似任务相比较低的数字。如果团队正在静静地将Fibonacci数字视为小时数，情况尤其如此。同样，这将破坏测量速度的有用性。我已经看到团队完全放弃了测量速度，因为它漂移使它无用。
理想时长的利
- 熟悉。人们对在理想天数/小时内估算工作量的想法非常熟悉和满意。我们有很多经验和工具来处理基于时间的估算。这是多年来事实上的标准。精明的项目经理已经学会应用特定于人的乘数来将开发人员的估算转换为更真实的日历时间。PERT分析通常用于通过让开发人员为每项任务提供乐观，预期和悲观估计，然后应用加权平均值来获得更准确的估计。你仍然可以计划扑克，并使用计划扑克牌，只需要理想时长而不是相对估计。我曾经一直这样做，但由于软件开发的性质，对悲观估计的权重更大。
理想时长的弊
- 不测量速度改进。团队速度的大多数改进来自过程改进，例如在DevOps中，通常不会在理想时长的估计中有效描述。
- 误导。如果项目经理不小心保护管理层免受开发人员的估计，管理层很容易将理想估计误解为现实估计，并且期望结果比合理的更早。
- 变化性。团队在理想时长内的估计会随着时间的推移而显着变化。团队起初可能过于乐观。后来，因为他们意识到在当前过程和环境下完成任务真的需要多长时间，他们就会更加悲观。最终，随着过程的改进以及它们在当前环境中的估算能力的提高，它们可能是合理的。
T恤大小方法的利
- 适当的精确度。许多人已经认识到Fibonacci数字系列提供了太多的精确度，并且已经转向使用T恤尺码，例如XS，S，M，L，XL。你仍然使用计划扑克过程。你甚至可以使用尺寸为T恤的卡片而不是Fibonacci数字。
- 相对大小
- 出色的速度测量
T恤大小方法的弊
- 跨团队不一致。 与Fibonacci数字一样，T恤尺码在团队之间并不相同。一个团队的L是另一个团队的M。
- 学习曲线。尽管学习曲线比使用Fibonacci数字少，但它仍然是开发人员在相对大小方面进行思考的范例的变化。他们可以悄悄地将时间尺度附加到每个尺寸（例如，XS =一小时，S =一天等），这会破坏其价值。
- 漂移。 与Fibonacci数字一样，该团队的估计会随着时间的推移而变化。
全部小任务的利
- 简单性。有些人选择通过简单地将所有任务划分为它们都具有相同大小来解决这些其他方法的问题。你可以修改计划扑克过程并使用估计来确定需要划分为较小任务的内容。
- 发现。开发一支具有严谨性和才能的团队，将所有任务划分为小任务，具有一定的优势。这有助于发现在sprint/迭代正在进行之前可能无法发现的问题。
- 灵活性。一旦将任务分成小尺寸，就可以根据需要在sprint / iterations之间划分工作，从而改善工作流程。Flexibility. Once tasks are all divided into small sizes, it’s much easier to divide work among sprints/iterations as needed, improving the flow of work.
全部小任务的弊
- 不切实际。有些任务比其他任务要小得多。例如，更改屏幕上某些文本（仅使用一种语言的产品）的措辞，比大多数其他任务可以有利地分成小得多。因此，你至少需要XS和S尺寸。
- 颠覆性。 其他自然M大小的任务只能通过将它们分解成不必要地使开发和测试复杂化的不自然的部分来划分为S大小的任务。
我的计划扑克解决方案：量身定制的衬衫
我的解决方案是使用变化的T恤尺码。我称之为“量身定制的衬衫”。 关键是做两件事：
从理想时长开始
通过最初为每种尺寸分配理想时长，帮助团队超越学习曲线。该范围应支持产品待办事项中的大型史诗和粗略定义的用户故事，以及当前sprint/迭代的较小用户故事。我最喜欢的范围是：
| T恤尺码 | 理想时长 |
| XS | 分钟 |
| S | 小时 |
| M | 天 |
| L | 星期 |
| XL | 月 |
使用计划扑克过程，以及具有这些衬衫尺寸的卡片。
只有XS，S和M任务足够小才能适应sprint/迭代。
在将L和XL任务分配给sprint/迭代之前，必须将它们分成较小的任务。
建立参考任务
通过将每个大小锚定到特定项目任务来避免漂移问题。在项目开始时，帮助团队为每个规模选择一个代表性任务，然后在每个计划会议中，使用这些代表性任务进行比较，以便为新任务提供估算。
你觉得呢？
你喜欢“量身定制的衬衫尺码”的想法吗？ 你最喜欢的估算工作方式是什么？
Sprint规划的最大好处
无论你使用何种技术来估算任务，请记住估算本身并不是sprint计划的最大好处。
正如Ken Rubin在Essential Scrum中正确强调的，sprint规划的最大好处是团队讨论，其中提供了详细信息和不同视角，以发现用户故事实现中的隐藏需求和问题。点击此处了解我为IT专家的培训班。
附：你可能还想看看Scrum失败的两个主要原因