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

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

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

那什么是用户故事？首先来说用户故事是对需求的细化和切分，既然是细化，就得有一个度，需求的颗粒度需要多少才能称之为用户故事？这就牵扯出和用户故事一起出现的另外一个关键的单词叫史诗故事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），不应该依赖于其他的用户故事。如果用户故事存在依赖性那么就会导致用户故事之间存在着不同的优先级，只有被依赖的用户故事完成才能继续开发依赖的用户故事。一般可以通过组合用户故事或者分割用户故事来减少用户故事间的相互依赖性。

Negotiable：可协商

用户故事不是签订的商业合同contracts，它是由客户或者PO同开发小组的成员共同协商制定的，如果最开始像商业合同一样设定了太多的条条框框和限制就无法更好的沟通及协商，也就不可能划分出既让客户满意，也能让开发认同的好的用户故事。

Valuable：有价值

用户故事必须对于最终的用户是有价值的，因此应该站在用户的角度去编写，描述的是一个一个的feature，而非一个一个的task。

Estimable：可评估

对于一个用户故事的划分需要足够的领域知识，使得在划分i故事之时就能大致了解故事开发的周期，为了减少估算的不确定性，故事本身不能太大。

Small：短小

故事应该尽量的短小，当然也不是说越小越好。短小的故事可以减少划分过程中估算的误差，最好的故事是能够在一个迭代周期之内完成的。如果太大就应该考虑将其拆分为多个粒度更小的用户故事。

Testable：可测试

个人认为这一点在所有的特性中对于用户故事的重要程度最高。首先，如果一个用户故事无法进行测试，那么也就无法判断该故事是否完成。除此之外，对应的验收测试也最好是自动运行的，这样在任何时候都能触发该用户故事的检验。最后，必须在定义了验收测试通过的标准后才能认为故事划分完毕。

关于Testable，有一个较为经典的例子：

As  a user, I want to be able to cancel a reservation so that I can get a refund for the trip not taken.

关于此用户故事前面所提到的几个要素who，what，why都满足，那么验收测试应该如何去做？模拟的应该是实际的真正场景，如：退款是全退还是部分退还；提前多久cancel才是有效的；退还款项如何与用户之间进行确认等等。

按照刚才的假设，做一个真实场景的验收测试用例，通过Given-When-Then的方式来设定：

Given：“我”付款1000RMB预定了一个3周后从成都飞往三亚的航班。

When：在航班起飞前一周“我”取消了该行程。

Then：“我”应该得到预定机票半价的退款（500RMB）

在对用户故事设定验收测试的条件时候，分别对应：starting state---》event---》final state

任何的user story，在验收测试的时候都必须至少设定一个defaule scenario。

https://blog.csdn.net/rxr1st/article/details/7479472