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

2018-08-14 本文已影响2人凌宇哥聊敏捷创新

一、团队改进前概况

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

团队转型前的情况：

项目组开发每三个月后，都需要有3-4周的系统测试；

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

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

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

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

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

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

开发工作不开心（强制的繁冗的流程都要写文档）。

二、团队改进后效果

团队改进历程

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

团队阶段改进成效

平均迭代计划完成率90%以上，1-2个迭代（迭代周期2周）可稳定交付一个版本；

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

迭代千行BUG率<0.9，比改进前提升了25%-30%；

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

三、改进启发

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

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

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

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

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