Scrum用户故事与功能相同

Question

在他的帖子What's in a Story中，BDD的创始人Dan North似乎使用了Story这个词代替了一个功能，而这并不是我以前唯一可以互换使用的用户故事/功能的地方。为什么这对我来说特别困惑的是我在一个使用Jira / Greenhopper的团队工作，所以我们用Scrum做看板。 Scrum有自己的术语，用户故事恰好属于该术语集。

所以我的问题是：Feature / UserStory Dan north是否与Scrum中的UserStory相同？

如果不是（修辞）“为什么要这样使用它？”

Answer 1

这可能有争议，但我会考虑将一个功能作为一种分组一个或多个故事的方式。例如，您可能有一个“图像上传”功能，其中包含两个故事：

• 客户可以上传图片
• 管理员可以批准或拒绝并成像

我通常认为“特征”是业务/客户最初如何描述行为。一旦你接近建立它，然后你将它分成故事，以确定优先次序和估计。

Answer 2

我想如果用户故事（或者应该）始终与某个功能紧密相关，那么这是有争议的，反之亦然。

但是，根据定义，用户故事不一个功能。它们是不同的东西。

User story：

  

在软件开发和产品管理中，用户故事是最终用户或系统用户的日常或商业语言中的一个或多个句子，用于捕获用户作为其工作的一部分所做或需要做的事情功能

Software feature：

  

“软件项目的显着特征（例如，性能，可移植性或功能）。”

---

如何描述软件功能真的是开放和模糊的，而不是用户故事。用户故事应该出于某种目的而尊重特定格式：您可以回答 ， ， ，谁和/或为什么在用户故事中（取决于您采用的格式）。

IMO，如果您已经在使用用户故事，那么您不应该为这种关系烦恼，只要确保您的用户故事写得很好。

Answer 3

如果你看一下Scaled Agile Framework，那里的人就把不同类型的文物分开了，包括Epics，Features和Stories。它也在组织内以不同的规模进行映射，这非常酷。

在我的使用中，功能比单个故事更重要，在组织的更高层次上跟踪，并且通常涉及发布计划，用于指示给定版本中的内容。

故事是我们用来描述将使用该功能的场景，以便我们可以构建支持与功能相关的所有故事的功能。