我们如何跟踪用户故事的细节?

时间:2009-10-06 21:09:23

标签: requirements user-stories

因此,如果用户故事像一个模糊不清的东西:

作为销售代表,我想捕获联系信息,以便我可以在以后跟进。

我甚至不确定这是否是一个有效的用户故事,但我确信它足够接近。

然后有实现该用户故事的细节/任务。 我确信“销售代表应该能够从一个文本框切换到另一个文本框。”是要求之一。我们如何捕获/跟踪这个?这是用户故事的一部分还是需要单独考虑的事情?

6 个答案:

答案 0 :(得分:2)

用户故事捕捉特征的本质,而不是细节,故事是对讨论的支持。

所以,为了回答你的问题,在讨论期间口头传递细节,因为面对面的讨论是the most effective communication media。如果您认为有必要,可以使用电子工具将详细信息记录在卡片背面(如果您使用的是卡片)或...在“ notes ”字段中。实际上,我通常也使用“如何演示”字段来捕捉关于如何在sprint演示中演示这个故事的高级描述,并使用非常简短的“注释”来获取任何其他信息,澄清,参考其他信息来源等(Henrik Kniberg着名的Index card generator)。如果发现这非常方便,特别是在使用可执行规范时。

PS:您的故事完全有效,并且将优势包含在您的模板中是一种很好的做法(“作为角色,我希望行动以便益处“)。

答案 1 :(得分:1)

用户故事应该是1到3个句子的简短陈述。

http://en.wikipedia.org/wiki/User_story

我希望能够从一个文本框到另一个文本框中的标签是另一个用户故事。

您可以在www.rallydev.com等工具中跟踪这些内容,或者只使用任何类型的任务跟踪工具(SharePoint,Excel甚至等等)。

你要做的下一件事就是优先考虑。

答案 2 :(得分:1)

刚刚采取粗略刺伤......

  

作为销售代表,
  我希望使用键盘来完成所有数据输入和导航   这样我就不必把手从键盘上移开了   (以便我们遵守辅助功能指南)

  

作为一个企业,
  我们希望所有产品仅使用键盘输入即可完全使用   这样我们就可以向需要可访问软件的客户销售产品。

答案 3 :(得分:0)

第一部分属于“业务需求”文档(通常由业务分析师编写)。本文档的第一代版本非常高,但最终版本(稍后几次迭代)非常详细。

http://www.tdan.com/view-articles/6089

第二部分(关于标签)是另一个文档的一部分 - “UX规范”(显示所有屏幕并描述用户交互)。这个通常由不同的人/团队(产品或用户体验团队)编写。

http://uxdesign.com/ux-defined-2

http://www.uxmatters.com/mt/archives/2007/05/sharing-ownership-of-ux.php

答案 4 :(得分:0)

是的,这是我们也有很多问题。一方面,用户故事需要精心设计,另一方面,所有细节必须放在某处

我们使用XPlanner,我们通过将简短描述放入用户故事的文本主体来解决这个问题。然后我们使用XPlanners“notes”功能(任意文本或可附加到用户故事的文件)来获取详细信息。

通过这种方式,我们可以根据需要为用户故事添加尽可能多的信息,而不会使用户故事文本本身变得混乱。如果您不想在XPlanner中拥有所有内容,也可以参考外部文档。

这种方法对我们很有效。

答案 5 :(得分:0)

与其他人一致认为这是可行的故事,但捕获(衍生)的要求可能会更好地在其他地方捕获。

软件开发人员和业务类型熟悉不同的术语,一些人可能很容易理解(数据结构)可能对另一个人没有任何意义。用户故事是一种工具或手段,业务用户可以通过该工具或手段传达消息作为扩展的起点(包括测试,详细信息等)。

口头交流可能是有效的,但有效性取决于接收者听到和理解信息含义的能力。这是口头交流失败的地方。 Different types of communication提供或多或少正式的沟通方式。声音交流是一种“非正式的交流形式”,它可能会使信息被误导,误解和误解。就像孩子玩的游戏一样,一个孩子向另一个孩子传达信息,告诉另一个孩子,直到所有人都听到了......当最后一个孩子告诉小组时,它通常被误解,然后再被误解,导致降级的消息。

相关问题