scrum发布模型,整合了发布、冲刺、用户故事以及任务的关系。

由图中可见,产品的发布时包含了若干个sprint。每个sprint包含若干个用户故事。每个用户故事包含若干个task。

也许对于sprint、用户故事大家都比较熟悉,而task(任务)则相对比较陌生。我们估计例子:对于出行平台中,前台模块“搜索景点”这个用户故事,可以分为前端景点查询、后端逻辑处理等两个任务。具体拆解的粒度由系统的复杂性而定。

一、团队速率估算

弄明白发布模型后,很自然地想到交付这块,而交付很重要一点就是工期。针对很多同学,都是面对新项目和新团队的条件下进行项目的管理。我们就谈一下scrum的影响工期中的团队速率的估算。

1、使用历史数据(同一团队或者其他团队的数据)

这方法主要针对利用同一团队过往项目的开发速率数据进行估算,或者其他团队在类似项目中的速率作为参考。

这方法的好处在同一公司的基础条件下,预估出来的数据大多数情况下浮动空间比较少,即估算出来的值稳定。不过新项目一些特殊条件,可能让“最佳实践”的效果有偏差,这点对于高风险的项目要特别留意。

2、猜猜看

 这种方法,是以当前的项目为基准,进行团队速率的估算。

首先,估计产品列表。

对当前产品列表中的用户故事进行逐个估算故事点。一般都是进行跨职能团队,比如客户、产品、开发、测试等人员联合进行估算,得到认可度比较高的故事点数。如用户故事”搜索景点“,5个故事点。

其次,分解参考故事。

挑选一个用户估算进行分解成任务,让开发团队成员对其进行估算,确定完成的工时。如搜索景点,分为前端搜索,后端数据整合,功能测试等多个任务,估算大概10个工时。

再次,确定估算点数和小时数的大致关系。

如故事点数为5,需要10个小时完成,那么就是每个故事点完成时间为2小时。

然后,确定团队能力。

确定小组成员每周最高和最低的工时。在项目过程中,并不是每个成员都能投入100%到当中,可能中途某个测试人员或者DBA会去完成其他项目的工作。因此估算团队每个成员,最高提供的工时和最低提供的工时数据。得到团队每周最高的服务工时和最低的工时。

建议这数据每个sprint统计一次,时间跨度太大,存在一定变数。

最后,估算团队效率。

按提供的团队能力(每周能提供的工时),以及故事点和小时数之间的关系,得到小组在sprint中的速率。因为组员的在项目中占用的时间、对项目的熟悉程度会发生变化,因此最好能每个sprint估算一次。

3、以后再说

这种方法,其实把前两种方法进行结合。首先利用”猜猜看“的方法,去统计2-3个sprint,然后再用”使用历史数据“方法进行统计该团队的平均速率,为后续的产品发布或者sprint提供针对性更高的参考。

这个方法的好处:利用当前团队在当前项目中积累的原始数据进行分析,适用性更高。

不足的地方:对scrum master前期把控项目进度有不小的挑战。

二、不能如期交付的措施

经过团队速率的估算后,发现无法在指定时间内完成产品列表的要求,这种情况经常会发生。那么我们应该怎样处理呢?一般来说有如下几种措施:

1、选择次要的用户故事推迟发布

比如:每日交易信息统计。这类功能,可以根据其他主要功能进行加工得到的,比如每日交易信息统计,可以通过按天把交易信息导出,然后excel统计也可以得到。2、简化用户故事 如线上支付本身包含微信和支付宝的两种,那可以简化为只有微信一种。

3、增加开发人员 如果是对外的项目,一般协调甲方来认可前面两种方法,有一定的难度。甚至强势的甲方就没有给你商量的余地。这点可能我们换一种思维来考虑就容易自我消化,因为这个发布是甲方接口人的领导所重视的,甚至决定这个对接人的kpi或者部门的kpi,最严重的是,搞不定可能这个人就要滚蛋。

增加开发人员,加班加点赶工期就是一个常规的做法了。不过要注意项目人数不能太多,周期不能太长。不然会影响到团队沟通的效率以及其他项目的进度。  

精彩内容

评论可见,请评论后查看内容,谢谢!!!
 您阅读本篇文章共花了: