用户故事-无法生成用户故事的问题

Question

我来自XP背景。我非常了解这个过程，并有扎实的工作经验。我发现这是开发软件的最好方法。

我发现自己处于某种过程博士的位置，这就产生了很多自我检查和对我自己的理解的重新评估。

我听到的一件很常见的事是，有些作品不能写成故事。我个人不相信。借口包括

1. 它太大了(开发人员在5周前没有什么可展示的)。
2. 这是一个复杂的算法或抽象的概念(将需要5个星期的时间来编写，而没有任何显示)。

这个问题是为了获得提示，提示或建议。

我正在寻找关于如何解决这些问题和类似问题的提示、提示和建议(如果你能想到这些问题的话，还会有更多的建议)。

我将给出一个答案，这个答案包含了关于如何绕过那些不愿意写故事的用户/开发人员的信息，并给出了他们为什么不写故事的理由(我只列出了几个，还有更多)。

Answer 1

所以，基本上，你的问题是“如果人们声称一个任务对于用户来说太大了，不能分开，我能做什么？”

根据我的经验，几乎任何问题都可以解决。问他们是否可以实现一个简化的版本，省略高级特性，甚至在某些地方使用默认值；基本上，任何东西都可以在一次迭代中产生有意义的(即可测试的)结果。

记住:迭代的目的不是提供完整的功能，而是提供有用和可测试的功能。

这种分裂可能很困难，但它迫使你首先考虑你真正需要什么，这是非常有价值的。开发人员可能会为此而发牢骚(我经常这样做：-)，但这确实是必要的。将大任务分解成可管理的用户故事是所有敏捷方法的核心。

也就是说，如果任务真的、真的、真的不能分解(在研究环境中考虑复杂的数学算法，甚至需要几个星期才能理解基本知识)，那么迭代就太短了。迭代需要足够长的时间来产生有意义的结果。如果你的大部分问题都是如此困难以至于要花2-3个月才能完成任何事情，那就是你的迭代时间。但我从没见过这样的项目.

Answer 2

下面是我收集到的一些资源，这些资源可能会有所帮助：

• 分裂用户故事的模式
• 故事减重工具包
• 20种分裂故事的方法
• 拆分用户故事的方法

太大或太复杂，总有一种方法可以把故事写在饮食上(也许你不会在一次迭代中获得最终结果，但这并不意味着你不能，而且，嗯，会有不止一次迭代)。

Answer 3

不写故事的用户/开发人员

用户不应该写用户故事。他们不应该告诉你用户故事。你可以期待他们谈论他们是如何工作的，困扰他们的问题，以及他们想要做些什么来促进他们的日常工作。

轮到你的时候，你应该听他们的话并做笔记。如果他们允许，使用录音机或照相机。然后，当您重放所收集的信息并识别您所称的用户故事时，您会将其带回。您可以与团队讨论这些问题，当您达成协议时，您就有了开发中的目标用例。

开发人员扮演什么角色，取决于您。如果他们只是编码者，他们就不会参与这个过程。如果他们在一定程度上充当顾问，那么他们就会帮助定义用户故事。