扫码阅读
手机扫码阅读

润物细无声-用户故事+Scrum敏捷实战成功案例

402 2023-08-26

一、 团队改进前概况

       属于工具类软件产品团队,产品属于公司重要产品。团队成员包括需求2人,开发7人,测试4人。

团队转型前的情况:

  1. 项目组开发每三个月后,都需要有3-4周的系统测试;

  2. 根据项目前期质量需要,迭代开发过程中的质量活动较多,且基本每个环节都需要交付相关文档(需求交底-反交底-详细设计-详细设计评审-编码-自测-代码审查-需求验证-测试-修改Bug);

  3. 迭代评价的过程度量指标较多,每个迭代进行度量指标统计及分析至少需要2h。

团队转型之前面临的问题:

  1. 交付周期很难缩短-阶段性的存在3-4周的系统测试来保证质量;

  2. 时间“浪费多”-成员被要求写很多过程文档,过程度量指标数据统计非常多,团队成员感觉不到有价值;

  3. 迭代的交付主要集中在迭代结束前三天,测试的压力较大,经常出现因为开发的延迟交付导致测试无法在迭代内完成,迭代价值交付率低;

  4. 开发工作不开心(强制的繁冗的流程都要写文档)。

二、 团队改进后效果

团队改进历程

      敏捷转型历时7个月后,团队打造成需求、开发、测试真正意义上的一个整体团队,完成Scrum、用户故事、发布计划的深度实践,用户故事+Scrum研发规则能够顺畅运转。

团队阶段改进成效

  1. 平均迭代计划完成率90%以上,1-2个迭代(迭代周期2周)可稳定交付一个版本;

  2. 产品发版周期由15天降到13天,“抢”出一个短迭代;

  3. 迭代千行BUG率

  4. 需求用户验证方法基于用户故事的场景式验证,提升了用户的参与度和满意度。

三、改进启发

       本次案例是我2016年教练指导的团队,在我开始指导之前,团队已经能够“独立运转”基本的Scrum框架,但是还是遇到了诸多问题,在需求方面更是存在文前的若干问题场景。

后来了解到,在这之前需求人员一直和团队成员保持着一定的距离。2名需求人员属于产品线内的需求部门,而团队(开发+测试)则是单独的。当有需求需要导入时,需求人员拿着需求规格书对团队进行讲解交底,释疑,当团队认为没有问题了,就进入二周周期的迭代。结果,虽然团队的SCRUM框架貌似已经运转的有模有样,但是还存在着这样那样的问题。

       原因是什么?经过分析,我认为主要有两点,第一,团队对Scrum框架的理解和使用还只是很浅的层次,实际并没有真正领悟敏捷的价值观,尤其是“可工作的软件高于面面俱到的文档”这一条。其次,团队在需求方面,没有使用用户故事方法,还是使用传统的需求规格说明书导入团队。形式上的Scrum团队加上分离的PO再加上非敏捷的需求,导致团队问题多多。

       为了解决问题,我对2名需求人员(PO)进行了用户故事方法系统化的培训和辅导。

在用户故事编写方面,严格要求PO(2名需求人员)按照用户故事经典三段论的格式进行编写。并有效采用了史诗故事和用户故事两层需求描述的层级。在用户故事验收标准方面,根据产品情况采用了“需求点”的验证方式。


       在用户故事估算方面,采用了计划扑克进行估算,开发与测试同时参与估算,通过估算,大家对需求的理解达成了真正的一致。



           在发布计划方面,采用了时间驱动的发布计划。



       在迭代过程中,当开发认为他已经完成了故事的开发时,会召集PO和测试进行MiniShow,做到了及早用可工作的软件来验证PO\开发\测试的对需求理解是否真正的一致,如果发现彼此的理解存在偏差,会及时进行修正。

       当测试完成后,PO会进行需求的用户验证,因为采用了用户故事方法。用户能够得以场景式的进行功能验证,更容易参与,从而用户的反馈更加保真。

       在团队方面,从PO角色职责的角度,对需求人员进行了多次的点对点辅导。使PO主动打破了职能墙,开始积极参与团队的各项活动中,使需求人员真正成为了团队的PO。

经过一段时间的改进,相关Leader终于意识到过多过程文档编写的弊端,减少了过程文档的要求,降低了团队成员不必要的浪费。

       当2名需求人员成长为成熟的PO,在分享敏捷改进的经验感悟时,她们总结出用户故事的实践价值如下:

  • 便于团队成员内部快捷地达成真正的一致,节省了沟通成本;

  • 便于迭代的精准计划、价值导向的适应性调整,增强了团队成员的目标感;

  • 便于快速稳定交付,提升了团队的效率产能;

  • 便于用户提供业务场景层级的价值反馈,提升了用户验证的质量;

  • 促进团队从关注任务到关注价值的思维转变, 增强了团队整体对产品业务的理解,提升了团队的凝聚力。

想要了解更多,点击 查看原文