用户故事拆分与MFQ

这两天在学习用户故事拆分，突然感觉它和MFQ是存在着那么多的相似性，故在此简单谈谈我的感想。

一.思维方式

2015年外部教练邰晓梅在她授课过程中分享了TED的一段脱口秀视频，视频中揭示了成功人士的思维方式，如下图所示：

成功人士在做一件事情的时候总会先思考意义是什么（Why)?其次是如何去做(How)?在这个基础上才去考虑做什么(What)?非成功人士思考方式可能截然相反。

联想到我们的测试设计和故事拆分工作的思维方式何尝不是这样呢？

1.1测试设计的思维方式

新手在做测试设计时会基于对被测系统有限的信息“拍脑袋”直接给出测试测试设计用于，稍好些会套用一些诸如“等价类、边界值…”这样测试设计技术。但这些测试用例是否足够？哪些地方冗余？能否覆盖到用户最关心的功能点？这些都是很难得到保障的。而在现有的敏捷背景下的测试人员/QA越来越提倡的是做缺陷预防，在做测试设计之前先做被测对象和需求相关的信息收集和分析。在这个基础上得到正确的测试策略，甚至通过在需求澄清阶段就提前介入将缺陷直接扼杀在摇篮。

1.2故事拆分活动的思维方式

再来看下故事拆分活动。在需求分析和故事拆分阶段常出现的问题是喜欢用研发的语言去交流需求，一来上就直接从方案出发，特别是在已有系统上做需求尤为明显。比如：“当前我们XXX模块当前的处理流程是什么样的，这个需求就是要增加YYY结构，ZZZ流程”。也就是说通过现有系统能提供什么反推如何去满足用户的需要。而成功的需求工作应该是从用户价值出发，采用用户的思维和语言去考虑和描述，然后才是特性和设计。

二.协作方式

回想一下敏捷模式和传统模式下的研发的协作方式的差异无非就是横向切蛋糕和纵向切蛋糕的差异,如下图所示：

分层的思想随处可见,比如OSI 7层协议和TCP/IP 5层协议。分层的好处就是每层可以专注自己的事情单一职责，避免受其他层的影响，但也由于这个封闭性，每一层获得的上下游信息是是否有限的。现实中很多事情并不是局部最优解全局就是最优解，在越来越讲究协作的今天也很难没有任何依赖仅凭借一个人(或相对小的工作单位)就把一个庞大的事情搞定。正所谓群狼猛于虎。

2.1开发工作的协作方式：

在以往的研发工作的协作方式称作WBS(Work Breakdown Structure)，创建WBS是把项目可交付成果和项目工作分解成较小的，更易于管理的组成部分的过程。WBS是把项目可交付成果和项目工作分解成较小的，更易于管理的组成部分的过程。WBS是把项目可交付成果和项目工作分解成较小的，更易于管理的组成部分的过程。如下图所示：

Created with Raphaël 2.1.0原始需求需求交付方案讨论分解实施

图2.1.1 WBS交付流程

以往的开发工作中，需求分析这块相对比较薄弱，接到原始需求之后直接进入方案讨论，总体方案确定之后横向切蛋糕，将任务分解为上层业务、底层平台来实现，而平台再继续切蛋糕分解到各个子系统分别完成，完成后再进行联调，各个子系统的团队都专注自己的任务而整体上考虑用户价值(WHY)比较少，而蛋糕层与层之间的交流成本却很高。

而在现有的敏捷研发流程是纵向切蛋糕，更加强调完整团队和从用户价值出发。更强化需求管理是保证团队从Why的角度，从用户价值出发去做产品，而完整团队是保证信息顺畅的传递和更好的协作。在敏捷背景下的DOD交付过程大致是这样的，如图2.1.2所示：

Created with Raphaël 2.1.0需求研讨需求分析澄清和故事拆分需求开发需求验收交付

图2.1.2 DOD交付流程

2.2测试工作的协作方式：

传统瀑布模型中测试工作即是横向切蛋糕的过程，分部门分团队进行单元测试->集成测试->系统测试逐层进行，但每一层的测试聚焦在自身有限信息和范围的基础之上，比如单元测试聚焦代码逻辑和流程测试，系统测试基于前端的软件系统测试，但都缺乏对于对于整个交付流程信息完备的了解，虽然进行了分层但单元测试、集成测试、系统测试的覆盖依然会存在重复和遗漏。而敏捷背景下应用MFQ要求QA在前端的需求研讨、需求分析、需求澄清和故事拆、需求开发阶段都要介入。首先要站在用户视角发出自己的声音，为缺陷预防贡献自己的力量。还需要不断收集信息，结构化的整理到KYM中，并作为测试策略、测试设计的依据，如图2.1.2：

需求分析阶段：
TS/QA做KYM，测试方案，反馈问题缺陷预防
故事澄清和拆分：
TS/QA做KYM，TCO，反馈问题缺陷预防
需求开发:
QA更新KYM，TCO信息TCON->TC,自动化用例开发，反馈问题缺陷预防
需求验收：
QA执行手工测试用例，将自动化用例部署到CI，反馈问题缺陷预防

三.语言：

3.1用户故事的描述语言：

在故事卡上我们采用如下格式做用户故事的描述：

As a Role For Value I want to do

这是一种站在用户视角的描述方式，As代表用户角色，用户是谁。For代表的是用户价值，do代表的是用户场景。

3.2 MFQ中TCON的描述语言：

TCON在MFQ框架中的含义是测试条件/测试场景，它的三段式描述如下所示：

GIVEN:用户场景 WHEN:用户行为 THEN:用户期待/价值

它也是一种基于用户视角的描述方式。

我们发现它们的共同点是描述语言基于用户语言，也就是研发和用户采用“统一语言”，统一语言的意义同样是拉近用户和研发的距离，能够更好的沟通。

四.准则:

用户故事的拆分和编写需要满足INVEST准则：

I:Independent 独立：
可以独立交付，避免和其他故事产生依赖。依赖会妨碍优先级的的判定和开发计划的评估。

这一点和MFQ中M单功能的划分类似，在MFQ中M也被认为是可以独立验证的软件功能。但MFQ中是可以存在功能交互的，我们称为F。F功能交互的测试也会比单功能的测试相比M来说难度也更大（更复杂的测试环境，测试人员需要了解的被测对象的领域知识更丰富）。非独立的故事多了是否也会导致测试设计阶段F类型的测试点增多，增加测试难度呢？MayBe….

N:Negotiable 可协商的：
用户故事是可协商可调整的。

现有敏捷实践都主张“拥抱变化”，主张的是与用户沟通和调整而不是通过合同和条款制约。同样MFQ也需要是拥抱变化的，KYM和TCO梳理出来后并不是一成不变的需要根据需求的变化调整，在整个开发过程中当获得更多的信息后也需要进行调整。

V:valuable 有价值的:
用户故事是端到端的要能够体现出用户的价值，不能体现出用户价值的工作可以考虑合并或用任务的方式进行跟踪。

测试中的价值体现在项目”风险”和“价值”。测试是无穷尽的，测试策略、设计和执行都应该向“风险”和“价值”倾斜。

E:Estimatable 可估算:
用户故事要用于迭代计划，只有可估算才能保证团队开发节奏的稳定。故事不可估算的原因可能为领域知识不足、缺乏技术能力无法准确估计故事的工作量，缺乏封闭性。
S:Small 足够小：
故事要足够小，能够在一个迭代内交付。

在MFQ中M也是要求划分为足够小的能够被独立测试的功能单元。但这个大小应该是根据功能的重要程度来决定，它是相对的。从测试策略的角度来说对于一个重要的单功能，我们需要拆分更多小的单功能，对于一个低风险的单功能我们可能不需要再继续进行拆分。

T:Testable:
故事要有明确的验收条件，能够被测试和验收。需要用测去试证明一个故事满足客户的期望。

五.层次

分层细化的思想随处可见，用户故事和MFQ也都应用着这样的思想让需求的交付和测试过程可控。

5.1用户故事的层次

如上图所示用户故事分为迭代内的、发布的，和史诗故事。

5.2MFQ的层次

如上图，在做TCO的时候我们也会将一个大的单功能M进行拆分为M1.1,M1.2…等等。

六.优先级

在故事卡和测试用例中我们都会存在优先级的标识来决定重要程度和执行顺序。用户故事的交付和测试优先级的排定都应该是基于风险和价值的，他们优先级排定都可以用下图来表示：