划分用户故事（user-story）的原则

最新推荐文章于 2024-09-09 00:05:27 发布

raoxunrong

最新推荐文章于 2024-09-09 00:05:27 发布

阅读量2.8w

点赞数 2

分类专栏：敏捷文章标签：测试敏捷开发 user 敏捷任务

本文链接：https://blog.csdn.net/rxr1st/article/details/7479472

版权

敏捷专栏收录该内容

4 篇文章 0 订阅

订阅专栏

在敏捷开发过程中是通过用户故事来将需求具体化成可以进行迭代开发的一个个现实的可见的开发任务。因此在敏捷软件的开发过程中，用户故事的划分对于迭代和开发起着举足轻重的作用。

用户故事从其名字来看是站在用户的角度所描述的故事，同时也是用户所能看懂的故事，开发人员最容易犯下的一个错误就是站在自己的角度去思考和划分故事，这样就背离了用户故事的初衷。

那什么是用户故事？首先来说用户故事是对需求的细化和切分，既然是细化，就得有一个度，需求的颗粒度需要多少才能称之为用户故事？这就牵扯出和用户故事一起出现的另外一个关键的单词叫史诗故事epic，通俗来说就是大型的故事。Epic有一些自身的特点：如是由许许多多的较大的不确定的需求（large fuzzy requirements）组成；另外epics本身具有更低的优先级，因为你不能直接通过其完成迭代和开发，而是首先需要划分成较小的真正的user-story；除了这两点，epics因为包含了太多的模糊性需求，所以常常混杂了很多不同的特性，而一个特性就是一组可以归为一类的需求，同时对某一特定的用户存在着交互的价值。

在用户故事的划分中有三要素，分别为card，conversation和confirmation。

card 故事描述：通过将故事写在note card上面，除了故事本身的描述之外，还应该包括故事的时间点估计及对应的测试行为等等。

conversation 通过交谈丰富内容：用户故事的具体细节不是某一个开发人员或者PO自己拍着脑袋定义出来的，而需要项目组中的成员与PO或者客户之间沟通得出的。

confirmation 验收测试能够确认故事已经完成：用户故事划分以后是由开发人员通过编码实现，但是不能仅靠开发人员自测确认故事完成，需要的是一系列的验收测试用以保证故事功能的完成及软件按照我们的预期运行。

关于用户的编写原则，有一个通用的模板用以站在用户的角度描述用户所期望得到的功能：

As a role, I want to do something or a piece of functionality, so that achieve some business value or statement of intent.

作为一个角色，通过某项操作，以便能够完成特定的目标。

在这个模板中有三个不同的点，分别为用户角色--who，某项操作--what，完成的目标--why（reason）。

如：作为一个国米的球迷，通过点击官网的最新新闻栏，以便能够实时了解最新的国米动态。

一个良好的User-story的编写应该遵循INVEST原则：

Independent：独立性

用户故事之间应该具有独立性（有点类似于UT中的test case），不应该依赖于其他的用户故事。如果用户故事存在依赖性那么就会导致用户故事之间存在着不同的优先级，只有被依赖的用户故事完成才能继续开发依赖的用户故事。一般可以通过组合用户故事或者分割用户故事来减少用户故事间的相互依赖性。