我认为这将是一个更常见的问题,但我很难找到任何为我提供解决方案的方法。
我目前有一个用户故事,它有两个用户/角色。我想知道是否有一个最佳实践解决方案来分割这个故事,指出写用户故事是一门艺术,而不是一门科学。
场景:-有两种外部用户类型-卖家和买家。-买卖双方都希望了解即将举行的展览会的详细情况(出于各种原因,例如买方希望购买/研究,卖方可能想研究-如果他们正在出售,他们就会知道展览的情况)。
当前故事:作为卖方或买方,我想查看即将到来的展览的细节(地点/日期/时间),以便我可以参加展览。
有没有一种方法可以不概括角色,比如“潜在的参展人员”,或者创建一个“工作故事”,来编写用户故事呢?“当我想参观即将到来的展览时,我想看看展览的地点/日期/时间,这样我就可以参加展览了:在这个场景中,即使我把故事分开,最简单的解决方案也是一样的:在面向公众的地方列出即将到来的展览,并提供关于地点/日期/时间的详细信息。”
或者我应该对这个特定的故事概括两个确定的用户角色(卖主和购买者),或者在我的待办事项中使用用户故事和工作故事的混合。
(想法/评论/建议?)
编辑:我在搜索用户故事时也有同样的问题.我有一个用户故事,有关能够搜索产品的产品名称,然而,这是一个需要多种用户类型,即买方和卖方。
发布于 2019-11-25 11:32:20
你似乎已经回答了你自己的问题:
场景:-有两种外部用户类型-卖家和买家。
由此,我推断出您还有其他被认为是内部角色(例如,展览主持人、应用程序管理、.)。从本质上说,您将买方/卖方列为“外部用户类型”,因为这就是他们与其他用户角色的区别(根据我的推断)。
假设我的推断是正确的,这里的正确方法是定义“外部”和“内部”用户角色(在字典中,如果您还没有),然后您可以在相关的地方引用它们。
作为一个外部用户,我想查看即将到来的exhibitions的详细信息(地点/日期/时间),以便我可以参加展览。
为了推广这种方法:如果您需要引用一个抽象概念(在本例中是一组角色),就有必要命名抽象概念,这样您就可以引用它而不必担心它是否被理解了。
不要试图巧妙地找到一种迂回的方式来使它隐式地被理解,保持简单并使它明确地被理解(通过明确地定义这个概念)。
发布于 2019-11-25 14:42:42
你如何分裂这个故事取决于故事的大小。我认为有两种可能的选择。
第一个选择,也是我要从哪里开始的,是以一种包含两种用户类型的方式编写您的故事。一个例子可能是“作为一个潜在的展览参与者,我想查看即将到来的展览的活动细节,以便我可以参加展览。”然后,我将使用接受标准来定义哪些潜在的展览参与者,理想的映射到特定的用户角色或角色。我还将使用接受标准来确定事件的确切含义,以澄清地点、日期和时间。这就是我最初要向团队展示的内容。
基于对此的改进,团队可能会提出问题或关注。如果不同用户类型的处理方式有很大的相似之处,也许不把故事分开是有意义的。但是,如果有一些独特的工作需要完成,那么按照用户类型或其他方法将其划分为可以交付和评审的更小的故事也许更有意义。
就格式而言,将需求表达为用户故事、作业故事、用例并不那么重要。您的产品经理或开发团队可能会找到一种更好的格式。但这是对团队的讨论,以确保用户需求的表达方式对每个参与的人都适用。不过,同样的想法也适用--如果有必要的话,团队可以根据他们对故事的评估来评估分裂故事的不同方式。
发布于 2019-11-25 15:31:52
在不同的个别情况下,答案可能是不同的,所以让我们看看用户故事的用途来获得答案。
创建用户故事是为了响应健壮的规范文档,这些文档的目的是干净地传递,避免任何进一步的对话或澄清的需要。相反,用户故事的目的是提供足够的信息来促进团队和用户之间的对话。你的问题的答案可能是:“哪一种选择有利于更好的对话?”
如果它真的适用于每一个与会者完全相同,那么你可以概括。或者,在精化过程中,您、开发团队和利益相关者会问“如果用户是买方或卖方,这有什么不同?”
最后一件事:“作为一个,我想要,这样”的形式是不需要的用户故事。另一种形式对你的谈话会更好吗?
https://softwareengineering.stackexchange.com/questions/401589
复制相似问题