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