如何打破内部巨大变化的用户故事，例如底层数据访问层
我们有一些产品，其中一个产品使用平面文件进行持久化。套件中的其他产品可以使用该数据(通过API)，但一次只能使用一个。
我们不能将整个文件作为其庞大的数据放在DB中。20GB+..但我们仍然找到了一个解决方案，可以将一些数据放入DB中。例如用户解释、元信息、标记等。
所以故事是这样的：
“作为用户，我可以同时访问产品B、C和D中的产品A数据”。这是很大的，大约需要6-8个月
即使我将其保留为“作为用户，我可以同时访问来自产品B的产品A数据”。它仍然很大..即大约5-6个月
即使像这样做，它仍然是巨大的..“作为用户，我可以同时访问来自产品B的产品A的特征X数据”。即大约4-5个月。
问题是，如果我们可以做一件事(一个功能，一个产品)，我们就可以很快完成所有的事情。
我怎样才能把这个故事分成几个子故事呢？或者我应该接受这样的观点，即一些故事不能被进一步分解成可以在一次迭代中容纳的子故事。
PS:我们使用scrum
回答 3
Stack Overflow用户
发布于 2011-07-15 13:09:25
问问你自己(和你的团队)：是什么让这个故事如此宏大？在此过程中，是否绝对没有任何好处？特性和产品将是显而易见的削减，但可能不一定(如您所展示的)足够好。
功能的子组件怎么样？你要放什么？其中有没有外部可见的或有价值的？
您是否拥有产品的身份验证、配置或其他“标准”方面？你可以把它们剪掉，放到用户故事里。
也许3-5个月的特性可以进一步减少？
不管怎样，
我希望这能帮到你,
阿萨夫。
Stack Overflow用户
发布于 2011-07-22 03:47:12
你所描述的就是我们所说的“史诗”--它实际上是你用更大的描述符描述的小故事的集合。我建议您做一些更多的分析，以确定系统的哪些部分将受到您的请求的影响。您可能有一些分组，如报告、条目表单等，这些分组分别受请求的影响。
以用户故事的形式处理“史诗”请求对每个领域的影响。例如，“增强报表X以包含来自产品B的数据”、“增强报表X以包含来自产品C的数据”等。我不太了解您正在进行哪些更改以使标题更具描述性，但希望您能理解。保持这种解构，直到故事降到每个2、3或5分的最佳点。
这样做的好处是，它还允许PO在看到此请求的所有成本后做出决定。一旦他们看到将产品C也包括在内的成本，他们可能会认为我们真的只需要访问产品B的数据就能成功。
Stack Overflow用户
发布于 2011-07-14 22:10:10
敏捷完全支持某些特性比典型的冲刺周期(2-4周)具有更长的视野。当然，故事可以分解成任务。在这种情况下，我建议优先处理这个故事的任务，并使用您的scrum方法将它们烧毁。在每个冲刺结束时，你仍然应该有可以演示/测试的“工作软件”。您可能还没有完整的功能，但这也没关系。
https://stackoverflow.com/questions/6694344
复制相似问题
腾讯云开发者
