在项目开始时分解一个复杂的故事

我正在尝试与敏捷项目管理（使用Pivotal Tracker）打交道，但是在尝试定义项目的前几个故事时，总是发现自己陷入困境。以这个非常简单的故事为例：

“用户应该能够标记产品”

假设我已经在其他地方定义了“产品”，那么这个故事可能涉及在幕后编写一个多态标记系统，该系统ID完成后就可以最终添加标记产品的功能。

我的问题是这个故事中隐藏的工作量很大。我可以定义任务来完成故事，但整个故事应该工作1-2天？我只为揭示冰山一角而感到不对，但那是与用户有关的唯一部分。

您如何克服这种事情？最佳做法是什么？

更新25/08感谢所有人的指导，我已采纳了有关如何定义故事的所有建议。我现在切换到Jira Grasshopper，它对故事中的任务（分配，估计等）和冲刺开始后的开发任务有更好的支持。

如果您的故事需要每个开发人员工作1至2天，那么也许您应该将每个故事分解为特定的用户任务，这些用户任务需要 1至2天的开发人员工作。

考虑以下“用户故事”：

用户应该能够从购买的产品中收到发票。

考虑一下数据库设计中涉及的内容，才能为用户提供此功能。您需要一个客户表，一个发票标题表和一个发票行项目表，而我们甚至还没有谈到接受付款。

实际上，用户故事并非如此简单。完整的用户案例包括所涉及的用户步骤的演练：

• 用户将产品放入购物车
• 用户指定数量
• 用户指定运输类型

等等。简而言之，您需要将用户故事细分为更详细的信息。

故事不应该是“ 1-2天工作”。在Scrum中，故事通常使用Story Points（相对规模系统）进行估算。如果您使用规划扑克故事，则将获得一个点值-故事实施所需的时间取决于您团队建立的速度。

如果您认为该故事隐藏了复杂性（可以将其称为史诗故事），则应将其分解为较小的故事。确保新故事遵循INVEST标准。

但是您可能对此进行了过度设计。YAGNI的XP原理在这里适用。明确地说，除非确实需要，否则不应实现“幕后的多态标记系统”。即使这样，也应该通过改进现有系统来进行设计，而您已经开发了一套具有良好测试功能的系统。

如果确定您确实需要此复杂的标记系统，则应在单独的故事中指出这种复杂性。迈克·科恩（Mike Cohn）将设计方法描述为“ 有意而又紧急 ”

看来您在混淆故事和任务。

用户故事

用户故事是一个完整的“功能”，当添加到产品中时，便可以为产品提供更多价值。

用户故事不应大于在sprint期间可以实现的故事。在sprint计划的第一部分中，您决定要在sprint期间处理哪些用户故事。冲刺的目的是完成这些用户案例，从而为产品增加更多价值。

任务

在sprint计划阶段的第二部分中，开发人员将故事分为任务。这些任务是开发任务。它们可能是诸如“向数据库添加列”，“扩展服务x”之类的东西。任务的大小不能超过一天之内可以完成的任务。

在日常Scrum期间，您评估这些任务的进度。如果一项任务的日常执行已经超过一个工作日，那么它将花费太长时间，并且您作为一个团队有责任解决这种情况。

请记住，用户故事代表着利益相关者的商业价值。利益相关者应该对用户故事的完成感兴趣，而不是任务。

任务划分是开发团队管理sprint，监视sprint期间用户故事进度以及可视化潜在问题的工具。

利益相关者不应该关注这些开发任务。不幸的是，根据我的经验，他们经常这样做，尤其是对于刚接触敏捷开发的组织。但是，处理这种情况是另一回事。

史诗

如果用户故事超出了您的想象，您可以在一个冲刺中完成它，那么这就是史诗。在团队开始工作之前，它需要分为几个较小的用户故事。

请记住，用户故事会为最终用户增加价值，因此将史诗分成“前端”和“后端”故事并不是正确的方法。为新功能添加后端本身并不能为最终用户提供价值。

如果您没有经验，将史诗分成可在冲刺时间范围内管理的用户故事并不总是那么容易。

使用枢轴跟踪器

我认为Pivotal Tracker是跟踪用户故事的好工具。但是，它本身并不是一种Scrum工具，而且，Scrum教授如何将故事划分为任务的方法也不容易被关键跟踪器处理。您可以启用将任务添加到用户故事的功能。但是，如果您正在使用Scrum运行项目，我建议您使用白板和便笺来跟踪sprint期间任务的进度。

实施多态标记系统的设计目标很好，但是您仍应专注于实现客户所需的功能。这可能意味着，按细粒度的用户故事，按细粒度的用户故事，随着时间的推移，您的系统将演变为具有多态标记系统。但是，在此过程中的任何时候，您都应该拥有由许多小而可测试的功能组成的系统，这些功能由您已实现的一系列用户故事来描述。

在这种情况下，听起来您系统中的“标记产品”可能是史诗级的，即比单个用户故事大得多的东西，并且可以不费吹灰之力分解为几个较小的故事。通过大量的艺术许可，我可以想到以下用户故事，这些故事可能大致适用于您的要求：

• 作为系统管理员，我想为系统添加一些有效的标签，以便用户在首次使用标签功能时可以选择一些值。
• 作为系统的用户，我希望能够按名称搜索产品，以便以后可以对其进行标记。
• 作为系统的用户，我希望能够阅读产品的说明，以便我可以决定产品应具有的标签。
• 作为系统的用户，我希望能够看到产品的图片，以便我可以决定产品应具有的标签。
• 作为系统的用户，我希望能够将单个标签附加到单个产品。
• 作为系统的用户，我希望能够从单个产品中删除单个标签。
• 作为系统的用户，我希望能够将单个标签附加到多个产品。
• 作为系统的用户，我希望能够将多个标签附加到一个产品上。
• 作为系统管理员，我想查看系统中正在使用的标记的不同列表，以便我可以确定它们是否重复。
• 作为系统管理员，我想合并重复的标签。

...然后我可以继续。

我怀疑其中的任何一种都将栩栩如生，以至于您无法使用它们，但是希望它们能说明您可以使用“用户故事”进行的详细说明。

如果确实无法将用户故事细分为任何较小的故事，而您仍然认为它太大而无法尝试一次实施，则可以将其划分为垂直切片。这是一项技术，意味着在每个用户故事下仅提供部分功能，但是每个部分都是该技术所有相关层中的可测试部分，例如，对于网站而言，这可能意味着更改数据库，应用程序和UI层。避免为数据库工作使用一个用户故事，对于应用程序使用另一个用户故事，对于UI使用另一个用户故事，因为这些故事无法单独测试。

如果获得更多的艺术许可，我可能会拆分“作为系统用户，我希望能够将单个标签附加到单个产品上。” 分为以下垂直切片：

• 当系统的用户查看单个产品时，我希望能够查找标签列表，以便我可以决定应用哪个标签。
• 当系统的用户查看单个产品时，已经确定要应用于该产品的标签，因此我希望能够应用它。
• 当系统的用户查看单个产品并将标签应用于该产品时，我希望屏幕上显示一条确认消息，告诉我该产品已成功保存。

其中的每一项都是可以测试的-即使本身没有特别的价值。

有一些书籍的唯一目的是找出描述和分解需求的正确方法。因此，这不是一件容易的事。

通常，我发现开发团队正在努力寻求复杂的解决方案，而不是最简单的解决方案。这可能是由于故事本身造成的，或者是因为团队希望寻求一个过于复杂的解决方案，该解决方案不仅可以解决该故事，而且还为故事x，y和z奠定了基础。这是好主意，但可以用更少的工作来完成相同的工作。总是很难判断一个故事要投入多少设计，才能不弄乱设计来破坏未来的故事。该决定由团队做出。

作为产品所有者，您只能通过将故事分解为较小的部分来影响这一点。您应该问自己：这个故事是我们现在能想到的最小解决方案吗？我们能否将其分解为简化的功能集，以使某天成为“我一直想要的大型灵活标记系统”。您可以从仅用于单个标签的标签系统开始，然后将其扩展为包括预选标签列表，然后让用户定义标签等。

对于开发团队来说，它可以归结为：我们可以找到一种更简单的方法来实现故事，但仍然拥有一个可靠的体系结构，该体系可以在不影响未来功能的前提下完成今天的工作。

如果您愿意接受中间解决方案，并且开发团队也尝试提供最简单但又很好的解决方案，那么您可能会发现最适合的故事情节是正确的（越小越好） 。这并不是说您只有小故事。有些比其他大，这仅仅是您需要接受的事实，或者如果它们太大，则将故事分解成较小的部分。