Agile 什么是用户故事，什么不是用户故事？

我在工作中遇到了一个问题，我们刚刚开始使用scrum作为开发团队。我对我们提供的用户故事有一些问题，因为它们似乎不符合我对用户故事的理解

下面是我们为这次冲刺提供的用户故事的一个实际示例：

• 作为一个网站用户，我希望有一个注册页面，以便我可以注册并提供我的详细信息

• 作为商户用户，我希望在注册表上进行验证，以便提供正确的信息。（这与表单验证有关）

• 作为商户用户，我希望在注册时获得支持，以便回答我对所需详细信息的任何问题。（这与表格上的工具提示有关）

我首先想到的是用户故事。后两个似乎是第一个用户故事的传统需求，我认为它们应该是第一个用户故事的接受标准

我遇到的另一个困惑是在上一次冲刺中：

• 作为一个用户，我希望能够登录到该网站

• 作为一个用户，我希望能够登录到一个用户名的网站

产品负责人说这是两个不同的用户案例，需要分别测试

我的问题是，在为后两个创建测试用例和验收标准时，这很困难，因为它们非常具体，并且与第一个用户故事相关。似乎我们只是把传统的需求放在一张卡片上，放在一块板上，然后把它叫做别的东西。我主要是想知道我是否错了/为什么

在我看来，我们目前只是让用户创建他们想要的任何用户故事，而不是帮助他们将需求过滤到适当的用户故事中。有人告诉我，我们需要将它们分开进行报告，这样我们就可以记录用户请求的所有内容

用户故事关注客户价值。。。正在做的实际工作是充实的 通过以用户故事为中心的协作，作为系统 发展进步。。。为了限制范围，用户故事具有 共同制定验收标准，规定 用户故事符合利益相关者的期望。测试用例通常是 作为代码开发（使用测试驱动开发）或作为 代码被开发

[我的重点。]

作为一个用户，我希望能够登录到该网站

作为一个用户，我希望能够登录到一个用户名的网站

由于两者都不提供任何客户价值，因此用户故事也不提供

您使用应用软件来管理信息、做出决策和（最终）采取行动。如果用户故事没有提供一些关于采取什么信息、决策或行动的提示，那么就没有客户价值，这只是技术folderol——客户必须忍受的实现细节，才能进入应用程序的有趣部分

具体来说，登录名的客户价值为零。它在客户和他们做出决策和采取行动所需的宝贵信息之间设置了障碍。这是一种安全机制，大多数人实际上并不喜欢安全。安全性是由IT强加给客户的。最流行的密码（IIRC）是“AAAAA”。为什么？客户不喜欢安全

详细、微观的登录用户故事可能是看不到客户真正价值的征兆

---

在我看来，我们目前只是让用户创建他们想要的任何用户故事

好

有人告诉我，我们需要将它们分开进行报告，这样我们就可以记录用户请求的所有内容

这真是个不错的计划

问题是将“用户碰巧说的废话”与“我们可以构建的有意义的东西”分开。允许用户说出他们想说的任何废话是非常非常重要的。让他们闲逛是件好事

定期（在每次冲刺之前）你会将用户说的废话优先化为几件事：（1）你可能在冲刺期间构建，以及（2）创造你可能创造的最重要和最引人注目的用户价值。有些故事会被忽略。有些将是低优先级的。有些将合并，有些将拆分。用户说的一些事情会相互矛盾。有些将是彻头彻尾的谎言。有些是不完整的。一切都很好。这只是用户碰巧说的废话。不是从神的口中直接向你发出的神圣指令

这组修改后的用户故事推动了sprint。现在，您开始与用户协作以获取详细信息、编写测试用例、定义验收等

---

当您在快速交付时，用户可以继续说废话，这些废话将附加到未实现的用户故事的积压中。允许用户说出他们想说的任何废话是非常非常重要的。让他们闲聊是件好事。

你在网上找到了哪些用户故事的定义？有很多。请提供一些链接来定义你（和你的团队）的“好”定义。我们不知道你的背景，也不知道你读过什么。对显而易见的事情重新审视是没有意义的。请提供一些您已经使用的资源的链接。我的主要来源之一是：-主要问题是，我们刚刚开始，这些用户故事好吗？两个刚开始讨论用户故事的人，这对我很有意义。谢谢。不过，我认为登录故事不会创造客户价值的说法有点过于教条——当然，如果故事的措辞是“未经我同意，其他用户无法查看或操纵我的数据”或“fe”