背景

在某开发团队辅导的回顾会议上，团队成员对于优化估计具体方法上达成了一致意见。询问是否有什么具体的估计方法来做估算。

问题分析

回顾意见上大家对本次Sprint的效果做回顾，其中80%的成员对于本次Sprint的估算效果不满意，最终团队希望在下一个Sprint中，估算活动能有所改善。

经了解，团队目前的估算方法很简单，基本上是架构师和团队中有丰富开发经验的成员一言堂。估算的速度也很快。对于有些有疑问的需求，开发成员也是保持沉默，草草认领了任务。

团队迫切希望学习新的估算方法来优化目前的估算活动，因此分享几个具体的估算方法给团队实践，让他们自己选择适合、喜欢的估算方法是解决问题的关键。

解决措施

上篇《如何估算第三篇：利用故事点做估算》了解了什么是故事点后，我们来学习下具体的故事点估算的实践，感受一下估算。这里介绍最常用的两种估算方法：一个是计划扑克估算，另一个是敏捷估算2.0。下表内容展示了这两种估算方法在什么情形下选择。

计划扑克估算

在敏捷开发中，最典型的使用故事点做估算的方法是计划扑克（Planning Poker）。

计划扑克由James Grenning在2002年首次提出。计划扑克集合了专家意见（Expert Opinion），类比（Analogy）以及分解（Disaggregation）这三种常用的估算方法，使团队通过一个愉快的过程快速而准确的得出估算结果。

计划扑克的参与者是团队的所有成员。典型的敏捷团队规模推荐为7±2人，如规模比较大可以考虑拆分成为多个小团队各自独立进行估算。Product Owner也需要参加，但不参与估算。

计划扑克开始时，每个参与估算的组员都会得到一副计划扑克，每一张牌上写有一个Fibonacci数字 （典型的计划扑克由12张牌组成：?，0, ½，1, 2, 3, 5, 8, 13, 20, 40, 100,∞，其中?代表信息不够无法估算，∞代表该用户故事太大）。

开始对一个用户故事进行估算时，首先由Product Owner介绍这个用户故事的描述。过程中Product Owner回答组员任何关于该用户故事的问题。展开讨论时主持人(通常由Scrum Master担任)应注意控制时间与细节程度，只要团队觉得对用户故事信息已经了解到可以估算了，就应当中止讨论开始估算。

所有问题都被澄清后，每一个组员从 扑克中挑选他／她觉得可以表达这个用户故事大小的一张牌，但是不亮牌，也不让别的组员知道自己的分数。所有人都准备好后，主持人发口令让所有人同时亮牌，并保证每个人的估算值都可以被其他人清楚的看到。

经常会出现不同组员亮出的分值差距很大的现象。当出现有很多不同分值的时候，出分最高的人和出分最低的人需要向整个团队解释出分的依据。（主持人需要注意控制会议氛围，避免出现意见不一导致的攻击性言论。）所有的讨论应集中于出分者的想法是否值得团队其他成员进行更深入的思考。

随后全组可以针对这些想法进行几分钟的自由讨论。讨论之后，团队进行下一轮的全组估算。一般来说，很多用户故事在进行第二轮估算的时候就能得到一个全组统一的分值，但是如果不能达到全组意见一致，那么就重复的进行下一轮直到得到统一结论。

敏捷估算2.0（Agile Estimating 2.0）

计划扑克是Scrum团队应用最广泛的敏捷估算方法，但是有时候计划扑克玩起来耗费比较多的时间，尤其是在十人左右的团队中。Ken Schwaber在他的书《Agile Project Management with Scrum》中指出，在进行迭代规划时，迭代计划环节应该控制为一个4小时的固定时间，但是从战术的角度看，如果一个会议持续4小时，大部分的参会者会有精疲力竭的感觉，并且很难保持持久的注意力。

为了解决这个问题，Brad Swanson 和 Björn Jensen在上海Scrum Gathering （2010/4/19）上介绍了Agile Estimating 2.0技术。这个新的估算技术同样基于的专家意见，类比和分解，同样适用Fibonacci数列，但是它可以显著地缩短会议时间。它的估算过程大致分为主要四步，如下图所示：

第一步：由Product Owner向团队介绍每一个用户故事，确保所有需求相关的问题都在做估算前得到解决。

第二步：整个团队一起参与这个游戏。

只有一个简单的游戏规则：一次仅由一个人将一个用户故事卡放在白板的合适位置上：规模小的故事在左，大的在右，一样大的竖向排成一列。整个团队轮流移动故事卡，直到整个团队都认同白板上的故事卡的排序为止。

  第三步：团队将故事点（Story Point）分配给每个用户故事（列）。

最简单的做法是使用投票来决定每个用户故事分配到哪一个Fibonacci数字。

最后一步：使用不同颜色来区分影响估算大小的不同方面，并且重新考虑是否需要修改估算值。

例如，我们使用红色来表示那些无法被自动化测试脚本覆盖的用户故事，因此那些用户故事需要一个更大的数字来容纳手工回归测试的代价。

在国内一些企业多次实践Agile Estimating 2.0之后，反馈的结果还是令人兴奋。据称，团队对于估算的准确性更有信心了，并且只耗费原先的1/2时间。

通过以上介绍，相信了解了如何使用用户故事来分析了解需求。在学习了估算的核心概念及故事点后，对于估算方法的实践也有了更深的体会。不论是计划扑克估算还是敏捷估算2.0都只是估算的一种实践，不是固定的唯一方法。只要理解估算的意义和核心概念，选择适合的方法就是没有问题的。另外补充一下，这里讲的估算偏重于用故事点估算，如果团队成员一致达成共识，用工时或理想人天效果更好，便可以尝试，给予团队试错的机会，说不定也有意想不到的收获。

完成了估算后，我们需要对估算的内容进行管理。华为云DevCloud在用户故事或者Task中均有一个记录估算结果的属性，比如预计工时。所有工作项估算结果记录以后就可以以列表的方式进行查看。可以按处理人排序，查看每个成员认领的任务是否饱和。

开发团队完成的工作内容可以时时更新实际数据，这样每轮迭代也可以就估算准确度进行统计和分析。看看估算结果和实际结果的差别，以便可以后续做估算调整和改善。

参考附录

1. Kenneth S. Rubin. Scrum精髓[M].北京：清华大学出版社。

2. Mark C. Layton. 敏捷项目管理[M].北京：人民邮电出版社。