敏捷测试左移-需求实例化实践

编者荐语:

敏捷团队下的测试角色为了尽早介入会参与需求的实例化过程,如何实例化过程,如何在初期从业务到技术都逐步明细名构建验收标准,一线实践值得参考。

以下文章来源于大小眼学敏捷 ,作者大小眼学敏捷

大小眼学敏捷大小眼学敏捷

测试、敏捷、DevOps等相关技术话题讨论交流

工作中经常收到如下需求:

       1、增加一个批量导入的功能

       2、新接入微信支付

       3、系统自动调度订单

       4、红包要绑定指定商品

    

       且需求的到来往往伴随着截止日期,需要在XX天完成。或已经答应XX方,必须在X月X日上线,进行生产使用。于是我们经常:

      1、需求啥都没,没办法进行任务拆解,做不了

      2、等PO梳理完需求输出PRD后,我们进行需求评审后再确定项目计划

      3、PO或DEV经理基于自己理解先做

 

       在以往瀑布模式下还未交付前这段时间,大家都做的很开心。可一旦开启交付,往往发现与用户的真实需求或用户价值不匹配。轻微的进行部分修改或打补丁,严重的除了延误工期还要推倒重来。也就是在这种环境下,我们对于需求的背景,披露的功能,到底谁是用户等更加想弄清楚。

 

什么是用户故事?

 

      用户故事从字面上理解就是从用户的角度讲述功能需求。

     

     用户故事有一个标准格式,如下:

      英文:As a<Role>, I want to <Activity>,so that <Business Value>

      中文:作为一个<角色>,我想要<功能>, 以便于<商业价值>

 

      举几个例子:

      1、作为产品经理,我想要创建需求,以便于进行迭代规划

      2、作为快递员,我想要放快递到快递柜,以便于用户取件

      3、作为会记,我想要创建转账申请,以便于进行转账

      4、作为平台,我想提供微信支付方式,以便于微信支付

 

为什么需要需求实例化?     

 

      实际梳理过程中,我们基本很难一两次就能实现用户故事描述的如此清晰。是因为往往都是产品在进行讲解,而产品本身就带有明显的职能属性。产品普遍对业务比较了解,但对开发知识,测试验证都比较缺乏,所以往往是基于业务流程去讲,而忽略了代码实现逻辑,从而形成了知识的诅咒。

 

       知识的诅咒:一旦我们自己知道某样东西,我们就会发现,很难想象不知道它的时候会是什么样子。

      

       知识的诅咒带来最明显的就是大家都不说“人话”,产品认为大家都懂业务,开发认为大家都懂代码,测试认为大家都懂如何保证质量。这样各自以为对方都能明白自己的意思,结果都不明白,所以出现大量需求重复讲解,代码返工,测试不能反复,需求重做等。这也是为什么我们要基于实例去沟通需求的根本原因。

 

如何需求实例化?

 

       例子2告诉了我们:

       <角色> == 快递员

       <功能> == 快递放到快递柜

       <商业价值> == 用户取件

      1.png

       

      那是不是我们一眼就知道测试用例如何设计了?当然这里说的是比较粗的。那接下来我们如何将这么粗的一句话需求,进一步拆分成可用开发编码实现,测试质量把控的产品?

 

      一般我们是将产品、开发、测试聚在一起对此故事进行梳理、讨论、分析、总结、归纳。如:

      1)快递员放“快递”到丰巢柜时,生成“放件记录”和“支付费用记录”

      2)平台方发送“取货通知”

      3)收件人取快递时生成“取件通知”并更新“放件记录”

 

      这样在看取快递例子是否产品将业务流程梳理并讲述清楚;开发知道如何进行模型设计、抽象,进行开发实现;测试知道如何做用户故事的AC验收标准。

 

      从上述实例化的快递员放件用户取件故事,是否大家发现了两个重要的点?一个是“问题与价值”,另一个是“系统关系”。我们知道了故事中包含的产品业务问题与价值,也看到了开发需要架构设计中的领域、模型分析方向。

 

需求实例化

 

       这里我们分析到了“快递”、“放件记录”、“支付费用记录”、“取货通知”这些需要开发实现的产品功能,也梳理出我们的工作流与业务规则。


1.png


       但这个故事还是太大,对于开发人员和测试人员还是不足以开展对于的工作,只是相对从原始一句话需求到现在稍微清晰了点。

 

       对于用户来说我们需要交付一个产品,那产品必定有系统,所以我们先识别系统信息。从上述分析中得出我们有平台方(快递柜)、快递公司,但往往会忽略用户的快递从哪来的?所以还有系统如:电商网站。

 

      那整个业务流程是否梳理成:

      1、用户在电商网站上购买商品,形成订单;

      2、电商网站使用XX快递进行订单履约;

      3、快递公司从收件开始,到目的地投递放入快递柜,快递柜生成对应“放件记录”和“支付费用记录”,快递柜同步快递信息至快递公司与收件人;

      4、收件人收到“取件通知”,去快递柜进行取件;

      5、快递柜返回取件信息至快递公司,进行“支付费用记录”更新;

      6、快递公司同步订单履约状态至电商网站,进行快递费用结算;

      7、电商网站更新订单状态:已收货,进入订单下一环节:售后流程。


1.png

       需求实例化到这个环节,其实已经可以让开发做代码编写、测试做AC验收用例了。但是在敏捷项目管理中,我还会进行下一步梳理。


       上面的流程图或文字,大家应该梳理出了这个需求是快递公司“放件”领域上的问题,我们对于这个过程中的各种功能及其关系,有了更近一步的脉络了解。那对于我们最终要交付的产品来说,它是如何产生的?软件一般来是由类组成,类组合成一个个的组件,类和组件之间基于依赖关系相互调用,然后部署在服务器上,服务器之间进行通信,从而形成一个完整的产品,而这其实也是我们的软件模型。


       如何做系统架构设计和建模我们不开展,这里需求定位是“快递员放件到快递柜,用户取件”,所以我们暂定自己是快递公司,以前是没有放入过快递柜,且是其他公司的系统。那如果业务流程正好匹配上图,我们需要在履约过程中放件到快递柜这里进行系统的对接,同时对“放件记录”、“支付费用记录”这两个新增的接口进行开发、对接工作。


       若以后我们会对接多个不同公司的快递柜,我们可能会新增接口,以为后续对接做扩展准备。对应的新增接口是否需要新建表,若要建表对应的表结构、字段、字段的类型长度、主外键、索引如何设计,甚至对于数据是同步异步,内部数据调用关系等等这些都可以在当下进行讨论初步确定。


1.png


       做到这里基本上产品、开发、测试,整个研发团队都知道各自与彼此的关注点、交叉点,而这也是我认为一个需求实例化做的比较好的程度。

 

        但需求实例化在我看来还需要结合敏捷研发模式来开展,如在scrum模式实践中对backlog进行需求实例化后进行审核,然后团队一起进行规模评估与任务拆解,接着进行sprint冲刺。然后在kanban上将我们实例化的内容,按泳道或版本进行sprint版本进度跟踪。需求实例化只是第一步,我们要做的是在敏捷模式下高速持续交付高质量用户价值。


本文转自:https://mp.weixin.qq.com/s/H8_jFzGtNoQjDISleE4wpA

求分享转发: 分享到QQ空间 分享给QQ好友

 

 

粤ICP备19116230号
友情链接: 码农藏书阁 天天链