站长二维码

当前位置:首页 > 科技动态 » 正文

用户故事:需求描述的好帮手

 人参与  2020-09-23 14:41  分类 : 科技动态  点这评论

2020.9.21,老外去参加了语文八级考试,结果泪奔了……
 
试题:请考生写出下面两句话的区别在哪里?
 
1. 冬天:能穿多少穿多少;夏天:能穿多少穿多少。
 
2. 剩女产生的原因有两个,一是都看不上,二是谁都看不上。
 
3. 地铁里听到一个女孩大概是给男朋友打电话:“我已经到西直门了,你快出来往地铁站走。如果你到了,我还没到,你就等着吧。如果我到了,你还没到,你就等着吧。”
 
4. ……
 
老外泪流满面,交白卷,回国!没法学。
 
可以看到,同一句话对于不同的人,不同的情境却表达着不同的意思,尤其是写在书面上的语句,更容易让人摸不着头脑,所以沟通是必要的。对于产品经理,需要准确的表达用户的需求,这就需要和开发人员,和用户进行频繁的沟通。用户故事提供了这样一个方法,让我们能够以卡片的方式,描述一个用户故事,而不是直接拿着一摞厚厚的产品需求文档让开发看。用户故事的方式不仅便于沟通,而且能进一步促进沟通。 
 
老外考试结束后认真反思了一下自己,觉得还是不能轻易放弃自己,并收集了大量往年的考试题目和答案在自己的题库中。2021.6.1,老外本着不抛弃不放弃的精神信心满满地又来参加语文八级考试了,结果又一次泪奔了……考卷的题型更新了……
 
在互联网时代,各类事情都是日新月异,时代在变化,用户需求也在不断变化,可能需求变化的速度比我们需求说明书更新的速度都快,而用户故事修改成本低、调整灵活的优点一下子就凸显了出来。
 
总结一下,用户故事形式简单、便于沟通、修改成本低、调整灵活,这也是为什么我们会选择用户故事。
 
一、用户故事是什么样的形式?
 
先给大家看一下用户故事的常规方式,它是以卡片的形式呈现的,包括正反两面。其中,正面的主要内容有标题,用户故事编号(便于用户故事的统计和定位),用户故事正文(编写具体用户故事),而卡片的反面则展示了用户故事的验收标准(AC)。
 
首先我们可以尝试以用户故事的方式来简单描述我们日常生活。

 
故事一:我,起床,开始美好的一天;
 
故事二:我,吃午饭,补充能量;
 
故事三:我,到公司 开始工作,争取完成当日任务。
 
我们可以将这些用户故事概括为“谁?干了什么?什么目的?”的形式。
 
其中,“谁”是指我们的用户,也就是需求的主人公;“干了什么”定义客户想要做什么(需要,而不是需求);“目的”能帮助开发人员了解“没有说出来”的话,启发“对话”的双方。对应上述形式,在编写用户故事时,我们可以采用“(谁)作为XXX,(干了什么)我想/我能XXX,(目的)从而/以便我能XXX”的模板形式。
 
比如我们的用户是一个大猩猩,它提出一个需要:“作为一个大猩猩,我想/我能飞”,仔细想想,要让大猩猩在天空中翱翔还是挺困难的,对于这个需要,我们发现一时间不知道从哪里下手来满足它的需要。那如果我们了解了它想要飞的目的,我们可以重新编写它的用户故事:“作为一个大猩猩,我想/我能飞,以便我到那棵树上摘香蕉吃”,这时我们会恍然大悟,原来它只是想去到树上摘香蕉吃,那我们是不是可以给它搭个通往树上的梯子呢或者我们直接把它送到树上呢?这时我们是不是就可以更好更精准的满足用户的需要了?
 
二、用户故事的三要素(3C)
 
1.Card:以卡片的方式描述一个事情,因为卡片的大小有限,且移动方便,这就保证了用户故事简洁和便于交流的特点;卡片有正反面:正面写用户故事,反面写验收标准。
 
2.Conversation:简单描述完整的事情,让对话双方快速了解对话内容。
 
3.Confirmation:用户故事的目的是“达成一致”,“完成任务”,因此对话的双方需要有确认的验收方式(验收标准AC)。
 
用户故事应该写出明确的AC,AC解决了对于“完成(Done)”定义不清的问题,团队中各个角色需要对每一个用户故事的“完成”有明确的认识,在验收的时候才不至于扯皮。
 
对于AC的编写应当具备以下几点:
 
假设条件:任何事情的完成都应当有一个具体的情境;
 
触发点:在这个假设条件下,用户做了什么事情;
 
期望结果:定义期望(正确)的结果。
 
同样的,AC的编写也有模板,我们可以使用“(假设条件)假设/给定XXX,(触发点)当XXX,(期望结果)那么XXX”的形式。
 
举个栗子:假定饮水机有“热水”和“冷水”两个按钮,当我点击“热水”按钮,那么热水就自动流出来。
 
三、用户故事的生命周期:提出,整理,验收,消亡
 
用户故事在产生后,通过交流讨论之后会被拆分成一个个具体的用户故事,我们将其称为大的用户故事和小的用户故事,小的用户故事一定是可开发的,不可再分解的。当大的用户故事被拆分为小的用户故事后,那么它的生命周期也就此结束。而当小的用户故事被开发人员开发完成后,小的用户故事生命周期完结。
 
具体来说,用户故事可以划分为三个层次:“主题”用户故事,“大”用户故事,“小”用户故事。
 
如“作为抖音用户,我可以拍摄和发布短视频,记录我的美好生活”,这听起来很简单,但是具体到细节,我们就会发现很多问题:
 
用户需要登录吗?用户通过哪种方式登录呢?如果用户还没有账号,要怎么注册呢?拍摄视频有时长限制吗?可以加滤镜吗?视频拍摄完一定要发布吗?
 
很明显,这个故事太庞大了,我们将这个庞大的故事称为“主题”用户故事,通过对它进行迭代和提炼,我们可以抛弃掉“主题”用户故事,将它所产生的诸多细节问题写成一个更小更具体的用户故事来替代它,这便是一个“主题”用户故事的整个生命周期过程了。
 
对于新的 “大”用户故事,我们可以将它放入新一轮的故事规划迭代中,拆解成更小的用户故事,拆解完成后,“大”用户故事便消亡了,继而开始的是“小”用户故事的诞生。
 
“小”用户故事,是用户故事的最小粒度,有明确的验收标准,它应该是“可开发的”,“不可间断的”。
 
如:作为微信用户,我使用付款码向商家付款,以便我能方便快捷地完成交易。
 
可以想象一下,“向商家付款”的整个过程中一般不会出现其他操作打断我们的用户故事,因此“向商家付款”就是一个合理的“小”用户故事了。随后经过“开发,测试,验收”等一系列操作后,就完成“小”用户故事的整个生命周期,即完成归档。
 
使用故事,我们不必假装可以事先知道并写下所有东西。以客户团队和开发人员的讨论为基础,通过每轮迭代中增加的更多细节,不断改进和精炼我们的需求。
 
以上就是用户故事的基本概念啦,恭喜你,又学习到了一个新的知识点。

本文由them整理

本文标签:

上一篇:UX、UI、PD、用研之间的区别 下一篇:我为什么要辞职去卖肉夹馍?-原文

  • 网友评论
  • 赞助本站

赞助演示站
说点什么吧
  • 全部评论(0
    还没有评论,快来抢沙发吧!

推荐文章

标签列表

小编推荐

    热门文章 | 最新文章 | 随机文章

首页 业界动态好文分享网络营销科技动态文章投稿

Copyright © 2008-2020 them 版权所有 皖ICP备15013088号

全站搜索