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最严重的是搞不定可能这个人就要滚蛋。增加开发人员加班加点赶工期就是一个常规的做法了。不过要注意项目人数不能太多周期不能太长。不然会影响到团队沟通的效率以及其他项目的进度。
