如何理解「用户故事」

什么是用户故事

用户故事是一个简短而简单的功能描述，它为用户或客户带来价值，并且团队可以在迭代中交付这些功能。

用户故事应该回答三个问题:

• 我们为谁实现它?——期望<用户&gt;的类型
• 我们实现的是什么功能?——我希望<功能&gt;
• 我们为什么要实现它?——<价值，和好处&gt;

所以，用户故事的典型格式是:

作为一个<某种类型用户>，我想要<功能或场景>，以便<得到价值或好处>。

As a , I want to , so that .

例如：作为注册用户，我希望能够将我的照片下载到我的个人资料中，以便其他用户可以看到我的样子。

如何编写用户故事

层级结构

准则

根据INVEST准则，用户故事应为：

• 独立 Independent

  • 不依赖其他故事（这条其实，在现实中，很难实现，因为的确有一些故事依赖前置故事）。

• 可协商 Negotiable

  • 并非一成不变，可以进行讨论。

• 有价值 Valuable

  • 用户故事必须对业务具有明确且可量化的价值。这意味着重构、代码清理、架构设计等这类技术实践不是故事。同时这也意味着故事是一个垂直切片，它不可能是一个单独的前端或后端的任务。

• 可估计的 Estimable

  • 足够清晰，交付团队可以很好地知道它有多大。

• 足够小 Small

  • 用户故事应该不大于一到两个开发人员在一个迭代中实现的工作量。

• 可测试 Testing

  • 用户故事必须对业务具有明确且可量化的价值。这意味着重构、代码清理、架构设计等这类技术实践不是故事。

• 有价值 Testing

我们使用的用户故事模板

故事编写FAQ

Q1:故事是否可以针对不同的端，进行拆分？

A1:如果故事本身涉及到了2个端（即移动端和PC端），如果2个端的故事点较大，且FE为不同的人，可以针对不同的端，进行故事的拆分。

Q1:故事点如果特别大，是否进行拆分？

A1:故事是否拆分的标准是，是否可以交付「用户可见的价值」，和故事点本身无直接关系。

如何进行故事点估算

什么是故事点

故事点是对一个故事的难度和工作量的估计，说白了就是一件工作的工作量的度量。故事点的估计值不是承诺，跟实际完成时间没有直接关系。

故事点的「通货膨胀」

代码质量、开发人员水平、对业务熟悉程度，都会影响交付速度，但是当不同的开发人员，进行故事点估算时，如果以完成时间为标准，就会完成每个人的故事点估算是完全不一样的，这就引起了「通货膨胀」。

计划扑克估算

参考：计划扑克