敏捷开发知多少，用户故事先写好！

Posted 2021-04-25 你好甲方爸爸

不久前，小编和小伙伴们共同参加了公司的敏捷培训。

作为用户体验设计师，小编最感兴趣的莫过于用户故事这个名词了！第一感觉则是与用户体验行业推崇的体验地图有点相似呀，于是小编赶紧去恶补了关于用户故事的相关知识，与大家分享！并且文末还附上学习资料哦！！！

祝同学们开工大吉！！！

1用户故事很重要！

敏捷开发的基础是用户故事，所以用户故事一定是重点中的重点。而用户与开发人员都不一定确定用户故事是什么，所以制定用户故事一定是一个讨论过程，而且随着软件迭代，用户故事是发展的，满足用户故事也是发展的。

用户故事，user story，简单地说，是一种需求方法。它强调的是通过有效、及时的沟通，帮助用户澄清和优化需求，确定这些需求的优先次序以实现按期交付的终极目标。作为乙方，和甲方的出发点其实是一致的，尽快让新产品或新特性上线，基本上6个月，甚至4个月就是一个周期。基于这个出发点，乙方从技术角度，即使与甲方沟通，及时帮助甲方适当增减需求（最终以特性的形式出现），按优先级在既定的期限内实现交付，需要更多时间的新增需求或者变化需求调整到后期的版本升级中实现，如此种种，就显得相当重要。

2什么是用户故事？

用户故事描述了对用户、系统或软件购买者有价值的功能。用户故事由以下三个方面组成：

• 一份书面的故事描述，用来做计划和作为提示。

• 有关故事的对话，用于具体化故事细节。

• 测试，用于表达和编档故事细节且用于确定故事何时完成。

由于用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries（2001）对这三个方面起了非常好的名字：卡片（Card）、对话（Conversation）和确认（Confirmation）。卡片代表客户需求而不是记录需求。

这是对用户故事的最佳诠释：卡片包含故事的文字描述，然而需求细节要在“对话”中获得，并在确认部分得以记录。

故事卡片案例：

正确✅：用户可以在网站上发布简历。

错误❎：这个软件将用C++语言来编程。

3如何编写故事？

想写好用户故事，必须先知道什么样的故事才是好的用户故事。那么，一个优秀的用户故事应该具备以下特点：

独立性

我们要尽量避免故事间的相互依赖。在对故事排列优先级时，或者使用故事做计划时，故事间的项目依赖会导致一些问题。例如，假设客户团队已经选择了一个高优先级的故事，但它对一个低优先级的故事有依赖，这就会出现问题。故事间的依赖也会使得做估计变得更加困难。

对于相互依赖的故事，可以采用以下处理方式：

1）将相互依赖的故事合并为一个故事；

2）考虑其它的划分方法；

3）在故事卡上标明依赖关系。

可讨论的

故事是可以讨论的。它们不是签署好的合同或者软件必须实现的需求。故事卡是功能的简短描述，细节将在客户团队和开发团队的讨论中产生。因为故事卡的作用是提醒客户团队和开发团队在以后要进行关于需求的对话，它并不是具体的需求本事，因而它不需要包含所有的相关细节。然而，如果我们在编写故事的时候已经知道了一些重要的细节，那么应该在故事卡上以注释的形式记录这些细节，如下：
故事卡内容：公司可以用信用卡支付发布工作信息的费用。
备注：接受Visa信用卡、万事达信用卡和美国运通卡，靠拢支持发现卡。

对用户或客户有价值的

故事的编写应当体现对客户或用户的价值。这样使客户能方便地在开发过程中对这些故事排优先级。 保证每个故事对客户或用户有价值的最好方法是让客户来编写故事。

正确案例：
这个应用软件，最多50位用户能使用一个5用户的数据库许可。
所有的错误应以统一的方式呈现给用户并作记录。

错误案例：
所有的数据库连接要通过一个连接池。
所有的错误处理和记录应在一系列公共类中完成。

可估计的

对开发人员来说，能估算故事的大小（至少猜一下），或者是把故事变成可用代码的时间量很重要的。一般有以下3个原因会导致故事不可估计。

1. 开发人员缺少领域知识。
   

2. 开发人员缺少技术知识。

3. 故事太大了。
   
   

如果缺少领域知识导致不可估计，需要和客户沟通，如果缺少专业知识，则可以把故事拆分出一个调研故事，最好将调研故事和原始故事放在不同的迭代中。如果故事太大而不能可靠估计，则可用考虑写一两个史诗故事。

小的

故事的大小很关键，故事太大或太小，都无助于制订计划。使用史诗级故事来开展工作会很困难，因为它们通常包含多个故事。如：在一个旅行预订网站，“一个用户可以计划一次度假”是一个史诗故事。对于任何旅行预订系统，计划一次度假都是非常重要的功能，包括一系列的任务。史诗故事需要分成更小的故事。合适的故事大小最终取决于团队、它的容量及所使用的技术。

如果故事太小，一个比较好的方法通常是将其合并到需要半天或几天完成的故事中。给合并后的故事命名后，就可以同其他故事一样去计划实现它。

太小的故事案例：

· 求职者可以在简历上输入历任工作的日期范围。

· 求职者可以在简历上修改历任工作的日期范围。

合适的故事大小：

· 用户可以修改简历。

可测试的

故事必须是可测试的。成功通过测试可以证明开发人员正确地实现了故事。如果故事不能被测试，开发人员怎么知道他们什么时候才算完成了代码？
无论什么时候， 只要有可能，就要把测试自动化。这意味着完美要争取99%都自动化，而不是10%。

4用户角色建模

在很多项目中，需求分析人员只是从一个角度写用户故事，这样往往容易忽略一些需求（故事），因为有些故事针对的并不是系统的一般用户。以用户为中心的设计和交互设计的规则使我们懂得，在编写故事前识别用户角色和虚构人物（persona）有很多好处！

5搜集故事

Mike Cohn使用“拖网”来描述收集需求的过程，指出：

1、不同大小的网用来捕获不同大小的需求；

2、需求会像鱼一样，会成长，也可能会死亡；

3、不可能捕获到所有的需求。

一些收集需求的方法：
1、用户访谈。要求尽可能访问真实用户，在提问时尽量采用开放式问题和背景无关的问题。
2、问卷调查。反馈太慢，因此不适合作为主要方法，可以作为补充。
3、观察法。有条件的话可以观察用户使用软件的情况。
4、故事编写共组坊。把开发人员、用户、产品客户和其他所有有帮助的人叫到一起，编写故事，要求故事尽量多，不需要注重质量。

注意啦！！！

这里小编就要打广告啦！

如果想更科学的开展用户访谈、问卷调查工作

如果想通过观察法更深入的了解用户

如果想创建属于你的用户角色、用户画像

就来找我们用户研究工程师和你们一起开展研究用户的工作吧！

6优秀用户故事准则

1、从目标故事开始；
2、采用切蛋糕的方式，把大的故事分解；
3、编写封闭的故事；
4、对必须要遵守而不需要直接实现的故事，使用卡片约束；
5、根据实现时间来确定故事规模，越远的故事精确度越低；
6、不要过早涉及用户界面；
7、有些需求并不是故事；
8、在故事里包括用户角色；
9、只为一个用户编写；
10、以主动语态编写；
11、由客户编写；
12、向故事卡编号说“不”；
13、不要忘记意图。

上文所述内容均节选提炼于：

敏捷大师Mike Cohn的软件需求方法圣经

《用户故事与敏捷方法》

小编真诚奉上电子书链接

欢迎各位爱学习的同学们积极下载

链接:

https://pan.baidu.com/s/1eT9SpSu

密码:

6fdq

部分图片 来源网络

图文编辑 MUUX