代码之家 › 专栏 › 技术社区 › Jonathan

用户情景-无法生成用户情景的问题[已关闭]

user-stories extreme-programming agile process

Jonathan · 技术社区 · 15 年前

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

我发现自己处于一个过程医生的地位,这创造了很多自我检查和我自己的理解的重估。

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

这个问题是为了得到提示、提示或建议。

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

我会在答案中标记出关于如何避开不写故事的用户/开发人员的信息最多的答案,并说明为什么不写故事的理由(我只列出了一些,还有更多)。

7 回复 | 直到 11 年前

sleske 15 年前

所以,基本上,你的问题是,“如果人们声称一个任务对于一个用户来说太大了,而且不能拆分,我该怎么做?”

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

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

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

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

Pascal Thivent 15 年前

以下是我随时间收集的一些资源,可能会有所帮助:

太大或太复杂,总是有一种方法把一个故事放在饮食上(也许你不会在一次迭代中获得最终结果,但这并不意味着你不能,而且,好吧,会有一次以上的迭代)。

Kris 15 年前

通常当你得到“它太大了”,他们真正说的是“我只是有一个模糊的想法,这应该如何工作”。您需要与他们一起工作,以便更好地定义它,直到可以将它分割成更容易管理的逻辑部分。

sleske 14 年前

不写故事的用户/开发者

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

轮到你的时候,你应该听他们的并做笔记。如果允许,使用录音机或照相机。然后,当您重放收集到的信息时,将其带回,并确定您所称的用户故事。您与团队讨论它们,当您达成一致时,您就可以在开发中确定用例的目标。

开发人员所扮演的角色由您决定。如果他们只是编码员,他们就不会参与这个过程。如果他们在某种程度上充当顾问,那么他们会帮助定义用户故事。

S.Lott 15 年前

“算法规范”问题很常见。

许多人喜欢编写代码,并不真正关心用户是谁或他们做什么。

我试着通过问这些问题让他们集中注意力。

此人可以采取什么行动?他们有什么可能做有信息吗?如果他们有责任,他们可以采取行动来拒绝,批准,保留,拒绝,再处理,停止,开始,一些事情。如果用户无法采取任何行动,您需要询问他们是否真的是利益相关者。
他们必须做什么决定?如何决定采取何种行动(如果有)?我们不能自动化这个决定——这就是为什么人在循环中。
此人需要哪些信息来决定采取行动。

信息决策行动。

我们只编写软件来为人们做决定准备信息,以便他们采取行动。

如果这不是重点,那么故事就失去了控制。

Nick Romedios 11 年前

它基本上是产品所有者的责任和义务。并且可能有任何需求/任务不能拆分为用户情景。我发现很多这样的讨论 SCrum Master Forums

Ajit Singh 11 年前

如果开发团队声称这个故事太大,不适合冲刺。根据他们的反馈,尝试将故事与“必须拥有”和“很好拥有”分开,并尝试以此为基础将其分开。