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

发布于: 2020 年 07 月 22 日

背景



在某开发团队辅导的第二天,一个团队负责人咨询道:“领导经常管我要开发计划,我如何能快速的评估出预计开发完成时间呢,我们目前用工时估算,我听说过故事点估算,不知道适合吗?”



问题分析



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



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



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



解决措施



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



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



故事点的定义



故事点是表述一个用户故事,一项功能或一件工作的整体大小的一种度量单位。当采用故事点估算时,我们为每个待办项分配一个点数。待办项估算结果的原生数据并不重要,我们只关注最后得到的相对估算结果。一个估算值为2的用户故事应该是估算值为1的用户故事的2倍。而它也应该是另一个估算值为3的用户故事的三分之二。团队不要采用100、200、300,而要使用1、2、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].北京:人民邮电出版社。



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



发布于: 2020 年 07 月 22 日 阅读数: 10
用户头像

传送门:https://bbs.huaweicloud.com/ 2020.07.14 加入

华为云开发者社区,提供全面深入的云计算前景分析、丰富的技术干货、程序样例,分享华为云前沿资讯动态,方便开发者快速成长与发展,欢迎提问、互动,多方位了解云计算!

评论

发布
暂无评论
【DevCloud·敏捷智库】如何利用故事点做估算