用户故事可以有子用户故事吗？

Question

我正在更新一个现有的医疗软件，我和一些终端用户一起定义了用户故事。如果你不熟悉医疗环境:一个医生通常有多个病人。每个病人都有多个病例(腿骨折、皮肤病等)。在医疗方面，一旦病人接受治疗，案件就会结案。这可能发生在几天后(生病)或有时几个星期或几个月(例如，如果涉及物理治疗)。然而，在大多数医疗软件中，案件必须在预定的时间内(几天或一个月后)才能结清，因为大多数健康保险只为已结案的病例支付费用。

大多数医院和诊所的医生在与病人进行会诊时使用标准化的形式，即APE表格(年度体检)。

该软件的用户界面不太友好，因此我的工作很大一部分将是改善用户体验。当前版本的病例的UI看起来与类人猿非常不同，特别是新来的医生因此而对UI产生了麻烦。因此，我们想要改变UI，使它看起来更像一个猿形式。现在我有了以下两个用户故事，而第二个用户故事似乎是第一个用户故事的一个孩子。

第一用户故事：

作为一名医生，我希望软件中的一个病例看起来像猿的形式。

第二用户故事：

作为一名医生，我想查看病人的全部病史，以便快速了解医疗数据(见附件)。

这是正确的吗？在我以前做过的所有项目中，用户故事要么完全独立(意味着没有父级)，要么是特性的子类。这就是为什么我不确定一个用户故事是否可以在孩子的时候有另一个用户故事。

Answer 1

我觉得你想得太多了。

最终的目标是什么？你是试图为企业提供一个高质量的结果，还是试图遵循一种方法呢？

现在，在一个正常的世界中，答案是显而易见的，我只是主张您以任何方式明确和明确地描述问题，来指定您的需求。所以，子故事很好。当我还是一名开发人员时，我不会有任何问题来理解您的意图并交付它。

在一个不那么理智的世界里，你可以让被动的、咄咄逼人的开发人员寻找漏洞加以利用，这样，缺陷跟踪系统就会显示出比开发人员更多的可归因于分析的缺陷；或者是外部供应商，他们通过巧妙地实现你指定的目标而赚更多的钱，尽管这并不是你想要的，而是收取了一大笔钱来缩小差距。如果您生活在这个世界中，您需要绝对确保您的规范遵循开发团队期望得到的任何方法。

因此，绝对正确的答案取决于两件事，你的政治背景和商定的方法。如果有任何疑问，花半天时间做一些嵌套的用户故事，并将它们提交给开发团队审查。他们应该能在半小时内让你知道你的立场。

Answer 2

您的场景听起来不像父/子关系，而是一个简单的依赖关系。第二个故事在第一个故事完成之前是无法完成的。事实上，正如所写的，它甚至不依赖。你当然可以在没有类人猿形态的情况下完成一个“看到整个病史”的故事(除非类人猿形态是“整个医疗史”)。

或许一个更好的看待这一问题的方法是扭转这种关系。在我看来，你有一部史诗，可以这样表达：

史诗:作为一名医生，我想看看病人的全部病史，以便快速了解医疗数据(见附件)。

然后，你会把史诗分解成多个独立的故事：

• 故事:作为一名医生，我需要一个能让我查看每一段病史的工具。
• 故事:作为一名医生，我想让病史查看者包括X。
• 故事:作为一名医生，我希望医学史观众包括Y。
• 故事:作为一名医生，我希望医学史观察者包括猿类的形式。
• 故事：.。

作为发布和sprint计划的一部分，您可以根据依赖关系对故事进行排序。也许您可以编写查看器，而无需查看任何内容，然后可以将内容添加到查看器中。或者，在处理观众之前，您可以先编写历史的各个部分。这是您的团队，让他们决定处理依赖关系的最佳方法。

在敏捷中，这种情况时有发生。事实上，人们可以说这是正常的情况。故事不可能在真空中存在。在完成创建报表的故事之前，不能编写一个故事来打印报表。在构建了包含报表的数据库之前，不能创建报表。诸若此类。

所以，先想想大局，“我需要看所有的病史”，然后把它分解成一小块。“我需要病史包括类人猿”，等等。这些故事相互依赖是非常自然的，你不能改变这个事实。编写这些故事的目标之一是使这些依赖关系可见。

Answer 3

这是一个非功能性的要求。第二个用户故事是表达功能需求。它们是两种不同的要求，即使在实践中它们是相关的。更清楚的例子是：

• (功能)用户可以请求X。
• (非功能性)系统每分钟可以处理1,000个请求。

如果这是你想要做的事情，你可以用用户故事来表达这一点(第一次谷歌的结果是关于如何做的建议：https://www.mountaingoatsoftware.com/blog/non-functional-requirements-as-user-stories)。