scrum发布模型、团队速率计算和不能如期交付的措施

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，最严重的是，搞不定可能这个人就要滚蛋。

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