在他的文章What's in a Story BDD创始人Dan North似乎使用Story来代替Feature，而且这不是我见过的用户故事/以前可互换使用的功能。为什么这对我来说尤其令人困惑的是，我在一个使用Jira/Greenhopper的团队工作，所以我们使用Scrum来进行看板。 Scrum有它自己的术语，用户故事正好在这个术语集中。Scrum用户故事与功能相同
所以我的问题是：Feature/UserStory Dan North是指与Scrum中的UserStory相同吗？
如果它不是那么（修辞）“为什么这样使用它”？
我想这是有争议的，如果用户故事是（或应该）总是紧密相关的功能，反之亦然。
但是，根据定义，用户故事是而不是的一个功能。他们是不同的东西。
在软件开发和产品管理，用户故事是在一个系统的最终用户或用户的日常或商务语言中的一个或多个句子，抓住什么是用户确实还是需要做他或她的工作职能的一部分。
“一个软件项（例如，性能，便携性，或功能）的一个显着特征。”
这是真正开放和模糊软件功能如何可以被描述，而不是一个用户故事。一个用户故事应该尊重目的的特定格式：可先回答什么，当，其中，谁和/或为什么在用户故事（取决于你认为哪种格式）。
IMO，如果你已经在使用用户故事，你不应该打扰这种关系，只要确保你的用户故事写得很好。
我们一直在撰写用户故事，但由于BDD，我们想要进一步确定我们撰写的故事还支持某些功能。但正如我所说：即使是BDD的创造者似乎也可以互换使用两者。 – 2013-03-06 20:24:35
此外，我同意你提供的链接，我相信一个实际的功能应该是一些简洁的（1-3个字）描述系统或软件级别的功能。在我看来，像“数据持久性”这样的描述性特征。因此，无论我正在处理的是什么业务域对象，如果需要以某种方式持久保存，它们的场景将与数据持久性功能相关联。那个听起来是对的吗？ – 2013-03-06 20:26:38
这可能是争论的焦点，但我会考虑一个功能是分组一个或多个故事的一种方式。例如，你可能有一个特点“图片上传”它由两个故事：
我一般认为这个'特征'就是企业/顾客最初如何描述行为。一旦你接近构建它，然后你将它分解成故事，以便优先考虑和估计。
那么您是否使用用户故事在Kanban板或类似的项目管理工具上显示为您的WIP？ – 2013-03-06 18:46:23
是的，故事应该是工作单位。如果您使用的是时间盒式过程，那么您通常会在每年春季发布多个故事，但它们可能是从不同功能中选取的故事。 – 2013-03-06 19:21:15
这是你所做的一个有趣的陈述。我认为这就是Scrum中的Epics有用或被使用的原因。从我所了解的Scrum Epics聚合用户故事（其中，正如您所说，可能与几个“功能”相关）。 – 2013-03-06 20:29:06
如果你看看Scaled Agile Framework，那里的家伙把各种不同类型的工件放在一起，包括Epics，Features和Stories。它也映射到组织内的不同级别，这非常酷。
在我的使用中，功能比个人故事更大，在组织的更高层次上进行跟踪，并且通常会参与发布计划以指定给定发布中的内容。
故事是我们用来描述该功能将被使用的场景，以便我们可以构建功能以支持与功能相关的所有故事。
我认为这跟我昨天在这篇文章（http://blog.mattwynne.net/2010/10/22/features-user-stories/）中读到的内容相符：“用户故事是一个规划工具。它们存在直到它们被实现，然后它们消失，并被吸收到代码中。“这与您所说的内容有关，因为它确实是实现该功能的场景，但我们需要一些显示包含场景的WIP的方法，这些场景本身代表要执行的功能。 – 2013-03-07 15:24:47
不要迂腐，但最新版本的Scrum指南不提及用户故事。它指的是产品待办事项项目。用户故事是从XP借用的术语。 – 2013-03-07 11:39:36
@DerekDavidsonCSPCSMCSPO无论如何，要迂腐。德里克，你已经为此付出了很大的努力。至于我，我来自XP的商店。我负责更多地了解BDD以及如何与Jira一起使用。所以我正在与我的小三人团队一起进入Scrumban领域。根据你的个人资料，我知道这对纯粹主义者来说可能是不能容忍的）。干杯。 – 2013-03-07 15:40:31
我投票结束这个问题作为题外话，因为它是关于项目管理和词的意思，而不是编程。 – TylerH 2017-11-03 01:33:15