agile - 什么是用户故事，什么不是？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

3年前关闭。




Improve this question




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

以下是我们为此冲刺提供的用户故事的实际示例:

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

作为商家用户，我希望对注册表进行验证，以便提供正确的信息。 (这与表单验证有关)

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

我脑海中的第一个是用户故事。后两个似乎是第一个用户故事的传统要求，我认为它们应该是第一个用户故事的验收标准。

我的另一个困惑是在我们的最后一个 sprint 中:

作为用户，我希望能够登录该网站。

作为用户，我希望能够使用用户名登录网站。

产品负责人说这是两个不同的用户故事，需要分别进行测试。

我的问题是，在为后两个创建测试用例和验收标准时，这很困难，因为它们是如此具体并且与第一个用户故事如此相关。似乎我们只是将传统要求放在板上的卡片上，并称之为其他东西。我主要只是想知道我是否错了/为什么？

在我看来，我们目前只是让用户创建他们想要的任何内容作为用户故事，而不是帮助他们从需求中将它们过滤为正确的用户故事。我被告知我们需要将它们全部分开进行报告，以便我们可以记录用户请求的所有内容。

Answer 1

User stories focus on customer value. ... The actual work being done is fleshed out via collaboration revolving around the user story as system development progresses. ... In order to limit scope, user stories have collaboratively developed acceptance criteria which define when the user story meets the stakeholder’s expectations. Test cases are often developed as code (with test driven development) or documented as the code is developed.

[强调我的。]

As a user I want to be able to login to the website.

As a user I want to be able to login to the website with a username.

由于两者都没有提供任何 客户值(value) ，也不是用户故事。
您使用应用软件来管理信息、做出决策并(最终)采取行动。如果用户故事没有提供一些关于采取什么信息、决定或行动的提示，则没有 客户值(value) ，这只是技术文件夹 - 客户必须忍受的实现细节才能到达应用程序的有趣部分。
具体来说，登录信息为零 客户值(value) .这是 IT 在客户和他们做出决策和采取行动所需的宝贵信息之间设置的障碍。这是一种安全机制，大多数人实际上并不喜欢安全性。安全是由 IT 强加给客户的。最流行的密码 (IIRC) 是“aaaaaaaa”。为什么？客户不喜欢安全。
详细、微观 登录 用户故事可能是未能看到客户真正值(value)的症状。

It just seems to me that we are currently just letting the users create whatever they want as a user story

好的。

I am told we need to keep them all separate for reporting so we can keep a log of everything the user requests.

不错的计划，真的。
问题是将“用户碰巧说的废话”与“我们可以构建的有意义的东西”分开。允许用户说出他们想说的任何废话是非常非常重要的。让他们闲逛是件好事。
定期(在每个 sprint 之前)，您将把用户所说的废话优先考虑为以下几件事:(1)您可以在 sprint 期间构建，以及(2)创造您可能创造的最重要和最引人注目的用户值(value)。有些故事会被忽略。有些将是低优先级。有些会合并，有些会分开。用户说的有些事情会自相矛盾。有些将是彻头彻尾的谎言。有些会不完整。都很好。这只是用户碰巧说的废话。不是从众神之口直接给你的神圣指示。
这组修订后的用户故事插入了冲刺。现在您开始与用户合作以获取详细信息、编写测试用例、定义验收等。
当您冲向交付时，用户可以继续说废话，这些废话将附加到未实现的用户故事的积压中。允许用户说出他们想说的任何废话是非常非常重要的。让他们闲逛是件好事。