Scrum 中集成的用户故事 [关闭]

Question

我正在处理一个具有非常复杂的集成需求的项目，特别是接收和发送 EDI 数据以及在这两者之间发生的所有“有趣”的事情。我绝对可以将精力集中在数据处理（验证、必填字段、转换）上，但我遇到的问题是如何在积压工作中构建故事和史诗以计划和跟踪工作。

很容易说“作为经理，我可以拒绝休假请求，以确保我有足够的员工来履行我的承诺。”实际上，我非常擅长这一点，但我对这种集成工作还很陌生。

对于大型集成项目，更难说明用户是谁以及价值是什么。 EDI 集成只是接口（非功能性）需求，但实施是一项艰巨的工作。

谁能提供一些关于如何在我正在创建的产品待办列表中构建/构建这些需求的指导？

Answer 1

Mike Cohn对此有话要说，我觉得最后一段很相关

但是，您应该注意不要沉迷于该模板。它只是一个思考工具。尝试在此模板中添加约束是一个很好的练习，因为它有助于确保您了解谁想要什么以及为什么想要什么。如果您最终得到一个措辞混乱的声明，请删除该模板。如果你找不到表达约束的方式，就用任何感觉自然的方式来写约束

Answer 2

Scrum 没有指定需求应该写成用户故事，你应该使用最适合你的技术。如果您正在与“AS A”类型的故事作斗争，请尝试“IN ORDER TO AS A I WANT”。如果不使用，请使用用例建模。

需求不是合同，而是沟通的占位符。这里的关键是要有足够的信息用于规划目的，让团队知道必须做什么。细节可以在sprint中讨论。

Answer 3

在这种情况下我会做的是：

1) 尝试提出我们可以为集成实现的最简单的端到端功能。

2) 尝试为该集成提出一个用例

3) 将其转化为故事（可选步骤：故事不是物理定律。如果它们有用，您可以使用它们。）

例如：

1) 好的 - 看起来身份验证是涉及所有事情的最简单的实现。

2) 嘿 - 身份验证本身很有用。我们可以通过它来知道这组用户是否可以访问数据。

3) “作为网站管理员，我想确保只有经过授权的人员才能访问 Foo，以防止有价值的信息被公开访问”

通过这种方式，您将始终拥有一个正常工作的 EDI 系统 - 它仅涵盖部分功能。您可以随着时间的推移而增长的子集 - 希望按照功能对您的业务的重要性排序。

我的真正的偏好是进一步挖掘为什么要进行EDI。通常不会因为“EDI”是人们想要的功能。这是因为 EDI 对于系统中的一些其他功能是必要的。

在这种情况下，与其拥有一个单独的 EDI 项目，我更愿意使用任何需要 EDI 的东西来推动 EDI 层的开发。上面 (3) 中的故事将来自一个实时项目 - 您将更有可能构建您需要的内容并避免浪费。