问用户故事如何不包含需求(当写在卡片上时)并且仍然是可实现的？

EN

这个答案将侧重于如何处理用户故事和更低级别的需求。我不会讨论Scrum或Agile的优点或不足。我也不会谈论古鲁。

这个答案假设你已经加入了Scrum，但还没有找到适合你的方法。

正如其他人所提到的，用户故事是为了涵盖用户希望软件是怎样的。因为用户不关心底层实现，比如数据库表、约束、架构模式等等，所以在用户故事中找不到这样的细节。

然而，这并不意味着这些细节不应该被记录在任何地方。

当开发人员实现用户故事时，他们需要知道更低层次的细节，典型的用户不会知道。这些信息可以来自中小企业、BAs、产品负责人、您的架构师或任何其他专家或有技术头脑的人。

这是否意味着低层次的细节应该记录在用户故事中？没有(也有)。

在故事创建和实现之间的某个时刻，需要有人想出如何实现它。这通常采取与故事中涉及的人(用户、架构师、开发人员等)进行对话的形式。这些对话的结果应该是明确的接受标准，这清楚地划分了用户故事实现的范围。这些细节将需要被记录在某个地方，这是真正取决于你。这里的关键是，这些细节是在创建用户故事之后生成的。我认为这就是你的导师想要强调的。

作为一名开发人员，很明显，您需要一种将更具体的需求与您的用户故事相关联的方法。你怎么做完全取决于你的团队。

如果您的团队中的人想要将这些细节排除在用户故事之外，那么您可能需要尊重这一点。让您的高级用户故事不受实现细节的影响是有好处的。它使用户保持精益，您的待办事项可以作为用户和产品负责人所需内容的历史记录来阅读。只需让您的需求作为一个开发人员以及。您应该能够找到一个折衷方案，只需链接到用户故事就可以让每个人都感到高兴。

是的，它是BS。而Scrum并不是敏捷的。

我讨厌所谓敏捷实践者的僵化，他们告诉你，有一种方法可以实现敏捷，而且你必须遵循他们所使用的“敏捷”方法论的神圣经文中的所有规则。全是废话。

敏捷是关于敏捷的。

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

所以在这种情况下，如果将用户需求放在卡片中可以帮助您编写、测试、记录和演示所需的代码.把需求写在卡片上，告诉专家团队总是正确的。

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

我认为如果Scrum的顾问告诉您Scrum不需要需求，那么您就有一些非常糟糕的顾问。他们甚至错误地告诉你，用户故事实际上根本不是一个需求，它们恰好是一种需求。

软件需求的不同类型是什么？

业务需求

这通常是一种高水平的业务需求，通常相当于一种关于系统的执行风格声明。它是有目的的高层次和广泛的，如果没有更多的细节，它本身就不可能得到执行。

用户需求

这些是您熟悉的用户故事需求。它们一般可以贴在便条上。

• 参与者--通常是用户或涉众。
• 需要-用户需要的一些项目或一般功能
• 理由--这种需要存在的原因或背景
• 验收标准--这是用户验收测试的框架，在Sprint期间，产品负责人将如何决定用户故事是否被接受。

功能或系统需求

这似乎是你拼图中缺失的部分。从用户级需求出发，功能需求定义了系统级参与者和系统属性，以及系统的行为和功能。这也可以以故事格式完成，并包含在您的待办事项中。这些项目应该是独立的，并且可以独立于任何一个用户需求来实现。

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

功能需求定义了您的解决方案，这听起来就像您所描述的流程中的空白。

值得注意的需求类型提到，但不影响您的问题:非功能需求，技术要求，等等。