我从Scrum开始。我已经读到了它，但作为一个新手，我对很多事情感到不舒服。
这些天我的团队正在开始创建一款新游戏。我们知道游戏的关键要素，但我们并不知道它们将如何运作。我希望团队花一到两周时间进行头脑风暴并定义元素的工作方式。作为一个例子，其中一个元素可以是一个片段网格，用户点击这些片段来销毁它们。
这可以转换为用户故事，还是这不是转换为用户故事的东西？我正在考虑以这种方式编写用户故事：＆＃34;作为一名玩家，我想知道当我与棋子网格互动时我能做些什么。有了这个要求，我可以证明在这个元素的设计阶段花费的时间。
我知道用户故事是产品所有者添加到待办事项中以为项目提供一些价值的东西。对于我来说，在设计阶段，这将提供价值，因为利益相关者在开始真正的开发之前会确切地知道事情是如何工作的。
提前致谢。
答案 0 :(得分：0)
用户故事应该代表实际用户的价值，而不仅仅是开发过程的一部分。从一个类似于＃34的故事开始;玩家玩游戏几轮＃34;或者只是＆＃34;玩家在棋盘上移动一块＆＃34;或者你认为适合一个冲刺的任何东西。在您的估算中包括所有团队成员，设计人员和开发人员所需的时间。当您实施该故事时，您将拥有真实最终用户所关心的内容。这将是可怕的，因为你刚刚开始，但你可以写更多的故事，以便在以后的短跑中解决。
答案 1 :(得分：0)
重要的是要记住，故事“提醒对话”并且产品积压不是静态的，而是随着时间的推移而发展。
让我们假设你从相对不精确的东西开始，因为“玩家可以摧毁放在网格上的碎片。”没有关于这意味着什么的细节。
当您到达Sprint计划会议时，产品负责人会指出这是优先级最高的项目，并且每个人都同意Sprint目标将找出销毁件的不同方法。你可以在这里进行两种方式，这取决于你对破坏碎片的了解程度。
如果您对如何实现这一点有一些想法，那么您可以在会议期间进行快速的头脑风暴会议。让我们说，结果，您确定了可以采用的3种不同方式。然后将原始故事分成3个部分，然后团队需要决定他们在冲刺期间可以实施的人数。在这里要认识到的重要一点是，您可以将这个早期实现视为一个实验，以便稍后为您提供更多信息以进一步完善这些想法。
如果您不知道如何做到这一点，您可以在sprint中添加“尖峰”。尖峰是一个时间盒实验，旨在收集信息以实现另一个故事。因此，从本质上讲，您将安排研究时间并推迟实施，但该研究是时间限制的，并且有望提供实施选项。