我们有一些产品使用其中一个产品使用平面文件来保持持久性。套件中的其他产品可以使用该数据（通过API），但一次只能使用一个..
我们不能将整个文件放在数据库中作为其庞大的数据.20GB + ..但我们仍然找到了一些解决方案，其中一些数据可以放入数据库中。用户解释，元信息，标记等。
故事如下：
“作为用户，我可以同时访问产品B，C和D中的产品A数据”。这是巨大的，即大约6-8个月
即使我将其保留为“作为用户，我可以同时访问产品B中的产品A数据”。它仍然很大......即大约5-6个月
即使做到如下，它仍然很大.. “作为用户，我可以同时访问产品B的产品A数据的特征X”。即约4-5个月。
问题是如果我们可以做一件事（一个特征，一个产品），我们可以快速完成所有工作......
我怎样才能将这个故事分解为子故事......或者我应该接受一些故事不能进一步分解为可以适合一次迭代的子故事。
PS：我们使用scrum
答案 0 :(得分：4)
问问自己（和你的团队）：这个故事有多大？沿途可以展示绝对没有任何好处吗？功能和产品将显而易见，但可能不一定（如您所示）足够好。
该功能的子组件如何？你在放什么？它的任何外部可见或有价值吗？
您是否拥有产品的身份验证，配置或其他“标准”方面？你可以删除它们并将它们作为用户故事。
也许3-5个月的功能可以进一步减少？
反正
我希望这有帮助，
阿萨弗。
答案 1 :(得分：2)
你所描述的是我们所谓的“史诗” - 它实际上是一个较小的故事集合，你用更大的描述符描述。我建议您进行更多分析，以确定系统的哪些部分会受到您的请求的影响。您可能会有报告，条目表单等分组，这些分组会受到请求的单独影响。
将“史诗”请求对每个区域的影响作为用户故事解决。例如，“增强报表X以包含来自产品B的数据”，“增强报表X以包含来自产品C的数据”等。我不太了解您要更改的内容以使标题更具描述性，但希望您获得这个想法。继续解构，直到故事达到每个2,3或5个点的最佳位置。
关于这一点的好处是它还允许PO在看到此请求的所有成本后做出决定。他们可能会认为我们真的只需要从产品B中获取数据，一旦他们看到包含产品C的成本，就能获得成功。
答案 2 :(得分：1)
Agile完全支持某些功能比典型的冲刺期（2-4周）具有更长的视野。当然，故事可以分解为任务。在这种情况下，我建议优先处理此故事的任务，并使用您的Scrum方法将其烧毁。在每个sprint结束时，您仍然应该拥有可以演示/测试的“工作软件”。你可能还没有完整的功能，这没关系。