用户故事是敏捷项目管理的核心实践之一，除了定义、表达“公式”，本文将给大家分享用户故事的价值，比如用户故事在非技术的角度告知研发团队需求背景是什么，让研发团队更轻松的了解用户需求场景、目的、功能预期和实现价值。
用户故事从终端用户的角度概述他们想要实现的功能，其目的是为了阐明这个功能要给客户提供的价值。
我们很容易把用户故事简单地认为是软件需求，但它并不等同于软件需求。 敏捷开发的一个核心理念是以人为本，而用户故事正是以用户为中心的。用户故事站在非技术的角度告知研发团队需求背景是什么，让研发团队更轻松的了解用户需求场景、目的、功能预期和实现价值。
用户故事是敏捷项目管理的核心实践之一，它可以帮助研发团队在日常工作中培养以用户为中心的意识，提高团队协作性和创造性，从而打造出更好的产品。
一、什么是敏捷用户故事
用户故事是敏捷开发中最小的工作单元，它代指的不仅仅是一个功能，而是从用户角度阐述的一个产品目标。它站在用户的角度以通俗易懂的方式描述了软件功能。
用户故事的目的是阐明一个软件功能要传达给客户的特定价值。需要注意的是，“客户”不一定是外部用户，他们还可以是公司内部员工。
在经过团队评审达成一致之前，用户故事通常是简单的几句话，概述了用户需求的预期结果。一旦研发团队把用户故事加入排期之后，就会补充该用户故事相关的需求。
用户故事非常适合敏捷方法，比如 Scrum 和 Kanban 。在 Scrum 敏捷项目中，用户故事会被添加到迭代（Sprint）中，并在迭代中实现。而在 Kanban 中，用户故事会被放入看板的待办栏中，并随着 Kanban 团队工作流进行流动、完成。
用户故事的工作模式可以帮助 Scrum 团队更好地进行工作量评估并完成迭代计划，提高团队目标预估的准确性和团队工作的敏捷度。而在 kanban 模式下，则可以帮助团队了解怎样管理在制品，并进一步完善工作流程。
用户故事也是更大的敏捷框架（史诗和特性）的组成单元。特性是由多个用户故事组成的功能模块，而多个特性构成了史诗。这些更大的框架有助于确保研发团日常工作是朝着正常的目标前进。
二、用户故事能带来哪些优势
对于刚接触敏捷的开发团队来说，用户故事有时似乎是一个额外的步骤：为什么不直接将项目级工作（史诗）分解为一系列步骤来执行呢？这是因为用户故事可以为团队提供了重要的背景，并将任务与这些任务带来的价值联系起来。
用户故事具有许多优势：
- 用户故事以用户为中心：待办任务列表让团队专注于需要完成的任务，但用户故事可以让团队专注于用户真正想解决的问题；
- 用户故事促进团队协作：定义最终目标后，团队可以共同决定如何最好地为用户提供服务并实现该目标；
- 用户故事让解决方案更具创新性：用户故事鼓励团队批判性和创造性地思考如何最好地实现最终目标。
- 用户故事让团队更有动力： 每完成一个用户故事，开发团队都会享受到攻克一个小挑战带来的胜利，从而更有动力。
三、如何使用用户故事
用户故事一般由产品负责人（Product Owner）、产品经理或项目经理撰写和审核，撰写完成后将进入团队的研发流程当中。
在迭代前期或迭代计划会议期间，团队要确定本次迭代要完成哪些用户故事，并讨论每个用户故事场景下的需求和功能。团队在为每个用户故事构建解决方案过程中将激发成员的创意以及学习到其他技术。当研发团队对用户故事的实现方案达成一致，就会在用户故事中补充功能实现相关的需求描述。
迭代计划的另一个常见事项是根据用户故事的复杂度或完成时间进行工作量评估。研发团队一般使用 T 恤尺寸、斐波那契数列或规划扑克牌的方法来估算合适的故事点。用户故事应该被分解成能在一个迭代中完成的大小，因此当团队估算每个故事时，他们要确保分解将超过该完成范围的故事。
四、如何编写用户故事
在编写用户故事时需要考虑以下几点：
- “完成”的定义——当概述完一个用户故事后，一定要定义其完成的标准是什么。
- 概述子任务或任务——确定需要完成哪些特定步骤以及每个步骤的负责人。
- 用户角色——用户是谁？如果有多个用户，则需要考虑编写多个用户故事。
- 有序步骤——给大规模流程的每一个步骤写用户故事。
- 倾听用户声音——与您的用户交谈并从他们的角度来描述问题和需求。当能够从客户那里获取用户故事时，就不用猜测客户需求了。
- 时间——时间是一个敏感的话题。许多研发团队在评估时会忽略用户故事的实际完成时间，只依靠过往的估算经验来评估。用户故事应当在一个迭代中完成，因此应该把那些数周或数月才能完成的用户故事拆分成更小的用户故事，或者应该把它们上升为特性层级。
一旦明确定义了用户故事，请确保团队所有人都能看到它们的进度。
五、用户故事模板和示例
用户故事通常用一个简单的句子来表达，结构如下：
“作为一个[XX角色]，我[想要什么]，[以便达到什么目的]。”
结构分解如下：
- “作为[XX角色]”：我们是为谁实现这个需求？我们不仅要知道用户的职称，还要了解用户角色的特点。研发团队应该对用户角色有一个共同的理解。团队应该尽可能多地采访目标用户，了解他们的工作方式、想法和使用感受，对用户要有同理心。
- “想要什么”：这里我们描述的是用户的意图——而不是他们想使用的功能。用户本质上想达到什么目的？这个描述不用体现功能的实现——如果你描述的是软件功能而不是用户目标，就没有抓住重点了。
- “以便达到什么目的”：用户期望做的这件事符合他们的规划吗？他们想实现的整体效果是什么？需要解决的本质问题是什么？
例如，用户故事的结构可以参考下方：
- 作为小凯，我想邀请我的朋友，以便一起体验这项服务。
- 作为老王，我想整理我的所有工作，以便我对工作更有掌控感。
- 作为项目经理，我希望能够了解项目成员的工作进展，以便更好地汇报我们的成果和不足。
这些表达不是固定的，但是有助于定义用户故事的完成标准。当用户可以精准表达他想要实现的价值时，一个用户故事就诞生了。我们鼓励研发团队根据自身情况规范用户故事的表达结构并在工作中坚持实践。
六、敏捷用户故事入门
用户故事解释了开发团队成员日常工作的目的和内容，表达结构通常为“角色 + 需求 + 目的”。让团队了解他们交付内容的来源用户及其真实目的，可以很大程度上促进研发流程的进展。
可以从下次评估大规模的特性项目（Feature）开始，尝试把特性拆分为一个个具体的用户故事，由研发团队共同协作优化。当把用户故事同步给团队所有成员后，研发团队就可以开始工作了。
这里推荐使用 PingCode 研发管理工具，内置标准的用户故事工作模板，更支持特性、史诗、缺陷、任务等各种工作类型，帮助您的团队快速开启敏捷研发。
