用户故事的来龙去脉三句话讲得清楚吗？

时间: 2021-07-30 11:06:45 人气: 19 评论: 0

上两篇我们说到Agile框架中的角色(Role)和**议（Ceremonies），这篇我们深度聊一聊敏捷产物（Artefacts）的核心: 用户故事User Story！

概要

用户故事一般由三句话组成，描述了一个用户渴望得到的功能。一个好的用户故事包括三个要素：

用户故事通常按照如下的格式来表达：

英文：

As a <Role>,
I want to <Activity>,
so that <Business Value>.

中文：

作为一个<角色>,
我想要<活动>,
以便于<商业价值>

我们以一个可供外星人和地球人订火箭订票网站举例：

作为一个“火箭订票网站”

我想要“统计每天有多少外星人访问了我的网站”

以便于“我的**助商了解我的网站**给他们带来什么收益。”

在这寥寥三句话，它和传统需求描述有什么区别呢？

有价值（Valuable），是故事的核心要求。

每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们，而且需要让客户意识到这是一个用户故事并不是一个契约而且可以进行协商。

用户故事的每个故事，都**非常清晰的写明为什么目标客户做，帮助开发人员更好的站在客户的角度看问题。

传统需求**直接写明需要什么，对于开发人员来说，更像是知其然，未必知其所以然。

比如：以上火箭订票网站的故事，开发人员**清晰了解到是**助商的需求，价值清晰可见，而非只是告诉客户一个简单的访问数字，假想哪些客户可以用到。

可协商性（Negotiable），是用户故事的另一个特质。用户故事不是合同，而是可以协商讨论。一个用户故事卡**上只是对用户故事的一个简短的描述，不**有太多的细节。为什么这么做呢？

用户故事侧重提出问题，但不一定要在一开始设置的时候提出解决方案。

比如说我们一开始看到统计多少外星人访问网站，目的是为了给**助商提供信息，那么开发人员在数据分析过程中，很可能**发现，外星人星球的分布情况也可以轻松提供，为**助商提供更准确信息。或者者有**助商希望知道客户年龄，那么在统计数据前期，是不是可以调用其他地方的数据。等等。

所以，一个用户故事卡不**带有了太多的细节，来限制和用户的沟通。也就是说，用户故事的解决方案是需求方和开发人员不断沟通思维碰撞逐步产生的。

这与传统的方法往往由BA作为中间人来消化需求，喂给开发人员，有所不同。

用户故事不是不**一步到位，**有一个雏形，然后慢慢形成方案和Acceptance Criteria。

传统方式当然也有沟通，但是需要什么菜基本上是一次性递给开发人员。

关于用户故事，Ron Jeffries用3个C来描述它：

经过交流一个好的故事加上AC很可能是这样的：

作为一个“火箭订票网站”，

我想要“统计每天有多少外星人访问了我的网站”，

以便于“我的**助商了解我的网站**给他们带来什么收益。”

AC：

统计数据包括：

在敏捷的实践的时候，很多需求方都有一个困扰——抛弃了传统需求档案，我们还是需要做前期调研，那么我们什么时候可以开始写故事？

有一个非常有意思的方式——结合敏捷和设计思维。著名咨询公司Gartner把这个结合分成三个阶段：

（图**来源：Gartner）

敏捷是一种优化解决问题的方法，而设计思维是一种发现问题并找出解决方案的方法。它需要对最终用户的高度同情和理解，以及开发新想法，挑战假设和重新定义问题的迭代过程，目标是确定可能不一定明显的替代解决方案。

设计思维主要有5个阶段：

移情：了解人，他们的行为和动机。由于人们通常不明确地知道或无法清楚地表达这些事物，因此通过在上下文中查看用户及其行为来识别模式，提出问题和挑战假设，从而产生理解。
定义：根据组织，目标和最终用户的观点，创建可操作的问题陈述，以定义要解决的正确挑战，以及满足需求的一组需求。
构思：利用诸如头脑风暴，思维导图，素描或创建纸质原型等技术来退后一步，进行广泛应对，并提出最初未设想的更具创新性或影响力的解决方案。
原型：通过展示而不是说出来将想法变为现实;快速创建工作原型，将某些东西放入用户手中，并开始收集真实世界的反馈。
测试：从用户体验中学习，迭代并根据需要重复该过程，直到达到最小可行产品（MVP）。

在这个过程中，我们**慢慢形成解决问题的框架，继而帮助开发阶段拆分故事。