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