因此，如果用户故事很模糊，例如：
作为销售代表，我想获取联系信息，以便稍后跟进。
我什至不确定这是否是一个有效的用户故事，但我确信它足够接近。
然后是实现该用户故事的细节/任务。而且我确信“销售代表应该能够从一个文本框切换到另一个文本框。” 是要求之一。我们如何捕捉/跟踪这个？这是用户故事的一部分还是需要单独考虑？
问问题
987 次
6 回答
2
用户故事捕捉功能的本质，而不是细节，故事是对讨论的支持。
所以，为了回答你的问题，在讨论过程中会口头传达细节，因为面对面的讨论是最有效的沟通媒体。如果您觉得有必要，可以将详细信息作为卡片背面的注释（如果您使用卡片）或......如果您使用电子工具，在“注释”字段中捕获。实际上，我通常也使用“如何演示”字段来捕获关于如何在 sprint 演示中演示这个故事的高级描述，并使用非常简短的“注释”来记录任何其他信息、澄清、对其他来源的引用信息等（归功于 Henrik Kniberg 著名的索引卡生成器）。如果觉得这很方便，尤其是在使用可执行规范时。
PS：你的故事是完全有效的，在你的模板中包含好处是一个很好的做法（“作为一个角色，我想要采取行动，以便获得好处”）。
于 2009-10-06T21:44:22.420 回答
1
用户故事应该是 1 到 3 句话的简短陈述。
http://en.wikipedia.org/wiki/User_story
我希望能够从一个文本框切换到另一个文本框是另一个用户故事。
您可以在 www.rallydev.com 之类的工具或任何类型的任务跟踪工具（SharePoint、Excel 甚至......等）中跟踪这些内容。
接下来你要做的就是优先考虑。
于 2009-10-06T21:22:29.913 回答
1
只是粗暴地刺...
作为一名销售代表，
我希望使用键盘完成所有数据输入和导航，
这样我就不必把手从键盘上移开
（并且我们遵守可访问性指南）。
或者
作为一家企业，
我们希望我们的所有产品仅使用键盘输入即可完全使用
，以便我们可以向需要可访问软件的客户销售。
于 2010-02-01T00:24:59.060 回答
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
于 2009-10-06T21:21:32.087 回答
0
是的，这是我们也有很多问题。一方面，用户故事需要简洁，另一方面，所有细节都必须放在某个地方。
我们使用 XPlanner，并通过将简短描述放入用户故事的正文中来解决这个问题。然后我们使用 XPlanner 的“注释”功能（可以附加到用户故事的任意文本或文件）获取详细信息。
这样我们就可以向用户故事添加尽可能多的信息，而不会弄乱用户故事文本本身。如果您不想在 XPlanner 中拥有所有内容，也可以参考外部文档。
这种方法对我们来说效果很好。
于 2009-11-11T15:13:21.263 回答
0
同意其他人的观点，这是可行的故事，但捕获（派生的）需求可能在其他地方更好地捕获。
软件开发人员和业务类型熟悉不同的术语，一些人可能很容易理解的东西（数据结构）可能对另一个人毫无意义。用户故事是一种工具或方法，业务用户可以通过它传达一条消息作为扩展的起点（包括测试、细节等）。
口头交流可以是有效的，但有效性取决于接收者听到和理解信息含义的能力。这是口头交流可能失败的地方。 不同类型的交流提供或多或少的正式交流形式。声音交流是一种“非正式的交流方式”，它可能会导致信息被误解、误解和误解。就像小时候玩的游戏一样，一个孩子向另一个孩子耳语信息，另一个孩子告诉另一个孩子，直到所有人都听到......导致降级的消息。
于 2011-05-12T21:32:36.397 回答