十招玩转敏捷测试(3):设计篇——敏捷项目中用户故事分析与验收条件设计

用户故事和用户故事的验收条件应该在每轮冲刺正式开始前完成,一般在每轮冲刺开始前的一周,产品负责人应该和敏捷团队一起讲解用户故事,并一起制定用户故事的验收条件。就是完成所谓的 DOD(Defined Of Done),产品负责人和敏捷团队一起定义好的,大家达成一致的用户故事完成条件。这个 DOD 怎么才算完成呢?就是通过了产品负责人的验收,验收条件要事先和敏捷团队商量好,避免敏捷团队和产品负责人的理解不同而产生的分歧。

用户故事该如何切分呢?

首先我们引入一个工作分解方法:工作分解结构(Work BreakDown Structure),简称 WBS。WBS 的基本思想是把工作内容从大到小,从粗到细,从模糊到具体一个层级一个层级的拆分,最终到达可以在工作活动中完成的程度。WBS 中的工作包可以包括一个或多达若干个完成活动需要完成的任务,如图1为工作分解结构。

十招玩转敏捷测试(3):设计篇——敏捷项目中用户故事分析与验收条件设计


图1 工作分解结构


第二个需求分析工具为特性注入分析法

特性注入方法是一种尽量识别项目产品需要提供给用户的价值的方法,识别出的产品特性将会能够为产品提供所需的价值。特性注入法首先由 Chris Matts 提出,并且获得了 BDD(Behavior Driven Development)社区的大力支持。特性注入法中融入了多种 BDD 实践人员在工作中发现的实用技术和方法。特性注入法提供了一个团队工作框架,使得敏捷团队的需求分析工作专注在可以为产品提供真正商业价值的特性上。特性注入法的目标是找寻出可以为利益相关者(stakeholders)为实现业务目标提供最大价值的产品特性集合。它强调了持续与利益相关者沟通的重要性,以便深入探索和扩展探索对需要交付的产品特性的共同理解。特性注入法使用起来简单说可以为三个步骤(如图2所示的特性注入法):

  1. 寻找价值

  2. 注入特性

  3. 现场实例

十招玩转敏捷测试(3):设计篇——敏捷项目中用户故事分析与验收条件设计


图2 特性注入法


介绍了两个敏捷需求分析工具以后,我们接着上文继续讲小明童鞋的故事。

这天早上产品负责人召开了敏捷研发团队讨论会,产品负责人说:“经过市场部门和销售部门的讨论,最终整理出来一些提高销售收入的方法。这些提高销售收入的方面就是一些潜在的需求。需要和大家讨论一下,然后一起把这些需求细化一下。”提高销售收入的方法包括:

  1. 增加常旅客积分积累和使用功能,通过我们公司电子商务网站或相关渠道购买机票的旅客可以积累里程积分。这些积分可以在下次购买机票时使用积分购买机票,也可以设置积分共享,让他(她)的亲友使用自己的积分购买机票。

  2. 增加电子商务网站访问渠道,例如可以通过微信或支付宝平台查询机票,购买机票,查看和共享里程积分。

  3. 为了增加客户的黏着度,新增用户登录积分和信息共享积分,用户登录使用我们电子商务网站越多,积分也越多。用户在我们电子商务网站发表旅行心得或为他人提供帮组信息也可以获取积分。使用积分可以换成里程积分兑换机票。

产品负责人和研发团队在一起讨论了多次,逐渐理清了老板的业务需求,并根据对业务需求的理解理出了下面的产品列表(Product Backlog)。根据产品特性梳理经验,产品特性的颗粒度,我们一般保持在一个冲刺内可以完成交付这样一个工作量,这个工作量包含了完成这个特性所需的全部工作,例如用户故事梳理、编码、测试等。这样做的好处在于可以在冲刺完成时进行产品特性的验收,真正做到敏捷项目要求的 DOD。以下我们以“常旅客积分积累和使用”为例说明如何进行产品特性梳理:


表1 产品列表


产品列表 特性描述
积分积累 用户购买机票可以累积里程分
积分查看 用户可以查看自己的积分和使用情况
积分兑换 用户可以使用自己或亲友的共享积分兑换商品
积分共享 用户可以设置自己的积分与亲友共享

请见图3所示的特性看板:

十招玩转敏捷测试(3):设计篇——敏捷项目中用户故事分析与验收条件设计


图3 特性看板


特性的详细描述请见图4。

十招玩转敏捷测试(3):设计篇——敏捷项目中用户故事分析与验收条件设计


图4 特性描述


在敏捷看板中的产品特性描述方式如下:

特性:积分积累。

特性描述

为了降低购买机票的成本

作为常旅客

我想在购买机票时能够累积里程积分,登录账户可以累积经验积分,以便以后用来兑换机票

产品列表梳理完成后,就要梳理和细化本轮冲刺需要的用户故事(User Story)。一般来说如果您梳理的产品特性足够细,颗粒度足够小也可以转为用户故事。用户故事颗粒度一般保持在1个工作日左右可以完成交付这样一个工作量,用户故事也可以小到1-2个小时内完成。如果刚开始使用敏捷方式梳理需求,无法做到足够小。建议通常不要超过2个工作日。用户故事颗粒度太大不利于验收交付。

以产品列表中的“积分积累”产品特性为例,我们一起梳理一下用户故事。根据小明童鞋的故事中业务部门对老板的需求梳理结果可以知道。用户的积分可以分为里程积分和用户使用电子商务系统的积分,包括通过微信和支付宝等第三方渠道购买机票和登录使用系统的积分。每一个用户故事都是用户将如何使用系统的描述。

例如:购买机票累积积分。

用户故事: 购买机票时累积积分

故事描述

为了能够累积里程积分

作为一位常旅客购买了从北京至上海的机票

我的积分账户中里程积分应该增加对应的里程积分

验收条件

1.用户登录系统购买北京至上海的机票,查看里程积分应该增加13分

2.用户登录系统购买上海至深圳的机票,查看里程积分应该增加15分

3.用户购买了北京至上海的机票,然后进行了退票,里程积分应该减少13分

请见图5所示的产品列表看板和图6所示的用户故事描述:

十招玩转敏捷测试(3):设计篇——敏捷项目中用户故事分析与验收条件设计


图5 产品列表看板


十招玩转敏捷测试(3):设计篇——敏捷项目中用户故事分析与验收条件设计


图6 用户故事描述


有了验收条件,我们就可以真正开始敏捷测试与自动化测试设计了。


GITBOOK: 十招玩转敏捷测试

微信公众号:

十招玩转敏捷测试(3):设计篇——敏捷项目中用户故事分析与验收条件设计