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