我正在从事一个具有非常复杂的集成需求的项目，特别是接收和发送 EDI 数据以及介于两者之间的所有“有趣”的东西。我绝对可以将精力集中在数据处理（验证、必填字段、转换）上，但我遇到的问题是如何在积压工作中构建故事和史诗以计划和跟踪工作。
很容易说“作为经理，我可以拒绝休假请求，以确保我有足够的员工来履行我的承诺。” 实际上，我非常擅长这一点，但我对这种整合工作还很陌生。
对于大型集成项目，更难说明用户是谁，价值是什么。EDI 集成只是接口（非功能性）需求，但实施是一项艰巨的工作。
任何人都可以就如何在我正在创建的产品待办列表中构建/构建这些类型的需求提供一些指导吗？
迈克科恩对此有话要说，我认为最后一段非常相关
但是，您应该注意不要沉迷于该模板。它只是一个思考工具。尝试在此模板中添加约束是一个很好的练习，因为它有助于确保您了解谁想要什么以及为什么想要什么。如果您最终得到一个措辞混乱的声明，请删除该模板。如果您无法找到表达约束的方法，只需以任何感觉自然的方式编写约束即可
Scrum 没有规定需求应该写成用户故事，你应该使用最适合你的技术。如果您正在与“AS A”类型的故事作斗争，请尝试“IN ORDER TO AS AI WANT”。如果不使用，请使用用例建模。
需求不是合同，而是沟通的占位符。这里的关键是要有足够的信息用于规划目的，让团队知道必须做什么。细节可以在sprint中讨论。
我在这种情况下所做的是：
1) 尝试提出我们可以为集成实现的最简单的端到端功能。
2）尝试为该集成提出一个用例
3）将其转化为故事（可选步骤：故事不是物理定律。如果它们有用，您可以使用它们。）
例如：
1）好的 - 看起来身份验证是最简单的实现方式，涉及所有内容。
2）嘿 - 身份验证本身很有用。我们可以用它来知道这组用户是否可以访问数据。
3）“作为网站管理员，我想确保只有授权的东西才能访问 Foo 以防止有价值的信息被公开访问”
这样，您将始终拥有一个有效的 EDI 系统——它只涵盖了功能的一个子集。您可以随着时间的推移而增长的子集 - 希望按照功能对您的业务的重要性排序。
然而，我真正的偏好是更深入地了解为什么要进行 EDI。通常不会因为“EDI”是人们想要的功能。这是因为 EDI对于系统中的一些其他功能是必需的。
在这种情况下，与其拥有一个单独的 EDI 项目，我更愿意使用任何需要 EDI 的东西来驱动 EDI 层的开发。上面 (3) 中的故事将来自一个实时项目 - 你将更有可能构建你需要的东西并避免浪费。