如何理解「用户故事」
目录
什么是用户故事
用户故事是一个简短而简单的功能描述，它为用户或客户带来价值，并且团队可以在迭代中交付这些功能。
用户故事应该回答三个问题:
- 我们为谁实现它?——期望<用户>的类型
- 我们实现的是什么功能?——我希望<功能>
- 我们为什么要实现它?——<价值，和好处>
所以，用户故事的典型格式是:
作为一个<某种类型用户>，我想要<功能或场景>，以便<得到价值或好处>。
As a , I want to , so that .
例如：作为注册用户，我希望能够将我的照片下载到我的个人资料中，以便其他用户可以看到我的样子。
如何编写用户故事
层级结构
准则
根据INVEST准则，用户故事应为：
- 独立 Independent
- 不依赖其他故事（这条其实，在现实中，很难实现，因为的确有一些故事依赖前置故事）。
- 可协商 Negotiable
- 并非一成不变，可以进行讨论。
- 有价值 Valuable
- 用户故事必须对业务具有明确且可量化的价值。这意味着重构、代码清理、架构设计等这类技术实践不是故事。同时这也意味着故事是一个垂直切片，它不可能是一个单独的前端或后端的任务。
- 可估计的 Estimable
- 足够清晰，交付团队可以很好地知道它有多大。
- 足够小 Small
- 用户故事应该不大于一到两个开发人员在一个迭代中实现的工作量。
- 可测试 Testing
- 应该能够提出用户故事的验收测试标准，通过这些测试意味着用户故事已完成。
我们使用的用户故事模板
故事编写FAQ
Q1:故事是否可以针对不同的端，进行拆分？
A1:如果故事本身涉及到了2个端（即移动端和PC端），如果2个端的故事点较大，且FE为不同的人，可以针对不同的端，进行故事的拆分。
Q1:故事点如果特别大，是否进行拆分？
A1:故事是否拆分的标准是，是否可以交付「用户可见的价值」，和故事点本身无直接关系。
如何进行故事点估算
什么是故事点
故事点是对一个故事的难度和工作量的估计，说白了就是一件工作的工作量的度量。故事点的估计值不是承诺，跟实际完成时间没有直接关系。
故事点的「通货膨胀」
代码质量、开发人员水平、对业务熟悉程度，都会影响交付速度，但是当不同的开发人员，进行故事点估算时，如果以完成时间为标准，就会造成每个人的故事点估算是完全不一样的，这就引起了「通货膨胀」。
