将项目的第一个用户故事分解为任务[关闭]答案

【问题标题】：Breaking a project's first User Story in to tasks [closed]将项目的第一个用户故事分解为任务[关闭]
【发布时间】：2011-12-20 08:18:39
【问题描述】：

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

例如，如果我正在制造一辆汽车，而第一个用户故事说“作为一名驾驶员，我希望能够改变运动方向，这样我就不会撞到东西。”，那将意味着用户界面（方向盘），也包括运动（轮子）以及将它们连接在一起所需的一切（轴、框架、连杆等）。最后，第一个用户故事似乎总是代表项目的 40% 左右，因为它暗示了很多底层架构。

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

【问题讨论】：

我投票结束这个问题，因为它涉及组织实践，而不是编程。
我投票结束这个问题，因为它与编程无关。
我投票结束这个问题，因为它属于 pm.stackexchange.com

标签： project-management agile scrum user-stories

【解决方案1】：

您可能希望将您的故事视为系统的垂直部分。一个故事可能（并且经常会）触及系统所有架构层中的组件。因此，您可能希望将您的任务视为需要在故事涉及的每个组件上完成的工作。

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

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

你的任务可能是：

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

那里：那里有 9 个可能的任务。现在，作为一项规则，您希望您的任务大约每天花费 1/2 到 2 天，并且偏向于一天（最佳实践，用于调整大小）。根据难度，您可能会进一步分解这些任务，或者如果它们是两个简单的则组合一些（也许这两个 API 调用服务非常简单，您只需 修改外部 API 服务） .

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

编辑：

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

【讨论】：

这说明了我的问题。您的第一个故事（作为系统的垂直部分）需要您实现很多系统。这使它成为一个非常大（史诗）的故事。也许这就是@Aaron 建议的方式。
我不认为这会迫使您实现系统的大部分。它[通常]要求您触摸（即修改、扩展或添加）系统的每一层，但这是否是系统的大部分取决于系统。在我的系统中，自动关注功能可能只是社交聚合器应用程序的一小部分。可以认为，在 200 分系统中可能有 5 个故事点（或者，如果您更喜欢在理想的日子里思考，那么团队可能需要 3 天的时间来实施 3 个月的发布）。
这正是我现在面临的问题。一个人如何从零代码变成有用的东西。 IMO，前几个冲刺必须定义您的基础设施和架构。也许不完全，但那里必须有一些东西。如果这些组件不存在，我如何判断组件如何受用户故事的影响？对我来说，这是不可能的。我们过去所做的是创建一些系统故事。那定义了那种东西。这样就可以清楚地区分工作的位置。
在使用系统故事时，我总是被告知“你没有做敏捷”，对此我的回应是……“嗯”。这是关于完成工作的任何事情。
敏捷架构的特点是它总是在不断发展，而不是预先计划或在最初的几个冲刺中完成。在从零到价值的情况下，我建议您查看用户故事、验收标准（约束、UAT 等）并得出所需的最低架构。制作一个小的架构草图，概述这个故事所需的组件，然后您可以相应地分解任务。您的组件会随着时间的推移而移动、更改和发展，但这是一件好事。重要的是关注价值，而不是系统。

【解决方案2】：

您一开始实施的故事可以随着时间的推移而完善。您不需要认为每个故事都必须是用户将要使用的最终版本。

例如，在最近的一个项目中，我们必须开发一个应用程序，该应用程序涉及索引各种网站，并将它们与用户创建的过滤器进行匹配，最后提醒用户匹配项（类似于 google 类固醇警报）。

如果你从一个角度来看，只有一个故事——“作为用户，我想从匹配的页面中获取警报”。但是从“我们想要减轻的风险是什么”的另一个角度来看待它。第一个风险是与谷歌警报相比，用户不会获得相关或更好的点击。第二个风险是学习构建它的技术。

所以我们的第一个用户故事只是“作为用户，我想要相关的点击”，然后我们在一组硬编码的页面和硬编码的过滤器上为一些早期用户构建了点击匹配算法，并获得了他们的反馈。

实际上可能会有一些来回的故事，其中包含多个较小的故事来捕捉学习，例如“作为用户，我希望 URL 中的匹配项获得更多优先权”等。这些故事来自我们的反馈迭代早期用户认为的“相关点击”。

接下来，我们将其扩展为“作为用户，我希望从特定网站获得点击”，并且我们构建了索引架构来抓取用户指定的网站并对其进行点击匹配。

第三个故事是“作为用户，我想定义自己的过滤器”，我们构建了系统的这一部分。

通过这种方式，我们能够逐步构建架构。通过大部分初始部分，只有早期用户可以使用系统，并且许多数据被硬编码等。

过了一段时间，早期用户就可以完全使用系统了。然后，我们添加了故事以允许新用户注册并向公众开放。

长话短说，您首先实现的故事只能实现最终故事的一小部分，硬编码和搭建其他所有内容。然后你可以随着时间的推移对其进行迭代，直到你得到你可能真正向公众发布的故事。

【讨论】：

我对这种方法的唯一问题是它涉及到一些最终系统中不会出现的工作：那些被硬编码以表示尚未构建的部分的位。我宁愿总是向前迈进，而不是为了满足 Scrum 的理想，即在每次迭代结束时都有一个工作产品。但是，也许这是不可避免的。
保罗，它不符合 Scrum 的理想。我真的不在乎那个。这样您就可以构建系统的一小部分并与用户 测试它们并对其进行迭代。否则，您可能会构建整个底层架构，然后获得涉及架构根本变化的反馈。这样你就可以一块一块地构建它。

【解决方案3】：

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

没有完美的公式，只需添加任何描述 how 的任务即可实现、记录或测试用户故事。
请记住，任务应该以小时为单位进行估算，因此请尝试相应地缩放和详细说明任务。

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

祝你好运

【讨论】：

如果已经有一个系统，这些用户故事就不会那么复杂了。只是因为我们重新开始，它们才变得复杂。如果您已经拥有一辆可以移动的汽车，那么添加一个方向盘就没什么大不了的。（只是方向盘、立柱和连杆）轮子、车轴和车架还不存在的事实让故事变得宏大。
是的，但是，如果您觉得故事太史诗并且后续估计太大，您应该尝试缩小第一次迭代的功能。以您的示例为例，您将从向单轮自行车添加轮子开始，而不是向带有链条等的自行车添加轮子，然后在接下来的迭代中继续向摩托车添加轮子，并使用电机为轮子等提供动力，比一个车轮变成一辆有刹车的汽车等等……

【解决方案4】：

我过去曾遇到过这个问题。用户故事应该是孤立的，因此您可以在没有任何其他故事的情况下以任何顺序等方式完成它们。但我发现这样做只会让一切变得更加复杂。对我来说，这属于敏捷宣言的“个人和交互优于流程和工具”部分——或者至少是我对它的解释。

最终目标是船。并且要交付，您必须构建，并且构建您必须停止使用 scrum 并完成工作并确保您跟踪它。

所以我们所做的是打破故事的基本规则，我们制作了一些技术故事，例如“创建初步架构”。我们还声明了一些故事依赖于其他故事，并在故事卡的背面注明了这一点。

最后我觉得这种类型的故事很少见，而且替代方案的难度证明了例外是合理的。

【讨论】：

如果你所说的“停止使用 Scrum”，你的意思是去做，并随着你的进步而改进，我同意。问题在于“技术故事”，你最终会做一些本身没有价值的事情。 PO 确实应该投资于学习如何垂直划分系统。一个技巧是查看 UI 层，看看应该完成什么。这通常是你的故事的基础。因此，如果您有一个登录页面，那么您就有了一个可供登录的故事。如果您在填写 as a 和 in order 部分故事时遇到问题，您可能有迹象表明这不是有价值的追求。
说得好。我也同意应该首先尝试垂直拆分。但是，在某些情况下——也许这是你的第一个项目，并且你没有基础设施——你可能需要做一些基本的事情来支持系统可能具有的每个/任何功能。为了更好地跟踪事情，像 - 安装/设置 sql server 这样的故事可能没问题。
在开始开发产品的第一个故事时，我经常建议的是估计它的大小（使用故事点）在产品规划期间，好像您只需将其添加到现有系统。然后，在 sprint 计划 中分解它时，包括由于它是第一个故事而需要的所有任务，并在理想时间估计那些。这涵盖了各个方面：故事的规模相对较大，完成它所需的工作的各个方面都被考虑在内。

【解决方案5】：

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

【讨论】：