敏捷实践之用户故事估算

任志强 Roger

2019年02月

序  言

敏捷开发近些年在国内软件公司中越来越流行起来，越来越多的公司开始采用敏捷方法并投入精力去研究推广敏捷方法，因此也造就了国内一批又一批敏捷实践者和爱好者，我想当初Kent Beck等敏捷宣言的创始人也未必预见今天敏捷遍地开花的景象吧。

本人从2011年开始在IBM开始接触敏捷开发到后来做Scrum Master到现在的做敏捷教练，在敏捷的学习和实践中受益匪浅。我欣赏甚至是崇拜精益思想和敏捷方法，也特别希望能总结一些想法和心得来记录在这敏捷之路上遇到的困难和问题，从而分享给那些已经或者正准备踏上敏捷之路的朋友们用于个人学习、研究和欣赏，以及非商业或盈利性用途，为在敏捷之路的个人和群体贡献一份力量。

系列文字主要内容来自于个人敏捷转型实践、书箱文献和日常系列活动心得等的提炼总结和创作。此系列文字内容推荐有基本敏捷常识及有一定Scrum理论基础的朋友们阅读，并按实际场景进行参考。如内容涉及版权或原创作者有不同见解之处，敬请及时告知，乐于接受并给予修正。

目录

序  言... 2

1       概述... 4

2       故事粒度级别... 4

2.1       产品列表级... 4

2.2       冲刺列表级... 4

3       故事估算... 4

3.1       估算单位... 4

3.1.1        故事点... 4

3.1.2        理想天... 4

3.2       估算扑克... 5

3.2.1        活动规则... 5

3.2.2        优点... 5

3.2.3        缺点... 6

4       实践中的常见问题... 6

4.1       问题1：故事点数会因为不同的人开发而不同吗？... 6

4.2       问题2：估算必须要精确？... 6

5       额外收益... 6

1        概述

产品负责人在制定产品发布计划时需要考虑每个版本包含哪些产品特性，开发团队在承诺Sprint目标时需要考虑这个目标能否达成，用户故事的大小（可以理解为需求的工作量）将是我们判断上述两个问题的依据，也是本文要讨论的话题：“用户故事估算”。

2        故事粒度级别

为了做好计划，一般会针对产品列表和冲刺列表两个层面进行故事估算。

2.1      产品列表级

实践证明，在正式开始能创造客户价值的第一个冲刺之前，我们需要一个产品列表，但在项目初期我更愿意称之为“概要产品列表”，因为此时的很多故事粒度都比较大，所以估算也是粗略的。而随着产品列表条目的细节加入，团队就可以相对准确的估算用户故事大小了。

2.2      冲刺列表级

冲刺列表中的用户故事很多会被拆分成最小粒度的任务，一般任务级粒度的估算用理想时（工时或人时）。实践中很多团队在任务级的估算是故事负责人自己来做，根据故事的大小进一步细化工作内容和所需工作量。

3        故事估算

3.1      估算单位

用户故事的大小没有标准的单位，实践中最常用两种度量单位就是故事点和理想天，我经历的项目中用故事点更多一些。

3.1.1       故事点

不同团队对故事点数有自己的定义，不一定数字大故事就一定大，且故事点是客观的相对数值。例如，登录功能这个故事点数如果是2个故事点的话，那么注册功能就是登录功能的2倍即4个故事点。2是团队定义的大小，你也可以将登录功能定义成10个故事点，那么注册功能的故事点数就是20。当然，个人不建议用较大的数字去管理，因为不便于计算和比较。

3.1.2       理想天

理想天代表完成一个故事需要多少工时（8小时为一人天），我看过很多书籍比如Kenneth S. Rubin的《Scrum精髓》中就指出理想天不能直接对应到日历上，2个理想天也不是指2个自然天。在实践中我个人并不认同这种说法，如果一个用户故事团队觉得需要2个理想天完成的话，那么就应该是2个人天完成这个故事，前提是你需要清楚“完成的定义”，并且在估算时将所有干扰你完成这个故事所占用的时间算进去，或者干脆预留一个合理的Buffer时间来处理干扰你完成这个故事的工作。

3.2      估算扑克

估算扑克是一种基于共识的估算工作量的技术。最常用的数值范围是有Mike Cohn提出的，部分基于修改的斐波那契数列：1,2,3,5,8,13,20,40和100。

3.2.1       活动规则

整个团队成员都需要在场，每个开发成员都有一套估算扑克（当然也可以用电子版的线上做）。Scrum Master引导、观察团队成员完成估算活动：

l  产品负责人向团队讲解故事细节。

l  如果不理解故事，开发团队讨论这个故事并向产品负责人提出问题，产品负责人回答团队的问题。

l  每个团队成员背靠背选择一张牌代表他的估算。

l  都选择完一张牌后，同时亮牌。

l  如果大家的选择都一样，达成共识。

l  如果大家估算不一样，团队开始讨论原因。通常由给出最高和最低的估算人做出解释或者说明他们的估算是合理的。

l  讨论完成之后，回到第3步重复上述过程直到达成共识。

3.2.2       优点

团队成员通过这种方式可以达成共识。在讨论的过程中每个人都可以思考其故事细节，更好的理解故事内容。

3.2.3       缺点

比较耗时。当团队陷入很多细节讨论时时间就比较难控制，如果一个会议持续4小时（迭代计划的建议时长），大部分的参会者会有精疲力竭的感觉，并且很难保持持久的注意力。

4        实践中的常见问题

4.1      问题1：故事点数会因为不同的人开发而不同吗？

观点：不会。故事点数是团队基于共识的客观衡量单位，不会因为执行人的能力高低而改变，是一个客观的相对值。

4.2      问题2：估算必须要精确？

观点：我们无法要求所有的估算都精确，因为估算本身就是一种预测，预测就有不确定性，我个人认为10%左右的误差都是可以接受的。

5        额外收益

估算过程的主要目的是确定用户故事的大小，但通用户故事估算往往可以给产品列表的重新梳理提供直接有效的反馈。估算过程可以识别过大或者过小的故事，太大的故事不好估算且隐藏风险，太小的故事管理成本大于实施成本又是一种浪费。因此估算故事的过程可以识别故事大小从而进行拆分或者合并产生新的故事，从而给产品列表的更新提供线索。