暗示 UI 的故事和场景
我正在尝试学习如何在我们的开发过程中使用 BDD，有时我最终会编写暗示 UI 设计的东西，因此对于全新的开发或新功能，UI 并不总是存在。
例如，如果我在“单击列标题时”场景中这么说，则意味着该功能基于某种表格或网格，但此时我们仍然只是编写用户故事，因此没有 UI然而。
这让我很困惑，不知道我们在流程的哪个阶段提出 UI 设计？
请记住，我只读过有关 BDD 的文章，我认为这会对我们的团队有很大帮助，但在这方面仍然很新！谢谢！
I am trying to learn how to use BDD for our development process and I sometimes end-up writing things that implies a UI design, so for brand new development or new features, the UI does not always exists.
For example, if I say this in a scenario "When a column header is clicked" it implies that this feature is based on some sort of table or grid, but at this point we are still just writing user-stories so there is no UI yet.
That gets me confused to know at what point in the process do we come up with a UI design ?
Keep in mind, I only have read articles about BDD and I think it would help our team a lot but still very new at this! Thx!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您在编写场景时重点关注系统的功能，那么您将能够更轻松地重构这些场景中的基础步骤。这让他们保持灵活性。所以我想问 - 单击该列会给您带来什么？你在选择什么吗？您将如何处理选择？您是否正在搜索某些内容并按值排序？
我喜欢看到这样的场景：
这些都可能涉及点击某一列标题，但实现细节并不重要。这就是系统的能力。
在这些高级场景和步骤下面，我喜欢创建一个屏幕或页面，其中包含较小的步骤，例如单击其中的按钮。这使得重构变得容易。
我用 DSL 而不是英语编写了此内容，但它的工作原理相同 - 您无法从步骤中判断它是 GUI 还是网页，并且某些步骤涉及多个 UI 操作：
http://code.google.com/p/wipflash/source/ browser/Example.PetShop.Scenarios/PetRegistrationAndPurchase.cs
希望您觉得它很有趣，也许它会有所帮助。祝你好运！
If you write your scenarios with a focus on the capabilities of the system, you'll be able to refactor the underlying steps within those scenarios more easily. It keeps them flexible. So I'd ask - what does clicking the column get for you? Are you selecting something? What are you going to do with the selection? Are you searching for something and sorting by a value?
I like to see scenarios which say things like:
These could all involve clicking on a column header, but the implementation detail doesn't matter. It's the capability of the system.
Beneath these high-level scenarios and steps I like to create a screen or page with the smaller steps like clicking buttons in it. This makes it easy to refactor.
I wrote this in a DSL rather than English, but it works with the same idea - you can't tell from the steps whether it's a GUI or a web page, and some of the steps involve multiple UI actions:
http://code.google.com/p/wipflash/source/browse/Example.PetShop.Scenarios/PetRegistrationAndPurchase.cs
Hope you find it interesting and maybe it helps. Good luck!
我想您可以通过说“当我按 X 对信息进行排序时，然后...”来解决这个问题，但是您必须调整您的场景以删除任何提及以网格格式显示的数据，这可能会导致一些相当迟钝的书写。
我认为尽快开始 UI 设计是个好主意。在您上面提到的情况下，我认为用您想象的相关 UI 草图来增强用户故事是完全有效的，然后在进行过程中对其进行完善。在纸上用铅笔画草图应该没问题。或者您可以使用平板电脑和 SketchBook Pro 如果你想要全数字化的东西。
我的观点是，我不认为 UI 设计被排除在用户故事之外的真正原因。您可能已经知道您将构建 Windows、WPF 或 Web 应用程序。可以肯定地假设，当您想要显示表格数据时，您将使用网格。将这些假设排除在需求之外会混淆它们，而不会增加任何实际价值。
I guess you can write around that by saying "when I sort the information by X, then..." But then you would have to adjust your scenario to remove any mention of the data being displayed in a grid format, which could lead to some rather obtuse writing.
I think it's a good idea to start with UI design as soon as you possibly can. In the case you mentioned above, I think it would be perfectly valid to augment the user story with sketch of the relevant UI as you would imagine it, and then refine it as you go along. A pencil sketch on a piece of paper should be fine. Or you could use a tablet and SketchBook Pro if you want something all digital.
My point is that I don't see a real reason for the UI design to be left out of user stories. You probably already know that you're going to build a Windows, WPF, or Web application. And it's safe to assume that when you want to display tabular data, you'll be using a grid. Keeping these assumptions out of the requirements obfuscates them without adding any real value.
用户故事受益于这样一个事实：您描述了具体的交互，一旦您了解了系统的具体数据和行为，您也可以添加有关交互方式的更多信息。这允许您使用一些工具，例如 Cucumber，它与 Selenium 一起使您可以将故事转换为测试。您可能会更进一步，例如，对于 Web 应用程序，捕获您开始具体故事的所有页面，并收集与该页面的所有交互，从而产生某种信息架构，您可以将其用于文档或原型设计以及稍后的 UI 测试。
另一方面，当涉及到 UI 更改时，这会使您的故事变得有些脆弱。我认为敏捷的思维方式与设计变更时的思维方式是一样的——不要为未来而设计，做尽可能简单的事情，将来你可能无论如何都需要改变它。
如果您将用户故事中的所有具体事物（甚至输入）剥离，您最终将得到用例（至少以最简单的格式，取决于您如何编写故事）。在这方面，用例一点也不脆弱，它们仅指定目标。这使得它们抵制变化，但使用工具自动传输信息更困难。
至于流程，RUP/UP 从用例中派生出 UI，但我认为敏捷本质上是增量的（我不会说迭代，这会排除像 FDD 和看板这样的敏捷方法）。这意味着，当您实现新故事时，您可以向 UI 中添加必要的内容。这只会使得在故事中添加 UI 细节更加合理。问题是，这不是创建 UI 或更一般的 UX（用户体验）的好方法。这正是人们所说的敏捷的弱点。敏捷宣言专注于功能性软件，但仅此而已。据我所知，还没有用于设计 UI 或 UX 的敏捷技术。
User stories benefit from the fact, that you describe concrete interactions and once you know concrete data and behaviour of the system for it, you might as well add more information about the way you interact. This allows you to use some tools like Cucumber, which with Selenium enables you to translate a story to a test. You might go even further and e.g. for web apps capture all pages you start concrete story at and collect all interactions with that page resulting in some sort of information architecture you might use for documentation or prototyping and later UI testing.
On the other hand, this makes your stories somewhat brittle when it comes to UI changes. I think the agile way of thinking about this is same as when it comes to design changes - do not design for the future, do the simplest possible thing, in the future you might need to change it anyway.
If you stripped your user stories of all concrete things (even inputs) you will end up with use cases(at least in their simplest format, depends on how you write your stories). Use cases are in this respect not brittle at all, they specify only goals. This makes them resistant to change, but its harder to transfer information automatically using tools.
As for the process, RUP/UP derives UI from use cases, but I think agile is in its nature incremental (I will not say iterative, this would exclude agile methods like FDD and Kanban). This means, as you implement new story, you add to your UI what is necessary. This only makes adding UI specifics in stories more reasonable. The problem is, that this is not a very good way to create UI or more generally UX(user experience). This is exactly what one might call a weakpoint of agile. The Agile manifesto concentrates on functional software, but that is it. There are as far as I know no agile techniques for designing UI or UX.
我认为你只需要退一步。
不好： 当我单击列标题时，行会按我单击的列进行排序。
好： 然后我对行进行排序按名称，或者有时按邮政编码（如果名称很常见，例如“Smith”）。
用户故事/工作流程是用户想要实现的目标的序列，而不是序列他如何实现这一目标的行动。您正在收集内容，以便为所有用户和用例确定最佳如何。
看看你的帖子的一个独特的方面：
如果这来自用户，而不是您，则会显示隐藏的期望，即实际上存在带有列标题的表格或网格。即使来自您，也并非完全没有价值，因为您也可能是用户。它可能是短视的，仅仅因为它来自 SQL 查询就认为网格，或者它可能是准确的，因为它是您期望数据的呈现形式。有创意的 UI 并不是一个坏事事情本身就是如此，但忽略了用户的期望。
I think you just need to step back a bit.
BAD: When I click the column header, the rows get sorted by the column I clicked.
GOOD: Then I sort the rows by name, or sometimes by ZIP code if the name is very common, like "Smith".
A user story / workflow is a sequence of what the user wants to achieve, not a sequence of actions how he achieves that. You are collecting the What's so you can determine the best How's for all users and use cases.
Looking at a singular aspect of your post:
If this came from a user, not from you, it would show a hidden expectation that there actually is a table or grid with column headers. Even coming from you it's not entirely without value, as you might be a user, too. It might be short-sighted, thinking of a grid just because it comes from an SQL query, or it might be spot-on because it's the presentation you expect the data in. A creative UI isnÄt a bad thing as such, but ignoring user expectations is.