用户故事可以是信息请求吗？ [关闭]

Question

我从 Scrum 开始。我读过它，但作为一个新手，我对很多事情感到不舒服。

这些天我的团队正在开始创建新游戏。我们知道游戏的关键元素，但我们并不真正知道它们将如何真正发挥作用。我希望团队花 1 到 2 周的时间进行头脑风暴并定义元素的工作方式。例如，其中一个元素可以是一个网格，用户可以在其中单击这些碎片来销毁它们。

这是否可以转换为用户故事，或者这不是可以转换为用户故事的东西？我正在考虑以这种方式编写用户故事：“作为一名玩家，我想知道当我与棋子网格交互时我能做什么”。有了这个要求，我可以证明在这个元素的设计阶段花费的时间是合理的。

我知道用户故事是产品所有者添加到待办事项列表中的内容，以便为项目提供一些价值。对于处于设计阶段的我来说，这将提供价值，因为利益相关者会在开始真正的开发之前确切地知道事情是如何运作的。

提前致谢。

Answer 1

用户故事应该代表实际用户的价值，而不仅仅是开发过程的一部分。从一个故事开始，例如“玩家玩游戏几回合”或只是“玩家在棋盘上移动一块”或任何您认为适合一次冲刺的故事。在您的估计中包括所有团队成员、设计师和开发人员做出贡献所需的时间。当您实现了该故事时，您将拥有真正的最终用户会关心的东西。这会很糟糕，因为你才刚刚开始，但你可以写更多的故事来解决这个问题。

Answer 2

重要的是要记住，故事是“对话的提醒”，并且产品待办事项不是静态的，而是随着时间的推移而发展的。

假设您从相对不精确的内容开始，例如“玩家可以摧毁放置在网格上的棋子”。尚无关于这意味着什么的详细信息。

当您到达 Sprint 计划会议时，产品负责人表示这是最高优先级的项目，并且每个人都同意 Sprint 的目标将是找出不同的方法来破坏零件。您可以在这里进行两种方式，具体取决于您对破坏碎片的了解程度。

如果您对如何实现这一点有一些想法，您可以在会议期间进行一次快速的头脑风暴会议。假设您因此确定了可以完成此操作的 3 种不同方式。然后将原始故事分成 3 部分，然后团队需要决定他们可以在 sprint 中实施多少部分。在此需要意识到的重要一点是，您可以将此早期实施视为一个实验，稍后将为您提供更多信息以进一步完善这些想法。

如果您不知道如何做到这一点，您可以在 sprint 中添加一个“尖峰”。尖峰是一个有时间限制的实验，旨在收集信息以实现另一个故事。因此，从本质上讲，您是在安排研究时间并推迟实施，但研究是有时间限制的，并有望提供实施选项。