什么是用户故事: 定义和概述

用户故事是敏捷方法的一部分。他们将重点从写作转移到谈论需求。每个敏捷用户故事都包含一两句话。最重要的是，它们包括一系列关于特定功能的对话。 

这些用户故事是通过敏捷项目编写的。最好的部分是任何人都可以写一个故事。简而言之，您团队的所有成员都可以在项目结束时编写用户故事的示例。它用于敏捷软件开发领域，尤其是在 Scrum 框架中。想了解更多关于用户故事的信息？然后查看此链接。

在本文结束时，您将找到所有问题的答案，例如什么是用户故事、何时编写以及由谁编写。所以坚持到最后。

 

 

 

什么是用户故事？

用户故事是用日常语言编写的描述，从最终用户的角度解释特定软件的功能或特性。该工具通常用于产品开发或敏捷软件管理。大多数敏捷专家将其描述为产品开发工作的最小单元，它将帮助您为客户提供价值。

编写用户故事的主要目的是了解特定项目如何将价值回馈给最终用户。产品团队通常将开发工作分解为用户故事，而不是产品需求和功能。原因很简单，因为它们是用非正式语言编写的，所以人们很容易理解。通过用户故事，团队将专注于真实的人而不是抽象的特征。

正如您已经了解的那样，大多数用户故事主要由客户或用户编写或为客户或用户编写，以影响正在开发的软件的特性或功能。然而，所有产品团队对用户故事的使用并不相同。在某些情况下，任何人都可以编写用户故事，利益相关者也参与讨论，故事只是根据人物角色编写或编写的。而在其他团队中，项目负责人负责将用户故事制定并组织到产品待办列表中。

用户故事不能替代技术要求、文档或用例。它是建立真正的产品需求并帮助团队实现该目标的起点。

 

为什么是用户故事？

在整个项目生命周期中，随着客户和团队了解有关系统的新细节，需求会发生变化。团队通常不只是创建一个需求列表，完成它，然后交付项目。然而，事实并非如此，最重要的是，这也不现实。当您了解有关系统或产品的新事物时，要求也会发生变化。

敏捷软件开发使用用户故事方法的一个重要原因是，这些故事帮助开发人员与外部世界联系并创建为用户提供价值的产品。如果您的团队想从这种方法中受益，那么他们就会与用户联系并了解他们的痛点和收获领域。简而言之，要交付优质产品，开发团队必须与客户联系并了解他们的情绪和需求。

通过用户故事，可以减少编写长文档所花费的时间。相反，他们可以利用这段时间快速交付高质量的软件，让客户和团队都满意。 

 

 

 

 

用户故事的好处

以下是在敏捷软件开发中使用用户故事方法的一些好处，它们是

  • 其一致且简单的格式可在确定和捕获需求的优先级时节省时间
  • 它让您满意，因为您将能够提供满足客户需求的优质产品 
  • 促进开发团队、最终用户和产品所有者之间的协作
  • 改善团队和用户之间的沟通，从用户那里收到的反馈将帮助他们改进产品
  • 提高参与产品开发的所有各方之间的透明度
  • 帮助开发者更好地理解客户痛点，从而提供合适的解决方案

 

用户故事的特点是什么？

用户故事充当了产品开发人员和用户之间的桥梁。这些用户故事通常写在索引卡上，主要关注最终用户的满意度。这些索引卡由一个或多个句子组成。但仅仅在一两句话中，用户故事就应该以简单的方式捕捉特定功能的原因和内容。这些通常仅限于细节，因为它们是手写在索引卡上的。

在 Scrum 框架中，它通常很小，因为它应该在一个 sprint 中交付并且足够有价值，以便用户可以使用它并提供他们的反馈。 

这是一个好的用户故事的特征

大多数人使用熟悉的敏捷格式编写用户故事，即“作为（最终用户），我想要（要求/目标），为此（收益）”。但这可能并非在所有情况下都适用，很快他们就会发现自己遇到了诸如找到合适的故事大小、范围、复杂性等问题。所以这里是一个好故事的特征，在您的用户故事中实现它们。

 

 

  • 独立的 (Independent) - 您的用户故事不应与概念重叠。当用户故事独立时，处理用户故事变得容易。团队通常会创造性地拆分功能以创建更多独立的故事。 
  • 面议 (Negotiable) - 用户故事的重要特征是它应该是可协商的。它应该捕捉产品的需求，而不是细节。通过这种方式，它为团队提供了协商开发产品的方法和范围的机会。
  • 有价值的 (Valuable) - 编写用户故事的全部目的是了解最终用户的痛点，并为他们提供满足其要求的优质产品。因此，一个好的用户故事应该始终对最终用户有价值。并且只有当您的用户故事回答“为什么”时才有可能。如果您得到了该问题的答案，那么您就可以开发出令人惊叹的产品，以便用户可以使用它并向您提供反馈。通过这种方式，您可以避免创建无法提供价值的故事。
  • 估计 (Estimable) - 如果对团队没有好处，那么编写用户故事的意义何在？一个好的用户故事应该非常清晰，团队应该能够估计交付可测试和可交付功能所需的时间和精力。该估算也将有助于预测交付时间表和预算。 
  • 小的  (Small) - 一个好的用户故事应该很小。因为工作超过一周，那么可能会直接影响功能的交付。如您所知，如果开发延迟，用户的反馈也会延迟。因此，您必须始终记住，您的用户故事应该很小并按时交付给团队。
  • 可测试 (Testable) - 一个好的用户故事应该是可测试的。简而言之，用户或产品所有者必须清楚地了解用户故事，以便他们可以编写和执行测试。你的故事应该是可测试的，如果不是，那么你必须以一种可以测试的方式重新构建。

 

如何写用户故事？ 

在编写用户故事时，您必须考虑一些事项。因此，在编写故事时您必须记住的重要一点是，它应该描述最终状态（要完成的任务或要实现的目标）。当你写作时，你必须确保你的故事清楚地传达了终点。以便您的团队可以轻松跟踪项目的开发。永远记住，你的故事应该包括完成故事中提到的任务所需的所有细节。简单的说，除了写故事，你还要勾勒和划分任务，分配给相关的人。

如果您希望您的用户故事对团队有所帮助，那么您还必须记录您在故事中处理的客户或用户的类型。以防万一，如果您有很多用户，那么为每种类型创建一个故事。根据用户故事映射的概念，您必须考虑您的产品是一系列工作或任务，您的用户将能够在产品的帮助下完成。因此，如果您想清楚地构建开发工作，请将每个步骤写为用户故事。 

为了提高开发能够与客户和市场产生共鸣的产品的机会，您必须首先与他们建立联系。了解他们的优先级，了解他们的情绪，对产品的要求。如果您想编写帮助您的团队的用户故事，请分析从用户的答案中收集的信息。 

你必须记住，如果一个用户故事的时间超过一个冲刺，那么它会延迟你的反馈和交付时间。因此，所有比一个 sprint 花费时间更长的故事都应该分成更小的部分才能有效地工作。

 

 

posted on 2021-11-09 15:27  Lynch_Warren  阅读(3485)  评论(0)  编辑  收藏  举报

导航