敏捷故事点与时间

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/OpenandX/article/details/61918635

在Scrum培训中,经常有人问:故事点和时间怎么对应?忘记了那本书上曾经有个大牛举了个例子,把系统中最简单的一个功能时间作为故事基准点,比如一个网站登录功能,从开始到发布大概需要8小时也就是1个人天作为故事点。于是,在很多公司中默认以此为基准点。在之后的敏捷计划会议上直接用时间进行估算,甚至干脆把敏捷扑克中的一个点作为一个小时,反正自己知道这是个1:8的关系。

Mike大叔,曾经就此专门撰文指出:故事点和小时之间不存在等价关系;

或许我们可说,点数是工作量、风险和不确定性的函数,SP=f(E,R,U)。重要的是,点数是关于工作量的估算。风险、不确定性、复杂度、未知因素以及其他相关的事,仅当他们会影响工作量时才应被包含进去。如果某些事确实很复杂,但却不会影响实现特性所花费的时间,那么复杂性就不应该对估算产生影响-这才是故事点。原文参见链接(

https://www.mountaingoatsoftware.com/blog/how-do-story-points-relate-to-hours

在Scrum中故事的作用有如下几点:

1 引起团队和PO之间的讨论,对于一些商业开发来说故事可以最为技术人员和客户沟通的桥梁,自始至终他们可以使用互相理解的语言进行沟通

2 故事是敏捷角色和仪式之间的唯一串联

3 故事能够充分的展示价值

4 相对估算,由于大部分的PO或者互联网中的产品经理并非技术出生,因此很难根据故事来估计绝对规模,事实上即使是开发人员也很难估计准确,但在相对规模上却可以估算的比较精确,至少可以估计。

例如以登录功能为1个故事点,那么搜索功能呢?PO可能会计算页面复杂度是登录的3倍工作量,搜索算法也比登录复杂可能是3倍工作量,那么搜索就是6个故事点,不管如何起码PO能有一个基准。

在这一步中完全没有使用的时间。

接下来如何使用故事点来替换时间做到项目的监控和计划的调整呢?

在一个Sprint计划会议上,绝大多数的团队会把故事拆解为任务,而任务的估算使用的是时间,假如我们选定了20个故事点进行开发,之后把他们拆分为任务并且估计每个任务的时间,再然后Sprint正常进行,每天燃尽图会根据任务进行的情况来更新,伪敏捷的典型方式是燃烧事件或者人天,我甚至在某知名软件里面看到过燃烧小时的机制。时间和人天的燃烧并不能给项目提供任何帮助,在固定迭代人天和工时是固定的,这个迭代差3个人天和5个小时反映不出任何有用信息,敏捷开发是以经验为模型的,我们期望的是上个迭代能给下给迭代提供参考信息,相反我们在上个迭代完成多少故事点(纵坐标为故事点数)却是可以作为参考的。一个长期稳定的团队的故事点一定是如下图所示的,也就是说每个迭代能完成多少故事是可以推算的,基于这种方式我们能看到项目的终点大概在什么地方。


到目前位置时间也没有显示想象中的巨大作用。

最后一个问题,如果我没有基准,那么怎么填满第一个迭代呢?不是还得依靠时间吗?应对第一个迭代一般有两种方式,一是通过分解任务直到填满第一个迭代,这个时候确实会和时间产生关系,但下一个迭代就会以该迭代的完成故事点进行任务规划,从此与时间无关;第二种方式是选取较多的故事点,第二个迭代以第一个迭代完成的故事点作为依据选择故事,有人以历史项目数据为基准进行选择其实也是一样的原理。

其实在整个的敏捷开发过程中,时间真的是无关紧要,所以请忘记时间,使用故事点吧,不仅计划会更精确,而且更具有追溯性。
展开阅读全文

没有更多推荐了,返回首页