【公众号@ “项目管理研究所” 将会第一时间更新文章并分享《行业分析报告》】
归档于软件项目管理初级学习路线
第六章 软件项目成本计划
《初级学习路线合集 》
前言
大家好,这节我们学习软件项目管理---敏捷估算法既Story point估算方法。
敏捷估算法 敏捷估算思路:- 对高层的估算采用轻量级,快速生成策略,并粗略的估算。
- 对短期估算需要进行详细的估算。
大家知道,敏捷项目的需求采用story进行描述,那么工作量的估算则采用Story point估算方法。
Story point概念为:即故事点,用来度量实现一个Story需要付出的工作量的相对估算。
所以我们关注最后得到的相对估算结果,例如估算 故事A为1个Story Point,故事B为2个Story Point,则B的工作量是A的两倍。
Story Point估算是一个相对估算的过程,需要确定相对的估算标准。
Story point估算-常用的两个标准:这里给出两个常用的标准,第一个是斐波那数列等级标准,第二个是2的N次方等级数列标准。
Story point估算-Fibonacci 七个等级:实践过程当中,我们常以斐波那数列7个等级数列来进行故事点的估算。
七个等级分别为:0、1、2、3、5、8、13
估算过程如下:
- 选取预估为3 story points 的Story
- 将需要预估的story与选取的Story 进行比较,
- 如果两个工作量差不多,设置该story 的story point为3
- 如果工作量略少,则为2story point
- 如果工作量更少,则为1story point
- 如果该story 不需要完成, 则设置为0。
- 同理,如果略多/更多/再多,可以相应的设置为5/8/13。
- 如果该story 超过13 story point,可以认为是Epic,可以再分解。
采取SPM项目为例,其中注册功能预估值为3个Story point,而登录功能比注册功能的工作量略少,所以估计值为2个Story point,而人员管理功能比注册功能略多,所以估计值为5个Story point。
Fast Story Point Estimation(T-Shirt)最后我们介绍一个快速的估算方法。过程如下:
- 每个用户故事(story)被独立打印,贴在墙上。
- 然后在墙上写上斐波那数列1、2、3、5、8 、13、21,并加上一列问号(?)
- 团队人员排成一排
- 要求第一名成员把一个用户故事放到他认为可以正确放置故事点值的那一列上
- 第一名成员做完后 ,排团队成员的最后一个位置
- 下一个团队成员可以挪动已经摆好的用户故事,也可以选择另外的用户故事,把它挪到他认为可以正确放置故事点值的那一列
- 继续这个过程,直到所有用户故事都摆放完毕。
- 在循环这个过程的时候,例如有一个Story6反复被挪动所在的列值,项目经理需要将这个Story移到最上面,以便最后讨论。
- 当大多故事都摆放完毕后,项目经理带领大家来讨论反复挪动的故事应该所在哪一列,如果大家无法达成一致,需要将这个故事点放置在挪动过程中所在过的最高值一列上。
- 对于问号一列的Story需要重新进行估算。
如果团队成员对放置的Story不满意,例如下图是最后的排列结果,问号列下有个story9,暂时无法估算。
接下来就要计算每一列的story个数,并且乘以所在列值,从而得到所有的故事点,如下图所示:通过敏捷-快速估算方法最后得出的结果是95,其中不包括story9工作量。
总结到这里,第六章 第9节敏捷估算法就讲解完毕了!下一节介绍成本预算~
如果您觉得这篇文章有帮助到您的的话不妨点赞支持一下哟~~