refactoring - 如何打破在内部发生巨大变化的用户故事，例如底层数据访问层

<分区>

我们有一些产品，其中一个产品使用平面文件来实现持久性。套件中的其他产品可以使用该数据(通过 API)，但一次只能使用一个。

我们不能将整个文件作为其庞大的数据放入数据库中。20GB 以上。但我们仍然找到了一种解决方案，可以将一些数据放入数据库中。例如用户解释、元信息、标记等。

所以故事是这样的:

“作为用户，我可以同时从产品 B、C 和 D 访问产品 A 的数据”。这是巨大的，即大约 6-8 个月

即使我将其保留为“作为用户，我可以同时从产品 B 访问产品 A 数据”。它仍然很大......即大约 5-6 个月

即使像跟随一样，它仍然是巨大的.. “作为用户，我可以同时从产品 B 访问产品 A 数据的功能 X”。即大约 4-5 个月。

问题是如果我们可以做一件事(一项功能，一种产品)，我们就可以快速完成所有事情..

我怎样才能将这个故事分解成子故事..或者我应该接受一些故事不能进一步分解成适合一次迭代的子故事。

PS:我们使用scrum

最佳答案

问问你自己(和你的团队):是什么让这个故事如此重要？一路走来，绝对没有任何好处可以展示吗？功能和产品将是明显的削减，但可能不一定(如您所示)足够好。

该功能的子组件如何？你在放什么？其中有任何外部可见的或有值(value)的吗？

您是否有产品的身份验证、配置或其他“标准”方面的信息？您可以将它们剪掉并将它们作为用户故事。

也许 3-5 个月的功能可以进一步削减？

无论如何，

希望对你有帮助，
阿萨夫。

关于refactoring - 如何打破在内部发生巨大变化的用户故事，例如底层数据访问层，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6694344/

相关文章：

ios - 我在哪里可以查看大型 iOS 代码库以了解其组织方式？