敏捷测试左移-需求实例化实践
编者荐语：
敏捷团队下的测试角色为了尽早介入会参与需求的实例化过程，如何实例化过程，如何在初期从业务到技术都逐步明细名构建验收标准，一线实践值得参考。
以下文章来源于大小眼学敏捷 ，作者大小眼学敏捷
工作中经常收到如下需求：
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）快递员放“快递”到丰巢柜时，生成“放件记录”和“支付费用记录”
2）平台方发送“取货通知”
3）收件人取快递时生成“取件通知”并更新“放件记录”
这样在看取快递例子是否产品将业务流程梳理并讲述清楚；开发知道如何进行模型设计、抽象，进行开发实现；测试知道如何做用户故事的AC验收标准。
从上述实例化的快递员放件用户取件故事，是否大家发现了两个重要的点？一个是“问题与价值”，另一个是“系统关系”。我们知道了故事中包含的产品业务问题与价值，也看到了开发需要架构设计中的领域、模型分析方向。
需求实例化
这里我们分析到了“快递”、“放件记录”、“支付费用记录”、“取货通知”这些需要开发实现的产品功能，也梳理出我们的工作流与业务规则。
但这个故事还是太大，对于开发人员和测试人员还是不足以开展对于的工作，只是相对从原始一句话需求到现在稍微清晰了点。
对于用户来说我们需要交付一个产品，那产品必定有系统，所以我们先识别系统信息。从上述分析中得出我们有平台方（快递柜）、快递公司，但往往会忽略用户的快递从哪来的？所以还有系统如：电商网站。
那整个业务流程是否梳理成：
1、用户在电商网站上购买商品，形成订单；
2、电商网站使用XX快递进行订单履约；
3、快递公司从收件开始，到目的地投递放入快递柜，快递柜生成对应“放件记录”和“支付费用记录”，快递柜同步快递信息至快递公司与收件人；
4、收件人收到“取件通知”，去快递柜进行取件；
5、快递柜返回取件信息至快递公司，进行“支付费用记录”更新；
6、快递公司同步订单履约状态至电商网站，进行快递费用结算；
7、电商网站更新订单状态：已收货，进入订单下一环节：售后流程。
需求实例化到这个环节，其实已经可以让开发做代码编写、测试做AC验收用例了。但是在敏捷项目管理中，我还会进行下一步梳理。
上面的流程图或文字，大家应该梳理出了这个需求是快递公司“放件”领域上的问题，我们对于这个过程中的各种功能及其关系，有了更近一步的脉络了解。那对于我们最终要交付的产品来说，它是如何产生的？软件一般来是由类组成，类组合成一个个的组件，类和组件之间基于依赖关系相互调用，然后部署在服务器上，服务器之间进行通信，从而形成一个完整的产品，而这其实也是我们的软件模型。
如何做系统架构设计和建模我们不开展，这里需求定位是“快递员放件到快递柜，用户取件”，所以我们暂定自己是快递公司，以前是没有放入过快递柜，且是其他公司的系统。那如果业务流程正好匹配上图，我们需要在履约过程中放件到快递柜这里进行系统的对接，同时对“放件记录”、“支付费用记录”这两个新增的接口进行开发、对接工作。
若以后我们会对接多个不同公司的快递柜，我们可能会新增接口，以为后续对接做扩展准备。对应的新增接口是否需要新建表，若要建表对应的表结构、字段、字段的类型长度、主外键、索引如何设计，甚至对于数据是同步异步，内部数据调用关系等等这些都可以在当下进行讨论初步确定。
做到这里基本上产品、开发、测试，整个研发团队都知道各自与彼此的关注点、交叉点，而这也是我认为一个需求实例化做的比较好的程度。
但需求实例化在我看来还需要结合敏捷研发模式来开展，如在scrum模式实践中对backlog进行需求实例化后进行审核，然后团队一起进行规模评估与任务拆解，接着进行sprint冲刺。然后在kanban上将我们实例化的内容，按泳道或版本进行sprint版本进度跟踪。需求实例化只是第一步，我们要做的是在敏捷模式下高速持续交付高质量用户价值。
本文转自：https://mp.weixin.qq.com/s/H8_jFzGtNoQjDISleE4wpA