最近 Hayim Makabee 在他的博客上发表了题为“使用计划扑克预防工作量估算谬误”的博文，探讨了工作量估算中一个名为计划谬误（planning fallacy）的常见问题，并介绍了计划扑克是怎样帮助大家预防这一问题的。
对管理者和工程师而言，工作量估算可能是软件开发过程最令人头疼的活动之一了。其中一个常见的问题是由于计划谬误导致的工作量估计过低。 Wikipedia 上将计划谬误定义为
当人们着手估算某项任务时，尽管已有超支完成类似任务的经历，仍然有低估所需工作量的趋势。
为了阐述此问题的潜在特质，Makabee 援引了《思考，快与慢》 一书的作者、诺贝尔奖获得者Daniel Kahnemann 的理论。许多计划和预测往往脱离实际而向最理想情况靠拢，通过与相似场景的统计数据进行对比，可以改善这种情况。
Makabee 认为在软件工程中产生计划谬误可能有两个主要原因：
- 如果管理者是做估算的人，他会倾向于把计划做得有挑战性，督促手下人更卖力干活。管理者总希望看到工作尽可能快得做完。
- 如果干活的人来做估算，他会不好意思给自己安排太多时间。大家一般不想为自己负责的任务做悲观估计，因为这可能会显得他们懒惰无能。
因此，应该有另外一些对任务不含个人偏好的人参与做计划。
这也正是作者所说的，Scrum 的计划扑克的作用。它强制不同的参与者独立估算工作量，并以达成一致为目标。在用计划扑克时，参与者各持一套标有特定数值的牌，估算某项任务的工作量时选出一张牌作为估算值。每个人选的牌会“同时摊出来，以供大家比较及讨论各自的估算”。Makabee 建议要利用好计划扑克，从而达到规避计划谬误的目的，因为参与玩计划扑克的人中有很多并不负责那项任务。另外，参与者不仅独立完成估算，还要对自己的估算做出解释，尤其是很高或很低的时候。
一些读者就此文谈了自己的看法。
Putcha V. Narasimham 认为计划扑克确实很有用：
前阵子我就遇到过计划谬误，那时不知道敏捷有计划扑克这剂良方。事实上它是种很棒、很实用的方法，是我在敏捷理论中遇到的不可多得的务实方法。
Kirschilan 补充道
除了上面谈到的以外，值得注意的是，用计划扑克做估算是大势所趋。还有一种常见的方法是将真实的经验数据匹配到计划内容中。敏捷中把这个概念称为速率。
它的理念是，假设我们的估算模型相当稳定，而不是太乐观，那么我们就能用这些数据标识出前一段我们实际花了多少时间完成任务，进而计划接下来的任务。
持续使用这些数据有助于团队“从近一段时间完成类似任务的统计数据中获得经验”。以下是一个关于运用经验数据进行持续计划，来替代预先计划的博文：
http://fostnope.com/2012/05/14/what-does-a-butterfly-say-at-the-end-of-the-day/
另一个叫 Pavel Bekkerman 读者认为，管理者由于缺乏足够的培训而导致工作量估算过低一直是最糟糕的情况。她还说：
没有合适的方法，我们的队员和队伍会离他们该做的事越来越远，甚至将总体规划抛于脑后。我们要管理者是为了致力于拨开迷雾、拨乱反正，而不是火上浇油、越帮越忙。那么当前最基本的问题是：
你真的认为有了这个古老的方法，就能期望某人吸取历史教训，可以合理估算那些不只是一、两个工作日就能搞定的活儿？
…Makabee 就此回答道：
[…] 不管怎样，我认为确实有些公司比另外一些做得更好。尤其是我见过通过实施敏捷方法，大大改善软件开发的真实案例 […]
查看英文原文： The Planning Poker Prevents Fallacies in Effort Estimates
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论