前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >敏捷里的故事点 Story point

敏捷里的故事点 Story point

作者头像
PM吃瓜
发布2023-03-02 19:39:24
1.1K0
发布2023-03-02 19:39:24
举报
文章被收录于专栏:PM吃瓜(公众号)PM吃瓜(公众号)

故事点是敏捷项目管理和开发中的一种抽象的度量单位,用于估计实现一个或多个用户故事的复杂度,它是对工作量的一种描述方式。一个故事点就是一个数字,透过这个数字告诉整个团队用户故事的复杂度。复杂度包括功能的难易程度、风险和花多大的功夫。

传统软件团队使用时间估算工作量,但敏捷团队一般使用故事点来估算软件规模。故事点可使用改良斐波那契数列:0,1⁄2,1,2,3,5,8,13,20,40 或 T 恤尺码:XS,S,M,L,XL 来估算。这种抽象的概念可以帮助团队围绕工作规模做出更好的决策。

  • 为什么有point呢?point存在的目的是什么?Point应该是用来衡量团队效率的,point应该和sprint结合才有意义(按周期衡量团队效率的改进);
  • 使用point,应该先确定一个参照物,比如服务器开发一个接口是1point,其他的story对比这个,差不多是几个points?前端一个列表页面是1个point,那么其他页面相对于列表页面是几个points?只有确定了固定的参照物,才能在多个sprint内估算出当期工作成果的points进行量化。那么也就能看出来团队能力的提升,工作方法改进等带来的敏捷团队的效率整体提升;

故事点包括什么内容

由于故事点数代表了开发用户发故事所需的全部工作量,所以团队的估算必须考虑到影响工作量的所有因素。这可能包括:

  • 要开展的工作的数量
  • 工作的复杂度
  • 要开展的工作中存在的任何风险或不确定性

在用故事点估算时,必须要考虑以上每一个因素。让我们看看每个因素是如何影响故事点的。

故事点和工时的区别

传统软件团队使用工时估算工作量。工时是一种绝对估值的方式,它的估算方法常常会依赖于历史经验信息。

故事点是敏捷研发模式中估算软件规模的方式,是一种相对估值的方式。也就是说针对两个需求,可以估计这个需求比另一个需求更大,但不确定每个需求的准确工作量。

在实际使用中,两种估算方法没有优劣之分,只有适不适合的考量。良好的估算实践有助于团队掌握项目的成本和盈利能力,还有助于团队对要交付的需求规模、优先级以及价值达成共识,从而更好地作出业务决策。

如何让故事点的估算更加有效

在实际敏捷研发过程中,由于业务本身的不确定性、经常会出现的新变化因素,以及个人主观因素等原因,导致估算的点数与最终实际情况出入较大,那么以下几个提高故事点效率的方式希望能启发到你:

  • 让任务相关人都参与到估算中。 了解的信息越发全面,得到的结果也更加成熟。同时估算的过程让团队成员们分享各自的逻辑、经验与假设,也有助于团队的步调协同。
  • 参考之前的实际工作。 在回顾迭代时,也回顾和反思估算的准确性,让下一次的迭代估算更加准确和容易。
  • 选择适合的故事点估算方法。 对于不同类型、规模的项目,所适用的估算方法也不一样。比较受欢迎的估算方法包括:计划扑克(Planning Poker)、T 恤尺寸(T-shirt size)、点投票(Dot Vote)等等。

Scrum扑克牌

这些纸牌表示的意思是:

  1. 0表示喝口水的时间就能完成。
  2. 其他数字是根据和基准故事对比得出的结论。
  3. ?表示复杂度未知,通常需要对用户故事进行讨论或者拆分。
  4. 咖啡表示估算的太久,有点累了,需要休息一下。

原则上,一个好的敏捷团队,不应该为超过8个故事点的用户故事估算,大于等于8个故事点的用户故事应该被拆分为更小的用户故事。而随着时间的推移,T团队中会出现越来越多的基准故事,这些基准故事对应的故事点可能是1,也可能是2,也可能是3。这使得所有人对于新用户故事的估算越来越准确。

当然在实际的工作中,由于每个人实际情况的不同,即使所有人都明白1个故事点意味着什么,依然会为一个用户故事的故事点是2还是5而产生争论。有的人考虑的多,有的人考虑的少,有的知道一些近路,有的人一脸茫然。正确的步骤是这样的:

  1. 所有人先不要说出自己的故事点,而是将对应的纸盘扣在桌子上。
  2. 当所有人的纸牌都扣在桌子上时,大家一起翻开自己的卡牌。
  3. 请估算差异最大的两位成员讨论,各自估算的原因。
  4. 所有人收回纸牌,重复步骤1-4。直到所有人的估算一致为止。

使用这种方式的好处是显而易见的,它能让所有人对这个故事点有一个共识,这意味着,不管谁来完成这个用户故事,那么他是认可这个故事点的。而且它可以有效的避免不假思索的跟风行为,每个人必须对用户故事的复杂度进行思考,才能给出一个相对可靠的故事点,否则就要向所有人进行解释。

使用这种方式也有它的弊端,那就是计划会议非常耗时。在实践中,有的团队将估算的环节放在计划会议之前,而有的团队不借助扑克牌,而是直接通过全员讨论得出一个相对正确的故事点。

参考

https://help.coding.net/docs/collaboration/pattern/scrum/story-points.html

https://zhuanlan.zhihu.com/p/116731391

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2021-08-16,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 PM吃瓜 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 故事点和工时的区别
  • 如何让故事点的估算更加有效
相关产品与服务
项目管理
CODING 项目管理(CODING Project Management,CODING-PM)工具包含迭代管理、需求管理、任务管理、缺陷管理、文件/wiki 等功能,适用于研发团队进行项目管理或敏捷开发实践。结合敏捷研发理念,帮助您对产品进行迭代规划,让每个迭代中的需求、任务、缺陷无障碍沟通流转, 让项目开发过程风险可控,达到可持续性快速迭代。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档