用户故事与示例和模板

摘要：用户故事是从最终用户角度编写的非正式的软件功能常规说明。其目的在于阐述某个软件功能如何为客户提供价值。

简而言之，人们往往认为用户故事是软件系统要求。但其实不是。

敏捷软件开发的一个关键组件是以人为本，而用户故事则将最终用户置于对话的中心。这些故事使用非技术性语言为开发团队及其工作提供背景信息。阅读用户故事后，团队能够知道他们为什么要构建、他们在构建什么，以及这能创造什么价值。

用户故事是敏捷项目群的核心组成部分之一。它们有助于为日常工作提供一个以用户为中心的框架，从而推动协作、创造和总体上更优的产品。

用户故事是敏捷框架中最小的工作单元。从软件用户角度来看，这是最终目标，而不是功能。

用户故事是从最终用户或客户角度编写的非正式的软件功能常规说明。

用户故事的目的在于阐明一件作品将如何给客户回馈特定的价值。请注意，“客户”不一定是传统意义上的外部最终用户，他们也可以是组织中依赖您团队的内部客户或同事。

用户故事是采用简单语言编写的几句话，用于概述预期的结果，而不会详述细节。日后经团队同意后添加要求。

故事巧妙整合到 Scrum 和看板等敏捷框架中。在 Scrum 中，用户故事添加至冲刺，并在冲刺过程中“燃尽”。看板团队将用户故事提取到他们的待办事项中，并在工作流中运行它们。正是有了用户故事的这种用法，Scrum 团队能够更好地进行估算和冲刺规划，实现更准确的预测和更高的敏捷性。借助故事，看板团队可以了解如何管理进行中的工作 (WIP)，并且进一步完善其工作流。

用户故事也是大型敏捷框架（如长篇故事和计划）的基石。长篇故事是大型的工作项，它们分解成一组故事，而多部长篇故事又构成一项计划。这种大型结构确保开发团队的日常工作（基于故事）为实现内建于长篇故事和计划中的组织目标做出贡献。

了解有关长篇故事和计划的更多信息

对于刚接触敏捷的开发团队来说，用户故事有时看起来像一个额外的步骤。为什么不把大项目（长篇故事）分成一系列步骤，然后继续下去呢？故事为团队提供重要的背景信息，并将任务与它们创造的价值联系起来。

用户故事有许多关键益处：

• 故事聚焦于用户。待办事项清单可以让团队专注于需要完成的任务，而故事集则使团队专注于为真实用户解决问题。
  
• 故事促成协作。确定最终目标后，团队可以共同决定如何为用户提供最好的服务并实现这个目标。
  
• 故事推动创造性解决方案。故事鼓励团队以批判性和创造性的方式思考如何通过最佳的方案来实现最终目标。
  
• 故事创造动力。随着每一故事的演绎，开发团队都会享受一个小挑战和一次小胜利，促进了前进动力。

了解在 Jira 中用户故事是如何运作的

故事写完后，应该整合到您的工作流中。故事通常由产品负责人、产品经理或项目群经理撰写并提交审核。

在冲刺或迭代计划会议期间，团队将决定他们要处理这次冲刺的哪些故事。团队现在讨论每个用户故事所需的要求和功能。这是团队在实施故事当中获得技术和创造力的机会。一旦取得共识，这些要求就会添加到故事中。

在这样的会议中，另一个常见步骤是根据故事的复杂性或完成时间对故事进行评分。团队使用 T 恤尺码、斐波那契数列或 Planning Poker 来做出正确估计。故事篇幅应调整为可在一次冲刺中完成。因此，当团队定义每个故事时，务必要对超过该完成范围的故事进行分解。

在撰写用户故事时，请考虑以下几项：

• “完成”的定义 — 当用户可以完成概述的任务时，通常表示故事已经“完成”，但务必要定义它的具体含义。
  
• 概述子任务或任务 — 确定需要完成的具体步骤，以及每个步骤的负责人。
  
• 用户人物刻画 — 为谁而做？如果有多个最终用户，不妨撰写多个故事。
  
• 有序的步骤 — 为更大流程中的每个步骤撰写一个故事。
  
• 听取反馈 — 与您的用户交流，用他们的语言来采集问题或需求。倘若能从客户那里获得故事，您便无需再对故事做猜测。
  
• 时间 — 时间是一个敏感的话题。许多开发团队完全避免讨论时间，而是依赖于自己的估算框架。既然故事应当要在一次冲刺中完成，如果一个故事可能需要数周或数月才能完成，那就应该分解为几个更小的故事，或者被视为一个独立的长篇故事。
  

明确定义用户故事后，确保它们能为整个团队所见。

用户故事通常用一个简单句子来表述，其结构如下：

“作为 [角色]，我 [想要]，[从而]。”

分解一下：

• “作为 [角色]”：我们在为谁构建这个？我们追求的不是职位，而是这个人的角色。譬如，Max。我们团队应该对 Max 是谁有共同的理解。我们应该已经采访许多的 Max。我们了解这种人的工作方式，以及他们的想法和感受。我们对 Max 感同身受。
• “想要”：这里我们描述的是意图，而不是所用的功能。究竟想要实现什么目标？这句陈述应该不涉及具体实施。如果您描述的是 UI 的任何部分，而不是用户目标，那么您就不得要领了。
• “从而”：想要即刻做某事的愿望如何与大局保持一致？试图实现什么样的总体效益？需要解决什么样的大问题？

例如，用户故事可以这样表述：

• 作为 Max，我想邀请我的朋友，从而能一起享用这项服务。
• 作为 Sascha，我想组织自己的工作，从而能感受到更大的掌控力。
• 作为一名经理，我想要了解同事的进展，从而能更好地报告我们的成功和失败。

此结构不是必需的，但它有助于对“完成”进行定义。当这个人物能够得到想要的价值时，故事就完成了。我们鼓励团队定义自己的结构，然后坚持下去。

用户故事描述开发团队成员日常工作的背景和原因，通常表述为角色 + 需求 + 目的。了解他们的角色，作为团队所交付内容和原因的事实来源，是顺利完成一个流程的关键。

首先评估下一个或迫在眉睫的大型项目（例如长篇故事）。将其分解为几个较小的用户故事，并通过与开发团队合作来加以提炼。一旦您的故事公布出来，让整个团队都能看到，您便准备好上马项目了。