登录 个人注册 企业注册 杂志订阅 | 我的需求 | 下载专区 | English
首页 > 专题 > 敏捷项目管理 > 用户故事入门

用户故事入门

返回>

2019年07月12日    作者:卧寅    来源:微信公众号“第五空间学习中心”

A-A+

  作者介绍:

  卧寅:PMI 《敏捷实践指南》翻译审校,敏捷教练;PMI-ACP、Scrum Master以及DevOps Professional、NPDP等课程的授课讲师;CBAP、PMI-PBA、DevOps Master、CSP等高端商业认证、敏捷证书持有者。


前提


  用户故事是一种需求描述的方式,常见于各种敏捷方法中。


  它彻底改变了需求编写的方式。过去的需求编写,更多是来自于需求人员通过各种方式(包括但不限于用户访谈、问卷、数据分析等)获取需求后,编写成各种不同形式的文档。


  需求文档是经过了需求人员分析、整理后的需求,具有一定的时效性和局限性,随着市场环境的变化,用户的需求是否可以通过需求文档进行满足,就被打上了一个问号。

  

  而用户故事从用户角度来对用户“最终目的”进行描述,而不对“如何达到目的”进行描述,这就使得中间预留一些缓冲地带给研发团队,让研发团队可以就现状进行分析,并在开发时根据现状对用户“最终目的”进行满足。


  在这个过程中,可以将团队的智慧发挥到极致,让团队对“用户最终目的”进行分析,给出不同的方式,以集体的智慧完成需求。


什么是用户故事


  用户故事是针对于用户有价值的功能进行的描述。一般情况下用户故事的格式如下:


  作为<角色>,我需要<功能>,以便于<商业价值>


  在上述的格式中,包含了三个因素Who、What 和 Why。


  Who 描述了最终使用该功能并获得价值的角色,它帮助我们明确了功能使用人的边界,从而将当前用户故事集中在一个固定的范围内容;


  What 描述了需要达到的效果。注意此时是效果,而不是解决方案。换言之,关注点是你最终的目的,而不是解决方案(途径)。最简单的区别就是 “快速找到你需要的商品”是目的,而“使用搜索”是解决方案;


  Why 描述了What的合理性,着眼点是价值,即What 背后的商业逻辑。或者换一个更加粗暴的说法,就是“给Who 所带来的收益”。


  对用户故事还有一种叫3C 原则,具体是:


  Card,包含故事的文字说明


  Conversation,包含了需求细节


  Confirmation,对上述内容进行记录


  从上述对用户故事描述来看,当前我们至少知道用户故事至少有以下几种特点:


  有价值,对用户故事中Who 来说,这个用户故事必须有价值,用户将会因此有所收益。


  用户故事所带来的价值,用户必须可感知——这点极度重要,这近似将所有的技术细节从用户故事中剔除,让我们可以更关注需求本身。


史诗用户故事是什么


  有些书或者论坛上,会将Epic (史诗)当作一种用户故事类型。


  但我不认同用户故事有Epic(史诗)这种特定类型。


  Epic 不是一种类型,而仅仅是一个标签(tag)而已。


  用户故事就是用户故事,只是有些用户故事比较大,如果将这种用户故事完成,将会赋予用户某种能力(Capacity),那么这种用户故事我们就认为其具有Epic 这种标签,仅此而已。


  而且这种认知直接让我对用户故事的INVEST原则(下一次我们会聊到)中某一项有了一些其他看法。


用户故事细节在哪里


  用户故事如果写在看板上,内容是有限的,肯定是不能将各种讨论后的细节写明白的(微雕工艺者表示我不服),那么细节应该在哪里?


  我的回答是:需要存在其他系统中。一般我们会将其存在Jira或者Trello中,存储的内容一般是讨论的最终结果(团队与PO 共同认可)。


  最终结果包含两个部分:


  讨论的细节,包括该用户故事涉及的流程、顺序、以及界面(UI)与交互(UX)等结果;


  验收标准。肯定会有人告诉你,我们将验收测试写在用户故事卡片背后,但实际上由于用户故事的粒度问题,是不能保证100%都能写下的。而且有些验收标准也比较复杂,用户验收测试包含内容太多,这都不适合写在卡片背后。


验收测试是什么


  验收测试是用来验证实现的用户故事是否满足客户需求的测试用例。


  在迭代开始时,开发人员开始编码时,客户或者PO 就随时准备对产品进行验收。而帮助他们进行这个工作过程的工具,就是验收测试。


  验收测试应该越早完成越好,这么做的最大好处是——让开发团队与客户可以尽可能早的,就功能开发做出相同的认知,避免开发人员对客户的要求理解不到位,导致开发的偏离,产生工作量的浪费。

  

  下面是一个针对用户登录写的验收测试:

  用户可以使用正确的用户名、密码登录

  用户可使用手机验证码进行登录

  用户可使用微信扫码登录

  登录失败时,给用户错误提示


  在这个过程中,细心的你可能会发现,我在验收测试中,并没有对“用户名密码错误”、“验证码输入错误”、“微信扫码后不点击授权”等场景进行描述,这是为何?


  在实际验证过程中,验证的实施方是客户或者PO,他们更加关心是“正确的路径”,也就是所谓的Happy Path,而其他出错信息,他们无法穷举,所以该工作一定程度上就由研发团队来补上,从而让客户、PO将精力集中在有价值部分(非Happy Path 一般不产生价值)。

 

写在最后


  用户故事是现在敏捷开发中常见的形式,如何用好用户故事将会直接对敏捷实施能否成功带来巨大影响,所以下面几篇文章中,我们将会从INVEST、用户角色建模、故事验收、故事收集、故事拆分等方面为大家详细讲解用户故事有关的内容,敬请期待。

责任编辑:王兴钊

标签:用户故事
0
版权声明©
本网站所有内容版权归项目管理评论杂志社及相关权利人(本网站的资料提供者)所有,未经项目管理评论杂志社明确书面许可,任何组织及个人不得复制、转载、摘编本网站的内容,也不得在本网站所属的服务器上做镜像或以其他任何方式进行使用。凡未经许可擅自转载,均视为侵权行为,本网站将依法追究其责任。
热点:ppp    新能源    敏捷   
官方新浪微博
关于我们 - 广告服务 - 联系我们 - 诚聘英才 - 隐私声明 - 杂志订阅 - 在线投稿 - 下载专区 - 网站地图
项目管理评论 版权所有
有意与本刊合作者,请与项目管理评论联系。未经项目管理评论书面授权,请勿转载或建立镜像,否则即为侵权。
合作电话:010-58383379 E-mail:pmr@pmreview.com.cn 京ICP证13028000号-3

京公网安备 11010202007990号


PMI, PMP, PMBOK and the PMI logo are registered marks of the Project Management Institute, Inc.

技术支持:原创先锋_北京网站建设