一、 团队改进前概况training.mypm.net
属于工具类软件产品团队,产品属于公司重要产品。团队成员包括需求2人,开发7人,测试4人。项目管理论坛
团队转型前的情况:项目管理者联盟
项目组开发每三个月后,都需要有3-4周的系统测试;pmp.mypm.net
根据项目前期质量需要,迭代开发过程中的质量活动较多,且基本每个环节都需要交付相关文档(需求交底-反交底-详细设计-详细设计评审-编码-自测-代码审查-需求验证-测试-修改Bug);项目管理论坛
迭代评价的过程度量指标较多,每个迭代进行度量指标统计及分析至少需要2h。项目管理者联盟
团队转型之前面临的问题:training.mypm.net
交付周期很难缩短-阶段性的存在3-4周的系统测试来保证质量;club.mypm.net
时间“浪费多”-成员被要求写很多过程文档,过程度量指标数据统计非常多,团队成员感觉不到有价值;blog.mypm.net
迭代的交付主要集中在迭代结束前三天,测试的压力较大,经常出现因为开发的延迟交付导致测试无法在迭代内完成,迭代价值交付率低;blog.mypm.net
开发工作不开心(强制的繁冗的流程都要写文档)。项目管理者联盟
项目管理者联盟
blog.mypm.net
二、 团队改进后效果项目管理者联盟
团队改进历程项目管理者联盟
敏捷转型历时7个月后,团队打造成需求、开发、测试真正意义上的一个整体团队,完成Scrum、用户故事、发布计划的深度实践,用户故事+Scrum研发规则能够顺畅运转。www.mypm.net
团队阶段改进成效项目管理者联盟
平均迭代计划完成率90%以上,1-2个迭代(迭代周期2周)可稳定交付一个版本;www.mypm.net
产品发版周期由15天降到13天,“抢”出一个短迭代;项目管理者联盟
迭代千行BUG率<0.9,比改进前提升了25%-30%;项目管理者联盟
需求用户验证方法基于用户故事的场景式验证,提升了用户的参与度和满意度。PgMp.mypm.net
三、改进启发blog.mypm.net
本次案例是我2016年教练指导的团队,在我开始指导之前,团队已经能够“独立运转”基本的Scrum框架,但是还是遇到了诸多问题,在需求方面更是存在文前的若干问题场景。项目经理博客
后来了解到,在这之前需求人员一直和团队成员保持着一定的距离。2名需求人员属于产品线内的需求部门,而团队(开发+测试)则是单独的。当有需求需要导入时,需求人员拿着需求规格书对团队进行讲解交底,释疑,当团队认为没有问题了,就进入二周周期的迭代。结果,虽然团队的SCRUM框架貌似已经运转的有模有样,但是还存在着这样那样的问题。项目管理者联盟
原因是什么?经过分析,我认为主要有两点,第一,团队对Scrum框架的理解和使用还只是很浅的层次,实际并没有真正领悟敏捷的价值观,尤其是“可工作的软件高于面面俱到的文档”这一条。其次,团队在需求方面,没有使用用户故事方法,还是使用传统的需求规格说明书导入团队。形式上的Scrum团队加上分离的PO再加上非敏捷的需求,导致团队问题多多。项目管理者联盟文章
本文为项目管理者联盟联盟会员原创文章,授权发布,非经同意不得转载!
|