将项目的第一个用户故事分解为任务

Question

我正在从头开始一个新项目，并编写了User Store来描述给定用户将如何与系统交互。但是，我很难理解如何将第一个用户故事分解成任务，而第一个故事不会成为史诗。

例如，如果我在造一辆车，第一个用户故事是这样说的：“作为一个司机，我希望能够改变运动的方向，这样我就不会撞到东西。”这意味着有一个用户界面(方向盘)，但也意味着运动(车轮)以及将这些连接在一起所需的一切(车轴、车架、连杆等)。最后，第一个用户故事似乎总是代表了项目的40%左右，因为它暗示了太多关于底层架构的信息。

你如何分解一个新项目的用户故事，使第一个故事不会成为代表整个底层架构的史诗？

Answer 1

你可能想把你的故事看作是系统的一个垂直部分。一个故事可能(并且通常会)触及系统的所有架构层中的组件。因此，您可能希望将您的任务视为，即在您的故事涉及到的每个组件上所需完成的工作。

例如，假设你有这样一个故事，为了能够很容易地关注我朋友的推文，作为一个注册用户，我想自动关注我所有有twitter账户的gmail联系人。

为了实现这一点，您必须通过UI层、服务层、持久化数据层中的一些数据，并对twitter和gmail进行API调用。

您的任务可能是：

• 在菜单中添加一个选项
• 添加新的gmail身份验证屏幕
• 添加twitter身份验证屏幕
• 添加联系人选择屏幕
• 添加调用到您的服务层的控制器
• 编写一个新服务来执行以下工作
• 将联系人保存到database
• Modify现有的gmail API调用服务以获取联系人
• 添加twitter API调用服务以关注所选联系人

这里:这里有9个可能的任务。现在，作为规则，您希望您的任务大约每天花费1/2到2天，偏向于一天(最佳实践，用于规模调整)。根据难度的不同，您可以将这些任务进一步分解，或者如果它们很容易组合在一起(可能这两个API调用服务非常简单，您只需要一个修改外部API服务)。

无论如何，这是一个如何分解故事的原始草图。

编辑：

为了回答更多关于将故事分解为任务的问题，我写了一篇关于它的博客文章，并想在这里分享它。我已经详细阐述了打破这个故事所需的步骤。链接是here。

Answer 2

当我们在Scrum管理风格下开始项目时，第一组任务总是宽泛的，或者正如您所描述的: epic。这是不可避免的，任何项目的框架通常是最重要、最大和最耗时的部分，但它支持项目的其余部分。为了减少压倒性的规模-有多少事情要做，看看你是否能列出最重要的部分。然后将这些任务定义为起点。因此，您有几个任务作为一个广泛的开始的起点。希望这是有意义的！

Answer 3

用户故事描述的是what，而任务更多的是关于how。

• 没有完美的公式，只需添加描述how将要实施、记录或测试的用户情景的任何任务即可。
• 请记住，任务应以小时为单位进行估计，因此请尝试相应地扩展和细化任务。

如果你觉得一个故事有太多的任务(即使你有1-8个小时的任务)，那么也许你应该首先考虑重写你的用户故事，因为它可能太复杂了。

祝好运