深度解析：故事点估算看这一篇就够了 | IDCF

我在辅导团队对用户故事进行故事点估算的时候，常常会遇到以下问题：

• 用户故事的工做量估算为何要用故事点，而不是时间？
• 故事点估算为何要用斐波那契数列？
• 斐波那契数列的数字为何被改了？
• 为何要用估算扑克？
• 为何要有基准故事？
• 怎样肯定基准故事？
• 其余故事怎样与基准故事作相对估算？
• ……

我在翻阅了大量零散的资料之后，终于把这些问题搞清楚了。若是你也遇到过相似上述的问题，能够花点时间阅读下这篇文章，相信不会让你失望的。

1、为何用故事点而不是时间

在回答这个问题以前，咱们先看个例子：

韩梅梅和李雷一块儿去北京奥林匹克森林公园跑步，李雷对韩梅梅说：咱们跑南园这条路吧，这大概要花30分钟。

这条路韩梅梅很熟，可是做为一个跑步很慢的人，韩梅梅内心清楚这要花60分钟。因此，韩梅梅告诉李雷，她跑过这条路的，须要花60分钟。

而后他们就争执起来了：30-60-30-60……

他们争执半天没有结果，做为一个热心的旁观者，你可能会劝他们互相妥协一下，就算45分钟吧？可是这样也许是最坏的结果，由于他们虽然有了一个折中的方案，可是这个结果对双方都不太实际：李雷以为太慢了，而韩梅梅以为太快了。

因此，他们继续争论：30-60-30-60……

最终，李雷跟韩梅梅说：南园这条路大概5km，我能在30分钟内跑完它。

韩梅梅说：我赞成这段路程是5km，但它要花我60分钟。

他们两个都是对的：李雷真的能在30分钟内跑完，韩梅梅也真的须要60分钟。但当他们想为这段路程统一时间估算时，他们发现作不到，由于你们跑步的速率不一样。

可是，当他们使用了一个抽象的长度度量单位（km），他们很快就达成了一致。李雷和韩梅梅都赞成这段路程是5千米，可是因为他们的速度（相对度量单位）不一样，致使他们花费的时间（绝对度量单位）也不一样。

例子说完了，不少人这时候可能已经想到了一个公式：距离（km）=速度（km/h）*时间（h），那我为何要举这个例子呢？难道只是带你们回忆一下小学数学？

其实软件开发中任务的工做量跟跑步的“距离”是很是相似的概念：同一个任务，无论谁来作，它的工做量都是同样的，只不过能力强的人就作得快一点（耗时少）；能力弱的人就作得慢一点（耗时多）。

与跑步相似，若是咱们让多我的就同一个开发任务的耗时达成一致，那是很难的，可是若是咱们能有一个描述软件开发工做量的单位（相似表示举例的km），咱们可能就能很快达成一致。而“故事点”就是敏捷开发创造出来的用来表示开发任务工做量的单位，它跟例子中用来表示距离单位的“km”的做用差很少：它能使不一样技术水平和工做速率的人在工做量的估算上快速达成一致。固然，敏捷开发的主角是具备不一样工做效率的开发人员，而不是例子中不一样跑步速度的跑者。

就像这两个跑步的人，两个程序员也许赞成一个用户故事是5个故事点（类比例子中的5千米，都是一种抽象度量单位）。高级开发人员可能以为这很容易，1天（时间）就能完成。初级开发人员可能以为须要2天才能搞定。可是他们能在5个故事点上快速达成一致，由于把第一个用户故事定成5个故事点是不须要什么依据的（就像不一样国家或地区对长度单位的定义可能不一样，好比米、寸、英寸等，每一个团队对故事点的大小也均可以有本身的标准，只要团队成员都承认便可）。

不过，最重要的是，一旦他们赞成第一个故事的工做量是5个点，这两个开发人员就能够对后续估算达成共识。若是高级开发人员认为一个新的用户故事将须要两天（两倍于他估计为5个点的故事），他将评估新的故事为10个点。而初级开发人员也会这样作，当他估算须要4个工做日时（两倍于他估计为5个点的故事），他将评估新的故事为10个点。

因此，使用故事点而不使用时间的缘由是，故事点可使能力不一样的开发人员在估算同一任务时快速达成一致。

2、为何要用斐波那契数列估算故事点

2.1 人们没法分辨过小的差别

德国生理学家E.H.韦伯经过对重量差异感受的研究发现一条定律，即感受的差异阈限随原来刺激量的变化而变化，并且表现为必定的规律性，刺激的增量(△I)和原来刺激值(I)的比是一个常数(K)，用公式表达即K=△I/I，这个常数叫韦伯常数、韦伯分数或韦伯比率。

上面的定义是从百度百科拷贝下来的，简单来讲就是：咱们只能分辨出两个物体间必定百分比外的差别。

好比：咱们大部分人都能分辨出1公斤和2公斤物体，但可能没法分辨出20公斤和21公斤物品。它们一样是相差了1公斤，为何有的能分辨出来，有的就分辨不出来了呢？这是由于1公斤和2公斤之间的差异是100％，可是20公斤和21公斤之间的差别仅为5％，20公斤和21公斤之间的百分比差别过小了。

这就是韦伯定律想要告诉咱们的：差别过小，咱们是分辨不出来的；只有差别大到必定程度，才能被咱们分辨。那人们能够分辨出多大比例的差别呢？

2.2 人们能够分辨出的差别比例

韦伯定律只是告诉了咱们能够识别必定百分比差别外的区别，可是这个百分比是多少呢？天然界有个神奇的数字：0.618，即黄金分割比例。

黄金分割比例的现象在咱们身边有不少，好比：

• 人们的肚脐是人体总长的黄金分割点
• 大多数门窗的宽长之比也是0.618
• 有些植茎上，两张相邻叶柄的夹角是137°28'，这刚好是把圆周分红1:0.618
• 一些名画、雕塑、摄影做品的主题，大多在画面的0.618处
• ……

甚至在医学领域，当一个患者报告说本身感觉到了病情的好转，那么实际上他的病已经好了65%。

也就是说，61.8%这个百分比差别对不少人来讲，是能够轻易分辨出来的。

2.3 斐波那契数列大体符合了黄金分割比例

斐波那契数列之因此能很好的用于故事点的估算，是由于该数列的数字分布大体符合了黄金分割比例。在这个数列中，一、二、三、五、八、1三、21……，前两个值（后一个值比前一个值大100％）以后，后面的每一个数字都比前一个数字值大60％左右。

根据韦伯定律，若是咱们能够区分两个工做量相差60％的故事，则能够区分其余相同百分比差别的故事。

所以，斐波那契值之因此能很好地工做，是由于它们每次都以大约相同的比例增长，且该比例基本符合黄金分割比例。

3、为何敏捷估算要使用修正后的斐波那契数列

标准的斐波那契数列是一、二、三、五、八、1三、2一、3四、55……，可是目前绝大多数团队在估算时使用的斐波那契数列是一、二、三、五、八、1三、20、40、100……，数列的前面6个数字是同样的，可是从第7个数字开始，就彻底不同了，这是为何呢？

Mike Cohn曾经在他的文章中提到，早期的估算他都是根据真实的斐波那契数列进行的（一、二、三、五、八、1三、2一、3四、55……）。

这个数列越日后数字越大，也就说明估算越不许确，因此对于2一、3四、55这样的估算值，不少人都以为很奇怪：既然已经估不许了，为何非要使用21，而不将其四舍五入为20或25呢？

因而Mike Cohn就接受了这个建议，在以后的团队辅导及授课中他就开始使用20而不是21了，而且一直持续到了如今。

后来他又尝试使用了40和100这两个数代替了数列的其余值，之因此这么使用，是由于任务的粒度越粗，估算就越不许确，也就越不须要纠结究竟是80、90仍是100了。

同时，使用40和100也是不违反韦伯定律的，它们分别比以前的数字增长了100％（20 →40）和150％（40 →100）。这比黄金分割比例的61.8％大得多，人们是能够轻松的分辨出这些工做量的区别的。

后来在Mike Cohn的影响下，如今大部分公司在敏捷估算中都开始使用修正后的斐波那契数列了：一、二、三、五、八、1三、20、40、100、∞。

4、为何要使用规划扑克

相信不少人在估算故事点时，都是使用物理或电子的规划扑克进行的，咱们为何要这么作呢？这个问题须要从一个心理学名词“从众效应”提及。

4.1 什么是从众效应

在估算故事点时，当有人提出一个估算，即便你不一样意，但当别人都表达赞同时，你仍是会随声附和，这就是所谓的“从众效应”：人们认为若是其余人都赞同某一件事时，那么本身的保留意见则是愚蠢的或是误导性的，他们不想在其余人面前出丑。

这个弱点不是个体独有的，而是全人类共有的。

与“从众效应”相关的概念还有信息瀑布和光环效应：

1）信息瀑布

一篇叫作《A Theory of Fads, Fashion, Custom, and Cultural Change as Informational Cascades》的论文中首先提到了这个概念：若是一我的观察到以前众人的行为后，认为最佳的作法是放弃本身掌握的信息，听从以前众人的行为，那么这个时候信息瀑布就出现了。

2）光环效应

当认知者对一我的的某种特征造成好或坏的印象后，还倾向于推论该人其余方面的特征，本质上属于以偏概全的认知错误。与从众效应同样，光环效应也会致使人们将目光集中到某一个有正面色彩的光环上，从而忽视了实际数据。

从众效应的危害很大，咱们要怎么作才能避免它呢？

4.2 使用“德尔菲法”下降从众效应的影响

德尔菲法，也称专家调查法，1946 年由美国兰德公司创始实行，其本质上是一种反馈匿名函询法，其大体流程是在对所要预测的问题征得专家的意见以后，进行整理、概括、统计，再匿名反馈给各专家，再次征求意见，再集中，再反馈，直至获得一致的意见。

兰德公司使用这个方法作过一个匿名投票，投票的主题是“冷战期间，若是苏联要摧毁美国的主要工业目标，须要多少枚原子弹？”。

他们找来了一群专家，包括4名经济学家、1名物理脆弱性方面的专家、1名系统分析师及1名电气工程师。这几我的都是各个领域的专家，可是第一轮投票的结果差异很是大，少则50枚，多则5000枚。

在第一轮投票后，组织方将各个专家的意见整合后发给了你们，好比各个目标的脆弱性、各个行业的恢复能力、工厂的安全性、不一样零部件的交付周期、打击目标的准确性等等，而后又组织各位专家进行了第二次投票，评估差别缩小到了89~800之间。

反复开展上述过程，最终差别愈来愈小，最后落在了167~360之间。

最初的评估结果相差100倍，到最后，缩小到了2倍。借助这一工具，既能让专家达成广泛的共识，又不会担忧出现什么偏见。

为了下降用户故事估算时的“从众效应”，因此如今不少团队就采用了规划扑克这种独立投票的方式。规划扑克的具体使用方法会在第5.3节中进行介绍。

5、如何估算故事点

5.1 肯定基准故事点

每次估算时，最好使用相同的基准用户故事做为1个点（称做基准故事点，相似表示距离时先肯定好1km表明多长），这样对于整个项目的统计有很大帮助。其余的故事都基于这个基准故事作相对估算，就能够获得其余故事的工做量了，每一个迭代完成的故事点能够有效的统计团队生产能力在各个迭代的变化。

对于初次实施敏捷的团队，对基准故事和基准故事点的肯定可能会很迷茫：基准故事点若是定的太大，可能就会存在不少低于1故事点的故事；定的过小了又会致使其余故事的故事点会很大。根据个人实践经验，初次评估故事点时，能够尝试使用一个有1次先后端网络通讯、前端有一个页面、后端有一次数据库交互的用户故事做为基准故事，将其工做量定位1个故事点，好比不少系统都有的登陆功能，就是一个很好的基准故事，这样的故事工做量不会太大，同时也不至于太简单。

5.2 相对估算的依据

基准故事点肯定好之后，其余的故事怎样与它对比呢？怎样肯定另外一个故事的工做量是基准故事的几倍呢？咱们能够从如下3个因素考虑：

1）要开展的工做数量（The Amount of Work）

若是要开展的工做越多，工做量的估算值固然就会越大。考虑两个网页开发的案例。第一个网页只有一个字段和一个要求输入姓名的标签。第二个网页有100个要输入一小段文本的字段。

第二个网页并不比第一个网友更复杂。字段之间是不存在交互的，每一个字段只不过是一点文本而已。所以第二个网页并不存在额外的风险。这两网页之间的惟一区别就是第二页有更多的事情要作。

应该给予第二个网页更多的故事点数。但它即便有多了100倍的字段数，可能仍然得不到多100倍的点数。毕竟，因为规模经济效应，第二个网页的工做量可能只是第一个网页的工做量的2或3倍。

2）风险和不肯定性（Risk and Uncertainty）

用户故事的风险和不肯定性会影响其故事点估算值。

若是用户故事的干系人在询问需求时说得不清不楚，那么团队在估算时应当把不肯定性也反映在估算结果中。

若是要实现一项功能时须要改动一段缺少自动化测试、结构脆弱的老代码，那么估算结果中也应该反映这个风险。

3）复杂度（Complexity）

在进行故事点估算时，还应该考虑复杂度。回顾一下以前那个有100个琐碎文本字段且字段之间无交互的Web网页开发的例子。

如今考虑另外一个也有100个字段的网页。但这些字段中，有些是采用日历控件弹出的日期字段；有些是格式化的文本字段，如电话号码或身份证号；另外一些字段则须要作银行卡号的校验和验证。

页面上的字段之间还要相互交互。若是用户输入的是一个189开头的号码，则运营商字段默认显示中国电信。可是若是用户输入的是一个139开头的号码，则运营商字段默认显示中国移动。

尽管这个页面上仍然只有100个字段，但这些字段更难实现。它们更复杂，须要花更多时间才能实现。开发人员出错的可能性更大，所以不得不采起一些预防和纠正措施。

这种额外的复杂度都应该反映在所提供的估算结果中。

5.3 使用规划扑克集体估点

(规划扑克)

在4.2节介绍了怎样使用“德尔菲法”下降从众效应的影响，在敏捷开发中，咱们能够借助规划扑克来进行匿名投票。在估算会议上，团队中的每位人员都会获得一副纸质扑克，固然，随着移动互联网的普及，目前大多数敏捷团队使用了更为便捷的电子扑克。这里有2张扑克的含义须要解释下：

若是有人出了“☕️”这个扑克，说明须要休息一会了；

若是有人出了“？”这个扑克，说明他不了解需求，没法估算工做量，PO须要尝试从新澄清需求。

同4.2节介绍的案例同样，咱们在规划故事点数时，第一轮你们的估点可能也会有很大的差距。若是估算值差距明显，表明你们对该用户故事的工做量、风险和不肯定性、复杂度没有达成共识，估点高和估点低的人须要给他们一个机会阐述如此估点的理由。你们对该故事所包含的细节达成共识后，再对故事点数进行从新评估，直至你们对故事点数的评估基本达成一致。

若是对于同一个用户故事，估算的故事点数可能不彻底一致，但点数之间差距不大，好比在3和5个故事点之间，该用户故事的故事点能够采用平均值法进行计算，计算方法是将估点的平均值与斐波那契数列相比较，并把与平均值差值较小的故事点做为用户故事的最终点数。

如在A故事的估算中，共有7人参与估算，其中4人估算的故事点数为3，3人评估的故事点数为5，则取平均值后的故事点数为3.85，与斐波那契数列中的3和5比较，平均值与故事点3的差值更小，因此，该用户故事的最终点数为3，该用户故事点数估算完成。

5.4 其余

关于故事点估算还有不少小细节，我大概列一下个人见解，就不详细展开了，各位读者若是有更好的作法，欢迎留言指教：

1）在哪个会议上进行故事点估算？

若是需求梳理会出席的人数较多（达到团队人数的2/3以上），就在梳理会上进行；若是人数较少的话就在计划会前单独召开一个简短的估算会议进行估点。不建议在计划会上估点。

2）估算完成后，能够任意亮牌吗？

不能够，必须一块儿亮牌，而且在估算过程当中，团队成员之间也不能够互相讨论估算的点数。

3）PO和SM参与估算吗？

不参与。只有开发团队参与估点。注意是“开发团队”，它包括了开发和测试人员，而不只仅是开发人员。

4）超过多少点数的用户故事须要从新拆分？

每一个团队的基准故事点规模不同，因此无法给个确切数字，可是建议刚组建的敏捷团队最好不要超过5，后期能够根据团队的反馈进行调整。

5）实际开发中发现了估算失误要不要修改点数？

不要。估算是为了辅助咱们的工做安排，而不是用来管理员工的绩效表现。为了达到精准的估算而耗费过多的时间精力，这是本末倒置。并且就个人经验来看，一个迭代中确实会有一些故事的点数被低估，可是也会有一些被高估的故事，因此就迭代总体来看，故事点不会波动太大。

6）很小的需求，也必需要团队集体估算吗？

要。估点是团队对需求理解对齐的过程。若是需求真的很小，估点的过程也会很快达成一致的，不会耽误你们多少时间。

7）规模化敏捷中的各个团队如何统一估算基线？

首先从各个团队召集一些骨干成员（每一个团队最好能有2-3名），组成一个跨职能的估算团队；而后从整个产品待办列表中随机选择10-20个故事进行基准故事点的定义和估算工做，估算的过程当中若是有人对相关的技术或需求不清晰，能够放弃；最后，参与估算的人，将这10-20个估点后的故事带回本身的团队，并将基准故事和其余故事的估点同步给团队，以此对齐你们对工做量的认识。

参考资料

• 《敏捷革命》，Jeff Sutherland，中信出版集团。
• Why the fibonacci sequence works well for estimating，Mike Cohn。The main benefit of story points，Mike Cohn。
• What are story points，Mike Cohn。
• 韦伯定律，百度百科。
• 黄金比例分割，百度百科。
• 斐波那契数列，百度百科。
• 德尔菲法，百度百科。
• How to Estimate Story Points With Multiple Teams，Mike Cohn。

来源：小船哥说敏捷

做者：小船哥

4月每周四晚8点，【冬哥有话说】DevOps之庖丁解牛，拆解DevOps的工具及具体实战。公众号留言“解牛”可获取地址

• 0401《数据库持续交付流水线分享与演示（Azure DevOps+Flyway）》
• 0408《持续交付中的版本管理与基于Azure DevOps扩展框架的插件开发》
• 时间待定《微服务，多团队协做中的API测试怎么作 - Pact契约测试》
• 0422《BoatHouse端到端流水线展现》