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

Question

我从头开始创建一个新项目并编写用户商店来描述给定用户如何与系统交互.但是,我无法理解如何在没有第一个成为史诗的任务中打破第一个用户故事.

例如,如果我正在制造汽车,并且第一个用户故事说"作为司机,我希望能够改变运动的方向,这样我就不会碰到东西.",这意味着用户接口(方向盘),还有运动(车轮)和将它们连接在一起所需的一切(车轴,车架,连杆等......).最后,第一个用户故事似乎总是代表项目的大约40%,因为它对底层架构意味着很多.

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

Answer 1

您可能希望将您的故事视为系统的垂直切片.故事可能(并且经常会)触及系统的所有架构层中的组件.因此,您可能希望将您的任务视为您的故事所触及的每个组件所需的工作.

例如,假设您有一个类似的故事为了能够轻松地关注我朋友的推文,作为注册用户,我想自动关注所有拥有Twitter帐户的Gmail联系人.

为了实现这一点,您必须通过UI层,服务层,在数据层中保留一些数据,并对twitter和gmail进行API调用.

您的任务可能是:

• 在菜单中添加一个选项
• 添加新的Gmail身份验证屏幕
• 添加Twitter身份验证屏幕
• 添加联系人选择屏幕
• 添加一个调用服务层的控制器
• 写一个完成工作的新服务
• 将联系人保存到数据库
• 修改现有的gmail API调用服务以获取联系人
• 添加Twitter API呼叫服务以关注所选联系人

那里:那里有9个可能的任务.现在,作为一项规则,您希望您的任务大约每天花费1/2到2天,偏向一天(最佳实践,大小调整).根据难度,您可以进一步细分这些任务,或者如果它们容易两个就结合一些(也许两个API调用服务非常简单,您只需要修改外部API服务).

无论如何,这是如何打破故事的原始草图.

编辑:

在回答有关将故事分解为任务的主题的更多问题时,我写了一篇关于它的博客文章,并希望在此处分享.我已经详细说明了打破故事所需的步骤.链接在这里.

Answer 2

当我们以Scrum管理风格开始项目时,第一组任务总是很广泛,或者正如你所描述的那样:史诗.这是不可避免的,任何项目的框架通常都是最重要,最大和最耗时的部分,但它支持项目的其余部分.为了减少压力,要确定你能列出最重要的部分.然后将定义这些任务作为起点.因此,您有一些任务作为广泛开端的起点.希望有道理!