我正在从头开始一个新项目，并编写了用户存储来描述给定用户将如何与系统交互。但是，我很难理解如何将第一个用户故事分解为任务，而不会使第一个用户故事成为史诗。
例如，如果我正在制造一辆汽车，第一个用户故事说“作为一名司机，我希望能够改变运动方向，这样我就不会撞到东西。”，这意味着用户界面（方向盘），还有运动（车轮）以及将它们连接在一起所需的一切（车轴，框架，连杆等......）。最后，第一个用户故事似乎总是代表项目的 40% 左右，因为它包含了太多关于底层架构的信息。
您如何为一个新项目分解用户故事，以使第一个不会成为代表整个底层架构的史诗？
您可能希望将您的故事视为系统的垂直部分。一个故事可能（并且经常会）触及系统所有架构层中的组件。因此，您可能希望将您的任务视为您的故事涉及的每个组件上需要完成的工作。
例如，假设您有这样一个故事，为了能够轻松地关注我朋友的推文，作为注册用户，我想自动关注我所有拥有 twitter 帐户的 gmail 联系人。
为了做到这一点，你将不得不通过 UI 层、服务层，在数据层中持久化一些数据，并对 twitter 和 gmail 进行 API 调用。
你的任务可能是：
那里：那里有 9 个可能的任务。现在，作为一项规则，您希望您的任务大约每天花费 1/2 到 2 天，并且偏向于一天（最佳实践，用于调整大小）。根据难度，您可以进一步分解这些任务，或者如果它们是两个简单的则组合一些（也许这两个 API 调用服务非常简单，您只需修改外部 API 服务）。
无论如何，这是如何分解故事的原始草图。
编辑：
为了回答更多关于将故事分解为任务的问题，我写了一篇关于它的博客文章，并想在这里分享。我已经详细说明了打破这个故事所需的步骤。链接在这里。
当我们在 Scrum 管理风格下开始项目时，第一组任务总是很宽泛，或者如您所描述的：史诗。这是不可避免的，任何项目的框架通常是最重要、最大、最耗时的部分，但它支持项目的其余部分。为了减少压倒性的规模，看看你是否可以列出最重要的部分。然后将这些任务定义为起点。因此，您有一些任务可以作为一个广泛开始的起点。希望这是有道理的！
用户故事描述了what一项任务更多地是关于how.
how将要实施、记录或测试的用户故事的任务。如果你觉得你的故事任务太多（即使你有 1-8 小时的任务），那么也许你应该首先考虑重写你的用户故事，因为它可能太复杂了。
祝你好运
您一开始实施的故事可以随着时间的推移而完善。您不需要认为每个故事都必须是用户将要使用的最终版本。
例如，在最近的一个项目中，我们必须开发一个应用程序，该应用程序涉及对各种网站进行索引，并将它们与用户创建的过滤器进行匹配，最后提醒用户匹配项（类似于 google 类固醇警报）。
如果从一个角度来看，只有一个故事——“作为用户，我想从匹配的页面中获取警报”。但是从“我们想要减轻的风险是什么”的另一个角度来看待它。第一个风险是与谷歌警报相比，用户不会获得相关或更好的点击。第二个风险是学习构建它的技术。
所以我们的第一个用户故事只是“作为一个用户，我想要相关的点击”，然后我们只在一组硬编码的页面和硬编码的过滤器上为一些早期用户构建了命中匹配算法，并得到了他们的反馈。
实际上，这里可能会有一些来回，有多个较小的故事来捕捉学习，例如“作为用户，我希望更多地优先考虑 URL 中的匹配”等。这些故事来自我们迭代内容时的反馈早期用户考虑“相关点击”。
接下来，我们将其扩展为“作为用户，我希望来自特定网站的点击”，我们构建了索引架构来抓取用户指定的网站并在其上进行点击匹配。
第三个故事是“作为用户，我想定义自己的过滤器”，我们构建了系统的这一部分。
通过这种方式，我们能够逐个构建架构。通过大部分初始部分，只有早期用户可以使用系统，并且许多数据被硬编码等。
过了一段时间，早期用户就可以完全使用系统了。然后我们添加了允许新用户注册的故事并向公众开放。
长话短说，你首先实现的故事只能实现最终故事的一小部分，硬编码和搭建其他一切。然后你可以随着时间的推移对其进行迭代，直到你得到你可能真正向公众发布的故事。
过去，我在这个问题上走到了十字路口。用户故事应该是孤立的，因此您可以在没有任何其他故事的情况下以任何顺序等方式完成它们。但我发现这样做只会让一切变得更加复杂。对我来说，这属于敏捷宣言的“个人和交互优于流程和工具”部分——或者至少是我对它的解释。
最终目标是船。并且要交付，您必须构建，并且构建您必须停止使用 scrum 并完成工作并确保您跟踪它。
所以我们所做的就是打破故事的基本规则，我们制作了一些技术故事，比如“创建初步模式”。我们还声明了一些故事依赖于其他故事，并在故事卡的背面注明了这一点。
最后我觉得这种类型的故事少之又少，而另一种选择的难度证明了例外的合理性。