故事点是敏捷项目管理和开发中的一种抽象的度量单位,用于估计实现一个或多个用户故事的复杂度,它是对工作量的一种描述方式。一个故事点就是一个数字,透过这个数字告诉整个团队用户故事的复杂度。复杂度包括功能的难易程度、风险和花多大的功夫。
传统软件团队使用时间估算工作量,但敏捷团队一般使用故事点来估算软件规模。故事点可使用改良斐波那契数列:0,1⁄2,1,2,3,5,8,13,20,40 或 T 恤尺码:XS,S,M,L,XL 来估算。这种抽象的概念可以帮助团队围绕工作规模做出更好的决策。
故事点包括什么内容
由于故事点数代表了开发用户发故事所需的全部工作量,所以团队的估算必须考虑到影响工作量的所有因素。这可能包括:
在用故事点估算时,必须要考虑以上每一个因素。让我们看看每个因素是如何影响故事点的。
传统软件团队使用工时估算工作量。工时是一种绝对估值的方式,它的估算方法常常会依赖于历史经验信息。
故事点是敏捷研发模式中估算软件规模的方式,是一种相对估值的方式。也就是说针对两个需求,可以估计这个需求比另一个需求更大,但不确定每个需求的准确工作量。
在实际使用中,两种估算方法没有优劣之分,只有适不适合的考量。良好的估算实践有助于团队掌握项目的成本和盈利能力,还有助于团队对要交付的需求规模、优先级以及价值达成共识,从而更好地作出业务决策。
在实际敏捷研发过程中,由于业务本身的不确定性、经常会出现的新变化因素,以及个人主观因素等原因,导致估算的点数与最终实际情况出入较大,那么以下几个提高故事点效率的方式希望能启发到你:
Scrum扑克牌
这些纸牌表示的意思是:
原则上,一个好的敏捷团队,不应该为超过8个故事点的用户故事估算,大于等于8个故事点的用户故事应该被拆分为更小的用户故事。而随着时间的推移,T团队中会出现越来越多的基准故事,这些基准故事对应的故事点可能是1,也可能是2,也可能是3。这使得所有人对于新用户故事的估算越来越准确。
当然在实际的工作中,由于每个人实际情况的不同,即使所有人都明白1个故事点意味着什么,依然会为一个用户故事的故事点是2还是5而产生争论。有的人考虑的多,有的人考虑的少,有的知道一些近路,有的人一脸茫然。正确的步骤是这样的:
使用这种方式的好处是显而易见的,它能让所有人对这个故事点有一个共识,这意味着,不管谁来完成这个用户故事,那么他是认可这个故事点的。而且它可以有效的避免不假思索的跟风行为,每个人必须对用户故事的复杂度进行思考,才能给出一个相对可靠的故事点,否则就要向所有人进行解释。
使用这种方式也有它的弊端,那就是计划会议非常耗时。在实践中,有的团队将估算的环节放在计划会议之前,而有的团队不借助扑克牌,而是直接通过全员讨论得出一个相对正确的故事点。
参考
https://help.coding.net/docs/collaboration/pattern/scrum/story-points.html
https://zhuanlan.zhihu.com/p/116731391