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

Question

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

project-managementagilescrumuser-stories

44

我正在从零开始启动一个新项目，并编写用户故事来描述给定用户如何与系统交互。但是，我现在遇到了一个问题，就是不知道如何将第一个用户故事分解成任务，而又不让它变成史诗般的大型任务。

例如，如果我正在制造一辆汽车，第一个用户故事可能会说：“作为司机，我希望能够改变运动方向，以避免碰撞。”这似乎意味着需要一个用户界面（方向盘），但也意味着涉及到运动（轮子）和所有必要的连接（轴、框架、链接等）。最终，第一个用户故事似乎总是代表整个项目的40％，因为它涵盖了很多关于底层架构的内容。

对于一个新项目，如何拆分用户故事，使得第一个用户故事不会成为代表整个底层架构的史诗任务？

- PaulH

1

我投票将此问题关闭，因为它涉及组织实践，而不是编程。 - Kristján

1

我投票关闭此问题，因为它与编程无关。 - Vadim Kotov

3

我投票关闭此问题，因为它不属于此网站的主题，应该发布在 pm.stackexchange.com 上。 - Sudhir Jonathan

5个回答

5

当我们采用Scrum管理风格启动项目时，第一组任务总是很宽泛，或者正如你所描述的那样：史诗级的。这是不可避免的，任何项目的框架通常都是最重要、最大和耗时最长的部分，但它支撑着整个项目。为了缩小任务规模以避免不堪重负的感觉，请尝试列出最基本的部分。然后，将这些任务定义为起点进行工作。因此，您有几个任务作为广泛开始的起点。希望这能让您明白！

- Aaron

3

一个用户故事描述了“什么”，而任务更多关注于“如何”。

没有完美的公式，只需添加任何描述如何实现、记录或测试用户故事的任务。
请记住，任务应该估计完成所需的小时数，因此尝试按比例缩放和详细说明任务。

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

祝好运！

- plus-

如果已经有一个系统存在，这些用户故事就不会那么复杂。只有因为我们是从头开始，它们才变得复杂。如果你已经有一辆能动的汽车，加上一个方向盘并不是什么大问题。（只需要方向盘、柱和连杆）故事之所以变得复杂，是因为轮子、轴和框架还不存在。 - PaulH

是的，但如果你觉得故事太史诗般，估算值太大，你应该尝试缩小第一次迭代的功能。以你的例子为例，你可以从单轮自行车上添加一个轮子开始，然后再添加一个链条自行车上的轮子等等，然后在下一次迭代中添加一个带有动力的电机驱动轮子的摩托车等等，然后将汽车轮添加到带有制动器等所有设备的汽车中，等等... - plus-

3

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

例如，在最近的一个项目中，我们需要开发一个应用程序，其中涉及索引各种网站，并将它们与用户创建的过滤器进行匹配，最后向用户报告匹配结果（可以将其视为强化版的Google Alert）。

如果从一个角度看，只有一个故事 -“作为用户，我想从匹配页面获得警报”。但是，从“我们要减轻哪些风险”的另一个角度来看，第一个风险是用户无法获得与Google Alert相比的相关或更好的结果。第二个风险在于学习构建此技术。

因此，我们的第一个用户故事很简单-“作为用户，我希望获得相关命中”，然后我们仅为某些早期用户提供了硬编码页面和硬编码过滤器的命中匹配算法并获得了他们的反馈意见。

实际上可能会有一些来回的交流，以捕捉像“作为用户，我希望在URL中给予匹配更高的优先级”之类的多个较小的故事。这些故事来自于我们迭代早期用户所认为的“相关命中”。

接下来，我们扩展到“作为用户，我希望从特定网站获得结果”，并建立了爬取用户指定站点并在其上进行匹配的索引架构。

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

通过这种方式，我们能够逐步构建架构。在最初的大部分时间里，只有早期用户可以使用该系统，并且许多数据片段都是硬编码的等等。

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

- Siddhi

我对这种方法唯一的问题是它涉及到一些不会出现在最终系统中的工作：那些硬编码表示尚未被架构化的部分。我更愿意始终向前推进，而不是采取侧步的方式来满足Scrum每个迭代结束时都有一个可用产品的理念。但是，也许这是不可避免的。 - PaulH

5

保罗，这并不是为了达到Scrum的理想。我并不太在意那个。而是为了让你能够构建系统的小部分并与用户一起测试和迭代它们。否则你可能会先构建整个基础架构，然后得到需要对架构进行根本性改变的反馈。这样你可以一步步地构建它。 - Siddhi

1

我曾经在这个问题上陷入了两难境地。用户故事应该是独立的，这样你就可以按任何顺序完成它们，而不需要其他故事的干扰等。但我发现这样做只会让一切变得更加复杂。对我来说，这属于敏捷宣言中“个体和交互高于流程和工具”的部分，或者至少是我的理解。

最终目标是交付。为了交付，你必须构建，为了构建，你必须停止纠缠于Scrum，只需完成任务并确保跟踪即可。

因此，我们打破了一个关键规则，制定了一些技术故事，例如“创建初步架构”。我们还声明了一些故事依赖于其他故事，并在故事卡的背面注明了这一点。

最终，我觉得这种类型的故事很少见，而且选择例外情况的困难也证明了这一点。

- Jody

如果你所谓的“停止耍弄”Scrum，意思是只要开始做并且边做边改进，我同意。问题在于“技术故事”，你最终会做一些本身没有价值的东西。产品负责人确实应该投资于学习如何垂直划分系统。一个技巧是看UI层并确定要完成的任务。那通常就是你故事的基础。因此，如果你有一个登录页面，就要编写一个登陆故事。如果你在填充故事的“As a”和“In order to”部分时遇到困难，那么这可能表明这不是一个有价值的追求。 - Assaf Stone

说得好。我也同意首先尝试垂直拆分。但是，在某些情况下 - 也许如果这是您的第一个项目，并且您没有基础设施 - 您可能需要做一些基本的事情来支持系统可能具有的每个/任何功能。为了更好地跟踪事物，像安装/设置SQL服务器之类的故事可能是可以接受的。 - Jody

1

我通常建议，在开始开发“产品”的第一个故事时，在产品规划期间估算其大小（使用故事点），就好像您只需将其添加到现有系统中一样。然后，在冲刺规划中将其拆分，并包括由于它是第一个故事而需要的所有任务，并在理想小时数内估算这些任务。这样可以从各个方面保护您：故事相对大小，完成所需的所有工作方面都得到了考虑。 - Assaf Stone

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Assaf Stone · Accepted Answer

你可以将你的用户故事看作是系统的垂直切片。一个用户故事可能会（通常也会）涉及到系统所有架构层面的组件。因此，你可能需要将你的任务视为 与你的用户故事相关联的每个组件所需完成的工作。

例如，假设你有一个用户故事：作为已注册用户，我想要自动关注所有拥有Twitter账户的我的Gmail联系人，以便轻松地跟踪我的朋友的推文。 为了实现这个用户故事，你将需要经过UI层、服务层，保存数据到数据层，并调用Twitter和Gmail的API。

你的任务可能包括：

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

这里列出了9个可能的任务。一般来说，你希望你的任务大致需要花费0.5天到2天的时间，最好是1天左右（通常是估算大小的最佳实践）。根据难度的不同，你可能需要进一步细分这些任务，或者将一些任务合并在一起（例如，也许两个API调用服务非常简单，你只需要一个修改外部API服务）。

总之，这是一个关于如何将用户故事拆分成任务的基本框架。 编辑： 鉴于我在如何将用户故事拆分成任务方面收到了更多的问题，我写了一篇博客文章，并想在这里分享。我详细说明了拆分用户故事所需的步骤。链接在这里： here。