敏捷实践之故事点估算

黄隽 Charlie

2019年01月

序  言

随着近些年敏捷在行业及企业的推广，越来越多的企业意识到了敏捷所带来的好处，并愿意在敏捷上有所投入，从而越来越多的朋友加入了敏捷从业者行列，愿意学习敏捷知识。多年热衷于敏捷的我，参与或主导大大小小敏捷转型项目实战和敏捷圈线上、线下活动，阅读大量书箱文献，活跃于敏捷大咖们的议题讨论事件，以及从事多年专职顾问的经验，有些小热情总结一系列文字内容帮来分享给那些已经或者正准备踏上敏捷之路的朋友们用于个人学习、研究和欣赏，以及非商业或盈利性用途，为在敏捷之路的个人和群体贡献一份力量。

系列文字主要内容来自于个人敏捷转型实践、书箱文献和日常系列活动心得等的提炼总结和创作。此系列文字内容推荐有基本敏捷常识及有一定Scrum理论基础的朋友们阅读，并按实际场景进行参考。

如以上内容涉及版权或原创作者有不同见解之处，敬请及时告知，乐于接受并给予修正。

目  录

序  言

1     定义和特性说明

1.1      定义

1.2      特性说明

1.2.1        是相对单位

1.2.2        不等同于工作量估算

1.2.3        考虑“完成的定义”

2     案例说明

2.1      常见问题

2.2      解决方法

2.3      主要收益

1          定义和特性说明

1.1       定义

故事点是表述一个用户故事，一项功能或一件工作的整体大小的一种度量单位。当采用故事点估算时，我们为每个待办项分配一个点数。待办项估算结果的原生数据并不重要，我们只关注最后得到的相对估算结果。一个估算值为2的用户故事应该是估算值为1的用户故事的2倍。而它也应该是另一个估算值为3的用户故事的三分之二。团队不要采用100、200、300，而要使用1、2、3。估算结果是比值，而不是绝对值。

“当使用故事点来估算用户故事的大小时，并没有固定的公式来规定如何计算故事点的数值。故事点估算用于评估为了交付一个用户故事所包含的工作量（team effort），用户故事的复杂度(complexity)，风险，以及所有其他需要考虑的元素。——《Agile Estimating and Planning》, Mike Cohn.

1.2       特性说明

1.2.1        是相对单位

它是一个相对单位。比如，不同的组织团队，对于同样的用户故事的故事点大小一般是不同的；即使同一团队，针对不同用户故事的故事点大小，甚至是针对同一用户故事的故事点大小，都允许是不同的。但同时提醒，不同团队不同用户故事的故事点的设定，有利于组织能力的积累和横向参考。

1.2.2        不等同于工作量估算

故事点估算不是简单等同于工作量估算。如Mike Cohn所描述，它包含工作量、技术含量、各方面制约等多方面价值因素。有时其他的这些因素，在故事点估算中占有比重会胜过工作量方面的考虑。

1.2.3        考虑“完成的定义”

故事点估算必须要覆盖直到实现产品待办项待真正完成的所有事项。如果团队的“完成的定义”中包括了创建自动化测试来验证这个故事（并且这是一个好主意）这个事项，那么创建这些测试的工作量也应该包含在故事点估算结果中。

2    案例说明

2.1       常见问题

1)   在Sprint中如何估算故事点？

2)   Sprint计划会议中估算不准，如何解决？

3)   Sprint计划会议中估算时间过长，如何解决？

2.2       解决方法

1)    在敏捷开发中，最典型的使用故事点做估算的方法是计划扑克（Planning Poker）。同时也有另一种更新的估算方法－敏捷估算2.0（Agile Estimating2.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数列，但是它可以显著地缩短会议时间。

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

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

n   第三步，团队将故事点（Story Point）分配给每个用户故事（列）。最简单的做法是使用投票来决定每个用户故事分配到哪一个Fibonacci数字。

n   最后一步：使用不同颜色来区分影响估算大小的不同方面，并且重新考虑是否需要修改估算值。例如，我们使用红色来表示那些无法被自动化测试脚本覆盖的用户故事，因此那些用户故事需要一个更大的数字来容纳手工回归测试的代价。

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

2)    使用Planning Poker进行故事点估算。

3)          使用Agile Estimating2.0进行故事点估算。通常耗费的时间会缩短。

2.3       主要收益

1)   使不同技术水平和工作速度的人在估算结果上保持一致。