敏捷开发中，User Stories最佳实践

关注

翻译最新推荐文章于 2026-06-26 11:24:34 发布 991 阅读 AI 写同款· GEO 优化 ›

【软考】敏捷开发领域中Epic和UserStory之间的区别在敏捷开发领域中，Epic和UserStory是两个重要的概念，它们之间存在着紧密的关联关系。通过有效地运用Epic和UserStory，开发团队可以更好地组织项目、跟踪进度、评估工作量、制定发布计划，从而提升项目的整体效率和质量。本文将深入探讨这些关联关系，并阐述如何在敏捷开发过程中有效地运用Epic和UserStory。阅读详情

在本文中，讨论User Stories创建、计划和编写User Stories相关的代码的最佳方式，以及回答一些最常见的问题。

许多团队开始使用“用户故事（User Stories）”这个术语，因为他们转向了敏捷。用户故事是一种收集客户需求的简单而优雅的技术。然而，使用用户故事来构建优秀的软件需要一定的理解和实践。

让我们仔细看看用户故事（User Stories）是什么，以及如何在项目中成功使用这种技术。

什么是用户故事?

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

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

我们为谁实现它?——期望<用户>的类型

我们实现是什么功能?——我希望<功能>

我们为什么要实现它?——<价值，和好处>

在此之后，用户故事的典型格式是：

作为一个<某种类型用户>，我想要<功能>，以便<好处>。

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

有创建用户故事的过程吗?

没有创建用户故事的正式过程。然而，应该遵循一个指导方针来创建一个好的用户故事。它叫做3c，是由极限编程的创始人之一Ron Jeffries提出的。

卡片是用户故事的书面描述。它没有捕获应该构建的所有细节。相反，它是一个提醒，一个必须进行后续沟通的承诺。

对话用于讨论用户故事的细节。它可以通过一些文档来补充。

由用户验收测试来进行确认，以确保用户故事满足用户/客户的验收标准。

如何编写高质量的用户故事

要确保用户故事具有适当的质量，一个好的做法是遵循比尔•韦克(Bill Wake)的“投资”(INVEST)首字母缩写的标准。INVEST还有助于确定用户故事是否被很好地理解并为开发团队开始工作做好了准备。

独立——用户故事不应该依赖于另一个用户故事，因此用户故事可以按照任何顺序开发。

可协商——用户故事的细节在产品所有者和开发团队之间的口头对话中协商。

有价值——用户故事应该为用户/客户带来所需的价值。

可评估——开发团队应该充分理解用户故事，以便对其进行评估。

小的-用户故事应该小到适合在一个迭代（1-3周）中。

可测试性——应该为用户故事编写适当的验收标准，以便对其进行验证。

什么不是用户故事?

让我们坦诚地告诉自己：用户故事的定义必须是从真正业务用户的角度，不可能是“技术用户（开发者本身）故事”，因为在这种情况下，它不会给用户/客户带来直接的价值。尽管如此，当许多团队需要完成诸如代码重构之类的技术任务时，他们还是喜欢创建用户故事。我建议将其他工作项用于此类任务，并与您的产品所有者就此类工作达成一致，以便他了解为什么有必要这样做。与非功能性需求任务、界面设计任务、复杂的用户交互任务或bug相关。

您可以自由地为这些任务创建其他工作项。例如，约束故事可以用来表示非功能需求。用户故事是捕获产品功能的一种很好的技术，但是我们没有义务将它用于所有目的。

用户是谁?

在编写用户故事之前，应该清楚地了解创建用户故事的用户是谁。有时，新接触用户故事技术的团队会忽略它，他们最终会创建具有不必要功能的软件。所以，做一个适当的用户调查，让所有的用户类型或用户角色或角色写下和描述。可以帮助您实现这一点的两种技术是用户角色建模和角色。

谁负责编写用户故事?

通常，客户代表(如产品所有者)负责用户故事。尽管如此，用户故事并不是高层给团队的规范，而是产品所有者和团队之间的协作技术。这就是为什么如果用户故事是合作编写的更好。一个好的方法是成立一个故事编写研讨会，由团队合作编写。

细节在哪里?

由于用户故事不是规范，所以细节以不同的方式表达:

在用户故事编写的3C原则中，第二个C是对话（Conversation）。会话是敏捷最重要的方面之一。因此，大部分细节都是通过客户代表和开发团队之间的口头交流来传达的。

第三个“C”是确认（ Confirmation）。用户验收测试是确认用户故事满足用户/客户的验收标准，并作为正式的文档细节。BDD(行为驱动开发)是编写验收测试的一种很好的技术。

如果需要，一些用户故事可能包含额外的书面细节。

如何知道用户故事何时完成?

使用已“完成”技术的定义。简单地说，Done的定义是团队成员之间对完成工作的意义的共同理解。完成的定义通常以活动检查表的形式创建，该检查表展示了商定的价值(满足用户接受标准的用户接受测试)和质量(满足质量标准的用户接受测试)。