破石计划 -如何应用MFQ&PPDCS进行需求开发

发表于三月 2, 2018

一、破题

理解本文的主、副标题,需要先解释三个词语:“需求开发”、“破石”、“MFQ&PPDCS”。

 

1. 需求开发

 

仅据我目前的认知,需求开发大体包含产生需求和分析需求两大块。

 

输入可能是来自用户的原始的、粗糙的想法;

经过需求开发,项目各个职能的人共同努力(cross-functional team),理解需求、挖掘需求、探索需求、学习需求、分析需求,这是一个高度探索性的Discovery之旅;

输出是比较明确具体的、可以拿来进行软件构建和测试(build and test)的需求。

 

本文就是围绕这段需求开发之旅展开探讨的,因为我相信:

  • 参与这段旅程的人员,不仅仅应该包含代表用户的群体(User Community),他们更理解用户以及用户的需求,这包括但不限于用户、项目干系人、Business AnalystProduct OwnerUX designer等;

  • 还应该包括软件的实施人员,他们负责开发、集成、和测试软件。

 

也就是说,“理解问题(Problem)的人”与“解决问题(Solution)的人”应该共同参与到需求开发这段旅程中来

 

本文不包含:

  • 在这段旅程之前的需求收集相关内容,此时还没有形成哪怕是大的粗糙的用户原始需求,仍在识别“问题是什么”,需求还处于更广泛的探索与调研中。也许正在基于Design Thinking的思路进行Empathizing阶段的考察:到用户现场面对面的访谈、收集信息、了解现状;也许是公司的高层正在用《Impact Mapping》的方式讨论大的方向和策略、识别重点用户;也许正在用其他任何的方法开展用户调研。。。总之,这一阶段本文不涉及;

  • 在这段旅程之中或之后的软件设计相关内容,不论是用户交互设计,还是架构设计,或者需求的分解分配、详细设计等等,均不在本文探讨范围之内。但这并不表示,Design相关的内容或技能与Requirements相关的内容与技能完全无关,实际上二者是有很强的耦合关系的,比如在《Adventuresin Experience Design》、《Value Proposition Design》、《System Design Heuristics》这些书中都会提到“识别用户的价值”,而这点将是需求开发阶段着重探讨的内容。只不过我个人对软件设计一无所知,只好不提。

2. 破石

 

 

上图来自《User Story Mapping》(Jeff Patton),这本书给我印象很深刻的一个词就是Rock-Break- 破石。把Stories比喻成Rocks,大大小小的故事就像大大小小的岩石一样。

 

人们学习和了解需求或软件系统,并不缺乏方法,比如《Writing Effective Use Cases》中介绍的用例法、《User Stories Mapping》中介绍的用户故事地图法、还有我之前所在公司推行了一阵子的System Anatomy方法、当然也包括我所提倡的《海盗派测试分析:MFQ&PPDCS》中所述的MFQ&PPDCS法,等等。

 

纵观这些方法会发现,虽然他们的应用目的小有不同,表现形式也多种多样(文本表述、便利贴地图、思维导图、树形结构等等),但在本质上也有共通之处

  • 都需要一个从无到有、循序渐进的学习过程。我们不妨把需要学习和了解的对象(需求、系统、特性等等)称为SUDSystem Under Discussion),那么这个学习了解的过程,可以有两种方式:自上而下(Top-Down)或者自底向上(Bottom-Up,前者以Discovering为目的,对SUD知之甚少,所以从大而模糊出发,层层深入,直到细节,而后者以Organizing为目的,已经了解一些支离破碎的信息,需要不断概括与抽象,以窥全貌。本文探讨的是一个Discovery的需求发现之旅,所以属于前者,而以往测试人员应用MFQ&PPDCS进行测试分析就是以Organizing为目的,属于后者;

  • 这个自上而下的探索需求的过程是一个逐层破石的过程:首先拿到的是一个无比粗糙的需求,像一块很大的岩石,当我们用频繁的交流和分析方法做锤子,击打岩石,将破碎为一些小的岩石,然后捡起每一块小岩石,继续捶打,就会变成更小的岩石,直到成为足够小的石块,也就是我们终于明白将要实现的究竟是什么东西“Exactly what will we build?”,于是可以开启后续的软件构建与测试工作了。

  • 不论是自上而下还是自底向上的方式,对于执行者而言,都是一个不断地信息过滤与提取的过程,我在《海盗派测试分析:MFQ&PPDCS》中使用“Curationand Subtraction Heuristic”来概述这个过程:简单地说,就是执行者需要时刻留意过程中随时涌现出来的New Information,并对其进行快速地处理,提取出那些重要的信息,同时过滤掉不那么重要的信息,并且将提取出的信息进行实时的结构化处理,这是一个信息不断重组的过程,最终执行者会对所有的信息形成一个系统的、结构化的认知。

 

关于上述第二个共通点“逐层破石的过程”,下表采用User Story MappingUse CasesMFQ做了一个粗糙的对比,可以看出除了表现形式不同外,破石的思路还是有很多相似之处的。

 

3. MFQ&PPDCS

 

MFQ&PPDCS是我2008年提出的一个测试人员进行需求分析的框架,《海盗派测试分析:MFQ&PPDCS》的前三章分别阐述了需求分析的三大块:KYMKnow Your Mission)、TCOTesting Coverage Outline)和Modeling(需求建模)(对于没有阅读过本书的人,这里也有些简单的介绍文章:http://www.taixiaomei.com/mfqbook00.phphttp://www.taixiaomei.com/mfqbookb0.php)。

 

由于我个人的职业背景主要来自于软件测试,所以在过去的10年里,MFQ&PPDCS主要在测试人员中推广和使用,他们会用这套框架来学习需求、分析需求,以及据此设计出最终的测试实例。由于绝大部分测试人员还没有做到与其他角色一道自上而下的开发需求(Discovering Requirements),更多的是在“事后”自底向上地、向其他角色请教和了解需求,以便开展测试自身的工作,所以这10MFQ&PPDCS的应用主要以“Organizing Information”为主要目的。

 

其实,MFQ&PPDCS本身只是一种方法、一个做事情的思路,它不仅仅可以应用在测试需求分析中,开发人员完全可以用MFQ&PPDCS进行软件的需求分析,这正是本文-“破石计划”的主要目的,探讨如何应用MFQ&PPDCS进行需求开发。具体来说,主要针对的应用场景是

  • 开发测试融合(而不是开发测试分隔),比较理想的情况是敏捷项目中,一个跨职能的小组End to End一起工作,迭代初期需要快速了解和分析需求,那么可以选择使用MFQ&PPDCS进行“需求开发”,完成层层破石的过程;

  • 开发人员或测试人员,在项目需求阶段有机会介入,无论是瀑布模式还是敏捷模式,那么可以选择使用MFQ&PPDCS一步步地了解需求、分析需求,直到分析到合适的粒度,然后可以各自开展后续的具体实施工作(Build and Test)。


二、破石

破石可以发生多次,层层细化,每个人遇到的具体场景不同,所要解决的问题粒度不同,石块的大小也不同,相同的是:

  • 总会有起始的那块Big Rock1

  • 经过一次或多次反复的锤打而形成的中间态Smaller Rocks2

  • 以及最终在某个粒度停下来不再继续捶打的Much Smaller Rocks3

 

前面提到过,在软件的需求开发中,我们使用的锤子是“不断的讨论+某种方法(这是可选项,USM/UC/MFQ等)”,讨论和交流无疑是最关键的部分,方法充其量仅是个Heuristic,起到辅助和启发的作用:无论是借助于Story还是用Use Case,甚或于用MFQ&PPDCS进行需求分析和建模,使用这些方法本身并不能保证得出大小合适、准确无误的需求;而人在讨论中,借助于各人的知识和经验,能够想到并问出正确的问题,各种想法进行不断地碰撞,这才是确保成功的关键。

 

在《User Story Mapping》中将促成上述三个不同粒度的Rocks的讨论和交流分别称为:Opportunity DiscussionsDiscovery DiscussionsFinal Conversations。由于涉及内容过多,受篇幅所限,下文就以极简地方式描述在这三个不同的讨论交流阶段可以如何使用MFQ&PPDCS,仅供参考。

 

当然,要强调的是,具体操作时,这三个阶段并不是严格地、按顺序执行的瀑布式操作方式,以下介绍的每一个活动都可以根据需要自由跳转,不受阶段的限制。实际上,任何一个高度探索性的活动,都不可能是Waterfall的过程,而是应该强调基于上一次实践的反馈不断学习和调整下一次实践的过程,我称之为Mindful Learning,也叫做PRE,这是一个Practice-Reflection-Explication的往复循环,与《User Story Mapping》里面提到的ValidatedLearning很相似,有关PRE具体如果学习和使用,不在本文范畴。

 

 

1.     Opportunity Discussions

 

在最初的讨论中,需求还比较粗糙,可能仅仅有个idea,可能仅仅是一两句话的描述,顶多算是“白云级需求”,甚至还算不上是“需求”,仅仅是识别出通过软件可以解决的一些“问题”而已,称为“Opportunity”更合适些,讨论的粒度是比较大的Rocks

 

这一阶段重点关注WhoWhy,针对每一个Opportunity Idea,典型的问题有:

  • 谁提出的需求?或者需求的来源?

  • 用户有哪些?(CustomersUsersStakeholders

  • 用于解决用户的那些问题?

  • 用户当前是如何做的?

  • 潜在的使用场景?

  • 预期的使用效果?

  • 预期的收益?

 

然后可以使用合适的方法对这些Opportunities进行优先级排序,比如王小刚老师提出的BBR模型、或者基于ImpactLikelihood二维的产品风险分析(PRA-Product Risk Analysis)。

 

讨论的结论通常有三种:

  • Go - 可以继续讨论下去,进入到下一个阶段

  • Not Go - 认为没有价值继续讨论了,直接扔进垃圾桶

  • Pending - 目前还不确定,可以扔回“Opportunity Backlog”,以后再讨论

 

可以采用很多方法来辅助这一阶段的讨论交流,比如USM中的Output & Outcome modelUC中的User-Goal modelBusiness Canvas(商业画布),Impact Mapping(影响地图)等等。

 

如果采用MFQ&PPDCS的话,就是要做KYM思维导图了,由于这个阶段还比较靠前,所以可以重点只关注KYM中的KYCKnow Your Customer)部分。

 

 

2.     Discovery Discussions

 

这一阶段的输出是Smaller Rocks,如果一定要给这些更小的Rocks命名的话,不妨用“风筝级需求”,即Discovery Discussions大体上是将“白云级需求”细化到了“风筝级需求”的粒度(注:这也是参考了《Writing Effective Use Cases》一书的叫法)。

 

对于结论为GoOpportunities,此时的讨论关注的重点是:

  • 究竟要解决的是什么问题(Problem)?

  • 有哪些可能的解决方案(Solution)?

  • 我们所选的方案是否是ValuableUsableFeasible

 

具体可以有如下四个步骤:

 

  • Who and Why

对决定要继续深入探讨的Opportunities更细致地进行有关Who and Why的讨论,比如可以使用User-Goal model,识别Problem ScopeUsersGoals

 

如果应用KYM,除了更细致地开展KYC,还要开展KYPdKnow Your Product)。

 

  • What

随着对需求有更进一步的讨论和认识,可以画一个TCO进行信息的收集和整理,识别出一些M(有可能是一级、二级、甚至三级节点,有点类似于USM中的Backbone StoryBody Story,只不过二者表现形式不太一样),对What有更多的认识,同时可以留意收集F(功能交互场景)和Q(非功能需求),并记录必要的RisksQuestionsDoubts等。

 

注意,此时应用TCO更多的是基于Discovering Purpose,所以不仅仅是个信息Organizing的过程,头脑风暴、按照用户使用的场景和顺序讨论、从以往的经验中剥离出有用的信息,都是不错的辅助手段。

 

  • Evaluation

当对需求有了一定程度的认识后,就可以着手评估该解决方案是否是ValuableUsable以及Feasible了,也即对Quality Pyramid(参考《Fifty Quick Ideas to Improve Tests》)的上面三层进行评估。

Usable - 从用户角度,产品可用性如何?有哪些主要的可用场景?

Useful - 是否是有价值的(Valuable)产品,只有为用户提供价值的产品才会被用户使用。

Successful - 从商业角度、技术角度看,此方案是否可行?是否值得开发此产品?有哪些约束条件?(Feasible

 

  • Prioritization

Discovery阶段是个思维发散的过程,并不是每一个想法都值得去实施,还需要进行收敛,有必要对这些ideas划分优先级。需要注意的是:一定要先考虑对应需求的OutcomeImpact的优先级,再考虑需求本身的优先级:“Don't prioritize features, prioritize outcomes.

 

就像USM中基于用户故事地图做Slicing得出MVPMinimum Viable Product)一样,使用MFQ&PPDCS,完全可以基于FRAFeature Risk Analysis)二维图做Slicing,切分出高优先级的需求来。

 

与基于Organizing的目的使用FRA不同,基于Discovering的目的使用FRA时,维度Impact考虑的是对用户的影响(Outcome to CustomersImpact to Stakeholders),维度Likelihood考虑的是可行性Feasibility

 

经过一系列的Discovery Discussions,结论也有三种:

Go - 可以继续讨论下去,进入到下一个阶段

Not Go - 认为没有价值继续讨论了,直接扔进垃圾桶

Pending - 还不确定或者优先级比较低,可以先扔回“Product Backlog”,以后再分析

 

3. Final Conversations

 

这个阶段的目标只有一个,通过进一步的讨论和分析,回答一个问题:Exactly what will we build or test

 

主要有两大步骤:

 

  • 将“风筝级需求”细化为“用户目标级需求”,也叫做“海平面需求”。

 

几个粒度接近的概念:

UC中的“用户目标级需求”指的是关于系统功能的一个最短的概述,是主执行者努力使工作得以完成的目标,是进行优先级划分、发布、分组、评估和开发的基础;

USMActivities:“Activities organize a bunch of tasks done by similar people at similar times in order toreach a particular goal.

MFQ中的单功能M:“承担着一定功能,可以单独对其测试的部分。

 

基于TCO可以划分出一系列的MFQ (如果用于测试的目的时,粒度合适的M/F/Q是后续测试设计、测试执行、测试管理的基础,称为TBI-Test Backlog Item),每一个都可以看做是一个用户目标级的需求。

 

针对每一个用户目标级需求,再次应用KYMTCOFRASlicing分析其Who + Why What和划分优先级。

 

这个分析的粒度和内容,有点类似于在每个迭代开始的Story Workshop中,对即将实现的Story进行的讨论和分析,比较细致。

 

  • 然后针对这些“用户目标级需求”进一步分析,达到“子功能级需求”的粒度Much Smaller Rocks)。

 

这其实是针对“用户目标级需求”的What部分更进一步的分析和讨论,常见的做法有:在Story Workshop上对Story进行必要的分解、讨论明确每个Story的验收条件;使用UC的话,写出每个UseCase的主辅场景的各主要步骤;当然,也可以应用“实例化需求”方法对每个Story进一步分析。

 

MFQ&PPDCS中,此时会建议针对每个“用户目标级需求”进一步分解成合适的粒度,然后PPDCS的思路辅助建模(Modeling,基于模型会得出该需求对应的典型的、基本的场景,这些场景是后续软件buildtest的重要参考依据。

 

PPDCS对用户目标级需求建模,也是MFQ&PPDCS区别于其他方法的很重要的一点,以我目前所接触过的开发团队、或者我所阅读过的需求开发方面的书籍而言,都没有涉及这一方面,有可能是我所接触的人员有限的缘故、也有可能是因为Modeling是一项需要专门学习和训练才能掌握的技能,但可以肯定的是:使用Modeling分析用户目标级需求,不仅对测试人员、对开发人员也同样大有裨益,这一点在我之前与个别开发人员进行的小练习、以及组织的线下workshop中都得到了证实。

 

三、补充

  • 在由粗到细的需求开发过程中,SUD的粒度在逐渐变小,是一个逐层破石的过程;

  • MFQ&PPDCS的各种方法和技能(KYM+TCO+Modeling)可以针对不同的SUD的粒度,选择性地应用在破石的任何一个阶段。比如需要的话,也完全可以针对Big Rock应用TCOModeling

  • 相比于各种分析的方法,参与分析的人更重要,因为逐层破石的过程是个Exploratory Discovery Process,强调讨论和交流,强调人的思维和技能。

  • 在破石的各阶段的讨论中,记得不时地玩一下“What About ”Game,去思考一些可选路径、异常处理等问题。顺便说一下,具有逆向思维的测试人员更擅长玩这个游戏。

 

限于本人知识结构及篇幅,仅简要地讨论了一下如何应用MFQ&PPDCS进行需求开发(Discovering Purpose),与以Organizing为目的应用MFQ&PPDCS帮助测试人员分析需求相比,还远不成熟,尚没有机会在实际项目中辅导与应用,一定存在许多错误及不足之处,恳请读者指正。

Comment Box is loading comments...