创建和编辑应该是两个独立的用户故事吗？

Question

我经常遇到这样的情况:创建和编辑操作非常相似，但它们并不完全相同。那么，它们应该作为单独的用户故事处理，还是作为一个用户故事来处理呢？例如，我可以：

选项A: US A1:作为系统管理员，我希望创建新的用户帐户，以便指定用户可以访问哪些服务，用户可以访问系统。美国A2:作为一名系统管理员，我希望管理用户帐户，这样我就可以更改用户可以访问和重置密码的服务。

vs

选项B: US B1:作为系统管理员，我希望创建和管理用户帐户，以便指定用户可以访问的服务，并确保用户可以使用系统。

方法A或B是正确的，还是仅仅是个人偏好或实用主义的问题取决于创建和编辑功能的复杂性？

Answer 1

这里要考虑的关键是你的故事是否可以管理。

为了便于管理，它们需要：

• 毫不含糊地定义
• 相当容易估计
• 可在冲刺中完成

所以，如果你发现合并两个故事在某种程度上损害了上述任何一点，那就不要这么做。

就我个人而言，我更喜欢处理许多小故事，因为我觉得这样做更容易。权衡之处在于，您需要小心地在sprint中排序相关或依赖的故事(这是一项相当琐碎的任务)。

Answer 2

我认为有单独用户故事的备选方案A会更好。

用户故事是需求。有一个一套好要求的特征倾向于被很好地接受。选项A确保您的用户故事具有凝聚力(只处理一件事)、原子(不包含连词)，并且比选项B更容易验证。

从评估的角度来看，可能通过遍历工作流和用例来单独估计每个示例可能更容易一些。您可能会看到它们之间的共性和/或依赖(例如，您需要在编辑一个之前创建一个)，但是如果将它们分解成较小的部分，则可以给出更实际的估计。

不过，从实现的角度来看，您可能需要同时交付这两部分功能，这样才能使发布对最终用户实际有用。不过，这可以在迭代计划中进行管理。取决于您的发布周期，它们可能在一个版本中结束，但在不同的迭代中结束，如果一个版本在每次迭代之后并不发生。一切都取决于计划和管理。

Answer 3

TL;DR，它们应该是两个独立的，但相关的要求。

将它们作为单独的需求运行的风险在于，您将拥有关联的UI和底层服务的重复代码。但是，将它们合并为单一需求的风险在于，编辑路径的设置与其略有不同。

create路径如下所示：

• 授权用户(AU)登录到系统，打开create user面板
• AU输入并验证新用户的详细信息。
• AU向系统提交创建请求
• 系统验证是否符合有关用户帐户的业务规则。
• 系统存储用户帐户(可能是insert语句)

edit路径如下所示：

• 授权用户(AU)登录到系统，打开edit user面板
• AU请求检索用户详细信息。
• 系统检索用户详细信息并向AU提供信息。
• AU为新用户调整详细信息
• AU向系统提交编辑请求
• 系统验证是否符合有关用户帐户的业务规则。
• 系统存储用户帐户(可能是更新语句)

有一些明显的重用与创建和编辑用户面板。同样，可以重复使用相同的例程来根据用户帐户检查业务规则。

但是create不需要检索现有的用户详细信息，而且创建路径可能会有稍微不同的提示，比如密码设置。

要遵循哪条路径的最终决定取决于您的开发团队的工作方式。根据我的经验，有两个单独的用户故事在表示项目管理所涉及的工作负载方面做得更好。一般来说，这两项任务将分配给同一人，这将减少在满足要求时进行额外沟通/协调的需要。

当您有密切相关的用户故事时，请考虑更广泛的视角，您需要花点时间简单地列出每个故事所涉及的内容。如果两个故事之间有很大的不同，那么我认为你最好使用不同的故事。这有助于确保显着的差异不会隐藏在合并的故事中。