如何使用用户故事定义复杂的业务规则？

用户故事的快速而肮脏的定义：

"As a <role>, I want <goal/desire> so that <benefit>"

在这个公认的定义中，几乎没有空间定义业务规则，约束或用户输入。

一个简单的例子只是为了说明：

"As a <librarian>, I want to <register new books> so that
<students can find their availability online>"

在这个愚蠢的例子中，注册书时在哪里定义所需的字段？应该写在任何地方吗？还是应由产品负责人以口口相传通过所需的业务规则？

这些字段是应该进行的对话的一部分。如果有用的话，可以将它们写下来，但这只是一个判断。使文档保持最新状态可能具有挑战性，而在一定程度上可以将工作软件视为文档。

用户故事-进行对话的承诺将是关于此的博客条目。

您的琐碎示例有两点，我不知道您对此有多注意。“注册新书”是什么意思？什么是“在线查找其可用性”？那些是谈话开始的地方，一旦故事完成，可能会有新的故事，因为这些注册必须存档或定期生成报告。

先前的答案提供了有效的观点，特别是关于用户故事是进行对话的提醒。要考虑的其他事项：

1. 如果故事太复杂，那可能是史诗般的故事。您可以立即将史诗分解为较小的故事，也可以在产品待办事项列表中将它们优先化之后

2. 暗示测试用例的细节与故事本身分开。[ Mike Cohn ]

   您可以在故事卡的背面添加注释，如果它们确实很重要，则作一些小注释，或将其放入验收测试文档中。

作为评估用户故事是否良好的指南，您可以遵循Bill Wake的建议：

• 我依赖（其他故事）
• ñ egotiable
• V aluable（用户或客户）
• E令人兴奋的（非常近似）
• 小号商场（足以被估）
• Ť estable

您可能需要阅读Mike Cohn撰写的User Stories Applied一书的第2章“写作故事”。

通常，在具有许多方面的广泛用户故事中，我尝试获取该故事的最一般示例，然后针对特定内容，创建从其继承的子用户故事。许多敏捷项目管理工具（例如RallyDev）使您可以轻松地做到这一点，我认为这很有意义。

新书的注册范围很广，因此也许还有其他10个关于用户<role>希望如何注册书的儿童故事。

我通常在用户故事下的一个或多个任务中定义这些东西的极端细节或奇怪的边缘细节。这些任务有助于定义开发和设计工作（应在一般级别上完成）以满足该用户的需求（例如，编写验证程序以确保描述字段中的输入少于50个字符...） 编辑： 我只是想添加最好不要将极端细节保留在用户故事中，因为这可能并不是用户真正关心的事情。用户想用一般术语来解释软件，他们依赖软件开发人员来找出并隐藏其中的细节。

这就是我解决问题的方式，但是我敢肯定有很多不同的方法。

答案很简单，将业务规则纳入接受标准。

一个简单的例子只是为了说明：

作为图书管理员，我想注册新书，以便学生可以在线找到其可用的图书。

在以下情况下，我会感到满意的：*我可以注册以下字段：-ISDN-作者-杜威十进制等等等等*我可以看到确认书已被系统注册*我可以在系统中查看书

如何使用用户故事定义复杂的业务规则？

这不是用户故事的目的。它们不是捕获编写实现所需的所有详细信息或业务规则的软件要求。它们只是从用户的角度描述应用程序应该做什么。

记住重要的一点：构建适当的软件。您可以使用所需的功能来做到这一点，并且用户故事只是为了确保您已收集了应用程序应具有的所需功能，因此您可以对其进行讨论，对其进行优先级排序，对其进行估算，等等。古典用户所缺少的部分故事（作为……我想要的……）是关于构建软件的人员之间的交流。

在规范文档或其他内容中，将详细信息作为接受标准，子故事，附加到用户故事的技术任务，超出了用户故事可以为您提供的帮助。在决定如何构建软件时，用户的笨拙只是对话的“主题”。

在给出的示例中，有许多开发人员可能不了解的图书注册细节，例如杜威或其他分类系统，ISBN，获取编号，重复的副本/标题/作者，其他版本，等等。 对于新系统，此类详细信息必须由客户提供（所有人中的图书馆员一定会在意这些细节）。

用史蒂夫·奥康奈尔（Steve O'Connell）的话来说，“考虑到开发人员创建了多少业务策略真是太恐怖了，这些开发人员缺少规范中的必要细节，因此只能自己弥补。”