将业务规则集成到用户故事中

Question

我有一组用户故事和一组业务规则（主要是法律要求我满足的规则）。在敏捷软件开发生命周期中，我不确定这些“规则”应该与我的用户故事关联到哪里。

例如，像这样的一个用户故事：

作为医生，我想添加患者信息以创建新患者档案。

以及像这样的一条规则：

必须在每个患者的记录中输入以下信息： (a) 患者： (i) 姓名和名字; (ii) 地址; (iii) 出生日期; 和 (iv) 性别;

这两者显然是相关的，但是我应该如何将它们联系在一起？作为我用户故事中的测试验收定义？还是另一个用户故事？

- code-gijoe

---

我投票关闭此问题，因为它与编程无关。 - Vadim Kotov

Answer 1

有几种不同的处理方法：

1. 创建一个artifact来保存业务规则，并将其存储在某个中央存储库中，使开发团队了解此规则并维护知识库。但是，随着应用程序的建立，仅几年内就可能有数百个规则，这可能会变得混乱。
2. 规则可以放在用户故事的不同卡片中。因此，虽然用户故事只有一行，但可能有6-8张卡片组成所有任务，以完成该故事。例如，必须创建新的病人表格，对表格进行验证等。因此，很容易看到这种方式在未来出现在卡片上，作为跟踪要求的一种方式。我认为这是最自然的，但这也不是特定列表100%书面记录的地方，因为卡片可能是“确保表单上的某些字段是强制性的”。
3. 没有明确的链接，而是规则是QA或BA需要注意的内容，以便用户验证表单是否执行此规则。这类似于第一种方法，但问题是开发人员在其中的责任是什么。在这种情况下，这是QA跟踪的内容，而不是开发人员可能需要做的。

用户故事旨在开始讨论，而不是对需求的全面列表。在我的看法中，当开发人员与用户讨论创建新患者文件所需的内容时，规则应该出现。

---

我喜欢在故事完成后保留卡片几个迭代的想法，但我确实意识到这些卡片最终将被销毁。同时，应该有代码来在其正确区域实现规则。使用您发布的示例，可能会在几个地方注意到必填字段的列表，因为必须显示字段和可能的错误消息的UI层，但还应该有一些业务逻辑层具有此逻辑，以便在尝试创建新的患者文件之前查看是否已特定完成某些字段。正在构建的系统也将以某种形式保存规则。

- JB King

---

好的，如果在讨论期间我同意一些规则，我可以遵循你的（2）建议。我认为那会很好。唯一的问题是用户故事通常是“自毁性的”，即故事结束后我会将其丢弃。所以规则也会丢失，或者我错了吗？ - code-gijoe

Answer 2

作为验收标准。毕竟这些都是可以作为测试执行的规则。绝对不是新的故事，因为没有可交付的目标。

- user5344084