如何正确使用故事点预估工作量?

万事ONES
+ 关注
2021-10-21 10:29
485次阅读
在敏捷开发的过程中,研发团队需要对任务工作量进行相对准确的预估,从而科学把控项目进度,确保项目及时落地与交付。「故事点」是敏捷开发中一种有效的度量单位,它以数字的形式呈现,表示完成某个用户故事开发所需要的工作量
与「工时」不同,「故事点」是一个抽象的、相对的值,它包含了对开发任务量、复杂度、风险和不确定性的整体预估。然而,由于每个人/团队的技术水平存在差异,对同一任务的复杂性和风险程度的判断也是不同的,因此每个团队对「故事点」都有自己的标准。一旦团队对「故事点」达成了共识,它能够帮助各个成员在估算工作量时快速达成一致,并有效地衡量团队产能。那么如何正确地对故事点进行预估呢?

选择基准故事,赋值故事点

我们所有人对「1个小时」都有清晰的认知和共识,因为时间是一个绝对值,然而「1个故事点」到底代表多少工作量呢?为了确定故事点的标准,团队需要先找到一个基准故事,该基准故事需包含解决具体用户故事所要完成的标志性任务,例如选择一个包含前端和后端任务,后端有数据信息交互的用户故事作为基准故事,其工作量设为1个故事点,那么其他用户故事则可以基于这一基准故事进行故事点的预估。比如某团队设置基准故事 A 为1个故事点,用户故事 B 的开发任务量、复杂度、风险和不确定性综合预估是基准故事 A 的3倍,那么用户故事 B 的故事点就应该设立为3。
故事点的取值需遵循斐波那契数列数列(1、2、3、5、8、13、21、34...), 为了避免繁琐,更好的体现故事点的差异性和准确性,团队可沿用修正版的斐波那契数列(1、2、3、5、8、13、20、40...)。

运用规划扑克,确定工作量

选择好基准故事之后,团队成员则可以开始对用户故事进行故事点估算。为了保证团队成员对同一用户故事的工作量判断达成一致,在故事点估算会议上,我们通常运用「规划扑克」的方式完成集体估算
对于选定的10-20个待办事项,参会人员集体讨论其功能实现并提出问题,然后每个人对待办事项进行故事点预估,同时亮出扑克。对于同一待办事项,如果大家给出的故事点预估存在了很大的差异,代表大家对它的工作量、风险和不确定性、复杂度没有达成共识,估点高和估点低的人需要给他们一个机会阐述估点的理由。大家对该待办事项所包含的细节达成共识后,再对故事点数进行重新评估,直至大家对故事点数的评估基本达成一致。
如何正确使用故事点预估工作量?

持续磨合,度量团队迭代效率

团队针对故事点的估算是需要不断磨合的,在迭代开发过程中,我们可能会发现故事点的预估出现了偏差,但此时不必急于修改故事点数。经过几次迭代的经验累积,团队会对于故事点的预估更加得心应手。
运用故事点预估工作量,还能够帮助团队度量迭代速率,从而更合理地规划版本发布。例如在多次迭代后,我们发现了团队在一个迭代中可以完成20个故事点,那么一个100个故事点的里程碑版本则预计需要5次迭代。

[免责声明]

原文标题: 如何正确使用故事点预估工作量?

本文由作者原创发布于36氪企服点评;未经许可,禁止转载。

资深作者万事ONES
万事ONES
0
深圳复临科技有限公司
实力厂商
实力厂商
优质服务
优质服务
及时响应
及时响应
立即询价
相关文章
最新文章
查看更多
关注 36氪企服点评 公众号
打开微信扫一扫
为您推送企服点评最新内容
消息通知
咨询入驻
商务合作