用户故事如何不包含要求（当写在卡片上时）仍可实施

有人告诉我“用户故事不是需求，它只是在提醒客户需要什么，您不能在故事中放入需求”。但让我们举一个例子，客户希望对不同的信用卡进行不同的处理。必须执行并知道严格的要求，以便可以编写测试用例。如果不在用户故事中，需求应该去哪里？

如果没有更低的要求，开发人员如何从故事中发展？测试人员如何根据用户故事编写测试用例（详细的用例）？用户故事之外还存在DB约束，字段验证等需求吗？

该答案将侧重于如何处理用户故事和较低级别的需求。我不会讨论Scrum或Agile的优点或不足之处。我也不会谈论大师。

该答案假定您已加入Scrum，但尚未找到使它适合您的方法。

正如其他人提到的那样，“用户故事”旨在涵盖用户希望软件如何发展。由于用户不关心数据库表，约束，体系结构模式等底层实现的内容，因此您不会在用户案例中找到此类详细信息。

但是，这并不意味着这些详细信息不应记录在任何地方。

当开发人员实施用户故事时，他们需要了解典型用户不知道的较低级别的细节。此信息可以来自SME，BA，产品负责人，您的架构师或任何其他专家或技术人员。

这是否意味着低级详细信息应记录在“用户故事”中？不（是）。

在时间之间的某一点的故事是建立和实施有人会需要解决如何实现它。通常采取与故事中涉及的人员（用户，架构师，开发人员等）进行对话的形式。这些对话将导致明确的接受标准，该标准清楚地描述了用户故事实现的范围。这些细节将需要记录在您真正需要的地方。此处的关键是在创建用户故事后会引出这些详细信息。我认为这就是您的老师想要强调的。

作为开发人员，很显然，您需要一种将更特定的需求与用户案例相关联的方法。只是怎么你这样做完全取决于你的团队。

如果您团队中的人希望将这些详细信息排除在用户故事之外，那么您可能需要尊重这一点。使高级用户故事免于实施细节有好处。它使他们保持精简，并且您的积压订单可以作为用户和产品所有者想要的历史记录来阅读。只要使您的需求成为开发人员也广为人知。您应该能够做出妥协，而仅通过链接到用户故事就能使所有人满意。

是的，其BS。Scrum不是敏捷的。

我讨厌所谓的敏捷从业者的僵化，他们告诉您有一种做敏捷的方法，并且您必须遵循圣经中所采用的所有“敏捷”方法论中列出的所有规则。所有的BS。

敏捷就是要敏捷。

敏捷就是要以最少的开销完成工作。这并不意味着“没有文档”，因为您通常最终会以敏捷角色进行更多文档记录，而无需进行计划文档编制流程就可以继续进行文档编制。与编码，测试和需求捕获类似。在敏捷过程中唯一重要的事情是那些可以帮助您快速有效地完成工作而无需任何BS的事情。

因此，在这种情况下，如果将用户需求放到卡片上可以帮助您编写，测试，记录和演示所需的代码...将需求放到卡片上，并告诉专家团队永远是对的。

您的其他开发团队会怎么想？在真正的敏捷方法论中，如果他们都认为应该在没有任何“用户对话”的情况下预先编写需求，那么就应该由团队认为最适合他们的工作来完成。如果团队认为用户对话是一件好事，请听取他们的意见，并理解他们为什么这样认为并使自己进入工作方式。

只是不要将其称为用户故事，每个人都会很高兴。

我认为答案是，您可以随时随地写下来。

通常，由于以下几个原因，特定的实现未包含在用户故事中：

1. 您知道客户想要什么，但是您不知道它将如何实现。
2. 客户知道其中涉及更多特定要求，但实际上并不在乎和/或理解它们。
3. 每个人都认为他们此时已经完全意识到了具体的实现，但是没有人愿意写下来，因为根据他们的经验，一切都会改变，并且没人愿意重写它。

没有规则在必要时省略其他文档。客户端可能需要访问它，也许不需要。如果您希望在特定实现上与客户之间达成某种合同，好像您可以遵循该合同，而当合同不起作用时，则应怪责客户同意该协议，那您就错了。如果客户了解信用卡处理的技术细节，则应与他们共享这些文档，并可能使其成为对话的一部分。

我认为，如果您的Scrum顾问告诉您的是Scrum不需要要求，那么您会有一些非常差的顾问。告诉您用户故事实际上根本不是要求，他们甚至是错误的，它们只是一种要求。

有哪些不同类型的软件要求？

业务需求

这些通常是高层业务需求，通常相当于某种有关系统的执行风格声明。它是有目的的，高度的，广泛的，其本身如果没有太多的细节就无法实现。

用户需求

这些是您熟悉的用户故事要求。它们通常可以贴在便签上。

• 演员-通常是用户或利益相关者。
• 需求-用户需要的某些项目或常规功能
• 原因-存在此需求的原因或背景
• 接受标准-这是用户接受测试的框架，在Sprint演示期间，产品负责人将如何确定用户故事是否被接受。

功能或系统要求

这似乎是您难题中缺少的部分。从用户级别的需求驱动，功能需求定义了系统级别的参与者和系统的属性，以及系统的行为和功能。这也可以以故事格式进行，并包含在您的积压中。这些项目应独立存在，并且可以独立于任何一个用户要求而实施。

• 演员-某种系统或组件。
• 需求-应该存在的系统的需求，属性或行为声明。
• 原因-系统中为什么需要这样做的背景
• 验收标准-传达应如何执行系统和集成测试所需的方案，行为，功能和流程。当这些类型的测试通过需求时，我们就知道该功能需求已经完成。这些内容可以存在于用户故事的外部文档中，但应在将这些故事分配给Sprint之前完成。

功能需求定义了您的解决方案，这听起来像您所描述的过程差距。

需要提及但与您的问题无关的显着需求类型：非功能需求，技术需求等...

用户故事是一种特定的人工制品，其目的是描述用户期望系统提供的界面，这就是为什么低级详细信息根本不属于该系统的原因。如果将它们放在此处，您正在改变人工制品的意图，它不再符合美国的定义。

使用其他形式的规范来捕获较低级别的需求和设计决策。这些其他形式究竟应该是什么，必须在您的组织中解决并针对您的特定环境进行定制。

您的问题听起来很像

我有这个CarFactory，也需要制造自行车，但是我们的OOD“ Guru”说我不允许这样做。这是什么BS！？！

尊重关注点的分离和产品的内聚力，包括代码中的关注点和流程中的关注点。

我认为这种方法的目的不是限制用户故事，而是防止不良要求。

根据我的经验，用户通常无法编写要求。开发人员通常无法编写要求。哎呀，让我们直接承认这一点：要求很难写！

我认为对于用户来说，在需求术语中写一些东西作为使用故事的一部分是有效的。但是，这样做不应自动成为一项要求。 有两个相互矛盾的使用故事是一个小问题；有两个相互矛盾的要求是一个重大的违约问题。 在此之前将彼此提升为毫无意义。

我认为严厉的观点来自对人性的认识。如果人们开始将用户故事视为放置需求的地方，那么他们将开始这样做。与使用其他收集需求（例如信息）的方式相比，使用故事的真正优势在于它们以用户的自然措辞和符号表达。这使得开发人员更有可能从客户的角度进行思考。在理想的世界中，寒冷的需求行话也可以到达那里。实际上，这样的用语往往会使开发人员陷入易于理解的需求中，而错过了敏捷开发希望通过使用故事来发掘的微妙措辞和细微差别。

自己做决定

答案是“如果没有更低的要求，那么开发人员实际上将如何开发一个故事？” 非常简单-与最终用户需求正交的详细要求（例如，数据库约束，字段验证等）对用户实际上并不重要。如果可以通过非常不同的字段验证，非常不同的数据库结构甚至根本不需要传统数据库来满足用户需求，那么让用户在考虑特定实现的情况下编写此类信息将适得其反。与系统最终实现方式不同。

您是专业的开发人员，因此请尽最大可能就实施细节做出专业决策。想要桌子的用户可以告诉木匠他们想要哪种类型的木材，但是木匠应该决定桌腿的厚度，以便承受合理的载荷。如果您缺乏一些信息来做出有意义的决定，则需要与用户进行讨论，但是，除了模糊的用户故事常识和行业最佳实践之外，详细的需求文档中约90％的内容实际上不需要任何信息。 。

所有这些细节都不是任意的-有错误的选择和更好的选择，并且应将它们记录下来，因为它们会影响实施的其他部分，但最终它们仍然是实施细节，可由实施团队并根据其决定。满足用户需求和最佳做法。

一个标准的汽车类比-如果客户希望将汽车漆成红色，则针对用户故事的适当澄清是询问哪种红色阴影更好，而不是油漆的化学成分；不过，可以预料的是，他们不会选择用会在雨中冲刷的水彩颜料来绘画汽车，因为最好的做法是不要这样做。

TL; DR

用户案例用于记录应为产品增加哪些价值以及原因。实现细节（例如如何值应添加，测试，测量，或验证）由故事的制约，但在其中不包含。故意将它们留作单独的工件，以保持框架内的灵活性和敏捷性。

规范和实现细节通常在其他工件中捕获，例如验收测试驱动开发（ATDD），测试驱动开发（TDD）和行为驱动开发（BDD）脚本和场景。这些特定的工件不是Scrum框架所强制要求的，但是如果您还没有其他有效的流程控制，那么它们一定会为您提供一个良好的起点。

用户故事不是规范

原始海报（OP）提出以下问题：

[A]客户希望对不同的信用卡进行不同的处理，因此必须执行并知道严格的要求，以便可以编写测试用例...如果不在本文中，应该放在哪里？

用户故事是一种提供价值的功能，提供一些上下文来指导有关实现的对话，以及与将受益于该功能所提供的价值的价值消费者相关的观点。

用户故事的全部要点是实现细节不是说明性的。团队可以自由地以任何方式在适当的上下文中将识别出的价值交付给价值消费者的方式来实现该功能。

一个可行的例子

用户故事样本

如果您从一组不太模糊的用户故事开始，这将更容易解释。由于OP没有提供跟在INVEST助记符后面的可操作的用户故事，因此为了示例，我将发明一个。考虑以下故事：

作为喜欢使用Discover卡付款的用户，
我希望可以使用Discover卡购物，
这样我不仅限于Visa，Mastercard或American Express。

这提供了具体的功能，提供了可以指导团队必须执行的实施决策的上下文，并将价值消费者标识为拥有Discover卡的客户。这不是一组规范，而是您需要与客户和团队进行正确的对话，以了解如何在开发的迭代过程中最好地实现故事。

分析与实施

实际的实施取决于团队。该团队将必须进行一些分析以确定：

• 实现新功能的最简单方法。
• 在不增加技术债务的情况下，最容易支持各种实施方案中的哪一种。
• 如何应用开闭原则和YAGNI原理，以确保新功能稳健而又不会过度设计。

客户宣言是敏捷宣言的核心原则之一。跨职能，自组织的团队有望与客户合作，以​​根据用户故事提供的准则制定实施细节。

如果您的用户故事写得不好，或者团队没有足够的技能或流程成熟度来进行敏捷框架所需的足够的分析，那么显然这将比需要的难得多。整本书都以如何在适当的粒度级别上创建良好的用户故事为主题。不幸的是，这没有灵丹妙药，但这对于敏捷团队来说是一种可学的技能。

测试驱动和行为驱动设计

确保分析合理，实施合理且可支持的最佳方法是使用TDD和BDD做法。例如，鉴于上述情况，团队应通过以下工件捕获计划的实施：

• 具有可测试方案的黄瓜功能。

  这对于推动验收测试的开发以及记录用户对应用程序行为的期望最为有用。例如，用户故事应具有一个或多个相关的Cucumber功能，这些功能描述用户如何使用Discover卡签出以及该过程对用户而言是什么样子。

• RSpec测试，用于验证新代码功能的行为（而非内部实现细节）。

  这对于记录和验证应用程序中功能的预期行为非常有用。例如，用户故事将推动单元测试和集成测试的创建，从而确保使用“发现”卡调用应用程序通过付款网关授权销售所需的卡特定行为。

具体工具无关紧要。如果您不喜欢Cucumber或RSpec，请使用最适合您团队的工具或方法。但是，重点是实现细节是基于用户故事的，但并没有规定。相反，实现（或规范，如果您愿意）是在功能开发过程中以协作方式制定的细节。

这里有很多好的答案。希望我可以给另一个增加一些价值...

我认为您的团队可能正在摆脱一种非敏捷方法。

这通常是某种形式的瀑布方法，实际上，通常确实涉及在编写一行代码之前尝试记录所有技术要求。

但这并不总是有效。通常它不起作用。原因？因为需求很少符合现实。事情会改变的。因此，迈向敏捷。

使用敏捷，用户故事就是用户关心的全部。他们想从A点到B点。如何实现就在您手中。如果您正在等待有人告诉您技术要求，那并不是真正的敏捷。如有疑问，请提问。如果需要文档，请文档化，但是您不希望客户为您做出所有这些决定。他们可能有意见，但是在敏捷环境中，这些意见应该（如您的专家所建议的）在对话中讨论。

可能会觉得这对您的团队来说是负担，但可以认为这是一种奢侈。您的团队现在在解决方案中有很多发言权-在瀑布模型中不一定是这种情况。