【DevCloud·敏捷智库】如何利用故事点作估算

背景

在某开发团队辅导的次日，一个团队负责人咨询道：“领导常常管我要开发计划，我如何能快速的评估出预计开发完成时间呢，咱们目前用工时估算，我据说过故事点估算，不知道适合吗？”

问题分析

从这个团队负责人那里了解到，领导通常在接到项目大量新需求时会问这个问题。领导须要作到“内心有数”，有一个预计的项目新需求完成时间。加上领导一直作传统的瀑布开发项目，他很是关心项目中远期计划，也就是咱们一般讲的里程碑或关键结点的问题。

团队目前使用敏捷开发方式初期，团队成员自己也对如何更快、更好地作好估算感到困惑，目前纠结是否应该采用故事点估算。

从以上问题分析中能够得出：第一，团队对故事点不了解，须要学习什么是故事点；第二，解决如何快速提供给领导开发计划的问题。

解决措施

解决问题咱们来分两步走。首先解决不熟悉故事点的问题，先给你们介绍一下故事点的定义及特性。而后你们了解一下两层估算即产品待办列表估算和Sprint待办列表估算的简单区别，解决开发计划的问题。

若是有时间，建议能够先看看上篇《如何估算第二篇：利用核心概念理解估算》了解估算的核心概念。而后再来看这篇文章效果更好。这篇文章主要讲故事点。具体的估算方法有没有比较好的实践呢？在《如何估算第四篇：利用2种常见方法作估算》中会介绍几种比较好的估算方法，包括：“计划扑克估算”、“敏捷估算2.0（Agile Estimating 2.0）”等。本篇仍然在为估算作技能储备（磨刀不误砍柴功），即明确什么是故事点。前面文章已经讲过估算的一个核心概念即估算相对大小，这个相对大小咱们用故事点为单位。工时和理想人天相信你们都理解，不作过多解释。在这里着重从故事点的定义、故事点的特性两个方面解释下什么是故事点，而后解决给领导提供计划的问题。

故事点的定义

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

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

故事点的特性说明

是相对单位

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

不等同于工做量估算

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

考虑“完成的定义”

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

以上介绍，有些朋友可能会问：有些团队用工时（单位小时）来估算，不能够吗？上一篇文章末尾提到，有些较成熟的团队，也能够借鉴历史数据和经验，直接应用工时或理想人天估算也并不是不可。

若是必定要推荐工时（或理想人天）和故事点分别在何时应用比较好，那么我通常推荐在作产品待办列表估算时用故事点，而Sprint待办列表估算时用工时（单位是小时）。

缘由很简单，结合最开始团队负责人的问题，其实老板大多对什么时间点能够交付多少需求（用户故事形式体现）感兴趣。最多见的问题是：“这50个需求什么时间能够作完？”很明显，老板并非在问本Sprint能作完多少需求，而是在问项目得有一个预计的时间点或里程碑。换句话说就是，须要对某个时间点能够交付什么样价值作出一个长期一点的预测。若是每一个故事平均15分钟估算，那么50个用户故事估算须要50*15分钟=750分钟=12.5小时。显然估算所须要花费的时间代价比较高，ROI过低。若是采用准确度差很少的故事点估算，则效率会大大提高。前面提到过为何故事点估算容易，这里再也不重复解释。此时建议团队平均3分钟完成一个用户故事的估算，那么估算须要50*3分钟=150分钟=2.5小时。这样根据团队正常速率，就能够预计完成时间，回答老板的问题了。

对于Sprint列表的估算，其目标更多的是要肯定团队本Sprint要完成的工做量，故事点显得有点抽象。团队具体执行时，时间概念上有点困难，而小时数就容易得多。一般Sprint列表项也会比产品待办列表项少得多，因此时间上不会花费太多。另外，就Sprint列表中的工做项而言，它会是更具体的需求，一般会进行任务细化和“完成定义”，进而很清楚如何去作，谁来作。这些因素综合看，以工时（小时）来估算成为优点。

参考附录

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

点击关注，第一时间了解华为云新鲜技术~