我正在尝试学习如何在我们的开发过程中使用 BDD，有时我最终会写一些暗示 UI 设计的东西，因此对于全新的开发或新功能，UI 并不总是存在。
例如，如果我在“单击列标题时”的场景中这样说，则意味着此功能基于某种表格或网格，但此时我们仍然只是编写用户故事，因此没有 UI然而。
这让我很困惑，不知道我们在这个过程中的哪个阶段提出了 UI 设计？
请记住，我只阅读过有关 BDD 的文章，我认为这会对我们的团队有很大帮助，但在这方面还是很新的！谢谢！
问问题
970 次
4 回答
5
如果您编写的场景侧重于系统的功能，您将能够更轻松地重构这些场景中的底层步骤。它使他们保持灵活。所以我会问 - 单击该列对您有什么好处？你在选择什么吗？你打算怎么做？您是否正在搜索某些内容并按值排序？
我喜欢看到这样的场景：
- 当我寻找条目时
- 当我去看一月份的日记时
- 当我查看最新条目时
- 当我看到同样的黑色T恤
这些都可能涉及单击列标题，但实现细节并不重要。这是系统的能力。
在这些高级场景和步骤下，我喜欢创建一个带有较小步骤的屏幕或页面，例如单击其中的按钮。这使得重构变得容易。
我是用 DSL 而不是英语写的，但它的工作原理是一样的——你无法从步骤中分辨出它是 GUI 还是网页，并且其中一些步骤涉及多个 UI 操作：
希望你觉得它很有趣，也许它会有所帮助。祝你好运！
于 2010-08-18T18:26:03.500 回答
0
我想您可以通过说“当我按 X 对信息进行排序时，然后……”来解决这个问题，但是您必须调整您的方案以删除以网格格式显示的数据的任何提及，这可能导致一些相当迟钝的写作。
我认为尽快开始 UI 设计是个好主意。在你上面提到的情况下，我认为用你想象的相关 UI 的草图来增加用户故事是完全有效的，然后随着你的进行而改进它。一张纸上的铅笔素描应该没问题。或者，如果您想要全数字化的东西，您可以使用平板电脑和SketchBook Pro 。
我的观点是，我没有看到 UI 设计被排除在用户故事之外的真正原因。您可能已经知道您将构建一个 Windows、WPF 或 Web 应用程序。并且可以安全地假设当您想要显示表格数据时，您将使用网格。将这些假设排除在需求之外会混淆它们，而不会增加任何实际价值。
于 2010-08-17T21:34:00.543 回答
0
用户故事受益于这样一个事实，即您描述了具体的交互，一旦您了解了系统的具体数据和行为，您不妨添加有关交互方式的更多信息。这允许您使用一些工具，例如 Cucumber，它与 Selenium 一起使您能够将故事翻译成测试。您可能会走得更远，例如，对于 Web 应用程序，捕获您开始具体故事的所有页面，并收集与该页面的所有交互，从而形成某种信息架构，您可以将其用于文档或原型设计以及后来的 UI 测试。
另一方面，当涉及到 UI 更改时，这会使您的故事有些脆弱。我认为考虑这一点的敏捷方式与设计更改时相同 - 不要为未来设计，做最简单的事情，在未来你可能需要改变它。
如果您将用户故事从所有具体事物（甚至输入）中剥离出来，您最终将得到用例（至少以最简单的格式，取决于您如何编写故事）。用例在这方面一点也不脆弱，它们只指定目标。这使他们抵制变化，但更难使用工具自动传输信息。
至于流程，RUP/UP 从用例派生 UI，但我认为敏捷本质上是增量的（我不会说迭代，这将排除 FDD 和看板等敏捷方法）。这意味着，当您实施新故事时，您会在 UI 中添加必要的内容。这只会使在故事中添加 UI 细节更加合理。问题是，这不是创建 UI 或更一般的 UX（用户体验）的好方法。这正是人们所说的敏捷的弱点。敏捷宣言专注于功能软件，但仅此而已。据我所知，没有用于设计 UI 或 UX 的敏捷技术。
于 2010-08-17T23:06:04.027 回答
0
我想你只需要退后一点。
坏： 当我单击列标题时，行按我单击的列排序。
好： 然后我按名称对行进行排序，如果名称很常见，有时按邮政编码排序，例如“Smith”。
用户故事/工作流是用户想要实现的序列，而不是他如何实现的一系列动作。您正在收集What's ，以便为所有用户和用例确定最佳How's 。
查看您帖子的一个独特方面：
如果我在“单击列标题时”的场景中这样说，则意味着此功能基于某种表格或网格，但此时我们仍然只是编写用户故事，因此还没有 UI。
如果这来自用户，而不是来自您，它会显示一个隐藏的期望，即实际上存在一个带有列标题的表格或网格。即使来自您，也并非完全没有价值，因为您也可能是用户。它可能是短视的，仅仅因为它来自 SQL 查询而考虑网格，或者它可能是现场的，因为它是您期望数据在其中的表示。创造性的 UI 本身并不是一件坏事，但忽略了用户期望是。
于 2010-08-18T22:57:21.560 回答