Истории и сценарии, которые подразумевают пользовательский интерфейс

Question

Я пытаюсь научиться использовать BDD для нашего процесса разработки и иногда заканчиваю тем, что пишу вещи, которые подразумевают дизайн пользовательского интерфейса, поэтому для новых разработок или новых функций пользовательский интерфейс не всегда существует.

Например, если я говорю это в сценарии «Когда щелкают заголовок столбца», это подразумевает, что эта функция основана на некоторой таблице или сетке, но на данный момент мы все еще просто пишем пользовательские истории, так что пользовательского интерфейса еще нет.

Это сбивает меня с толку, когда я узнаю, в какой момент процесса мы придумываем дизайн пользовательского интерфейса?

Имейте в виду, я только читал статьи о BDD, и я думаю, что это очень поможет нашей команде, но все еще очень ново в этом! Thx!

Answer 1

Если вы напишите свои сценарии с акцентом на возможностях системы, вы сможете легче реорганизовать базовые шаги в этих сценариях.Это держит их гибкими.Поэтому я бы спросил - что дает вам нажатие на колонку?Вы что-то выбираете?Что вы собираетесь делать с выбором?Вы ищете что-то и сортируете по значению?

Мне нравится видеть сценарии, которые говорят что-то вроде:

• Когда я ищу запись
• Когда яперейти к дневнику за январь
• Когда я смотрю на самые новые записи
• Когда я смотрю на ту же футболку в черном

Все это может включать в себя нажатиев заголовке столбца, но детали реализации не имеют значения.Это возможности системы.

Под этими сценариями и шагами высокого уровня мне нравится создавать экран или страницу с меньшими шагами, такими как нажатие на кнопки.Это облегчает рефакторинг.

Я написал это на DSL, а не на английском, но это работает с той же идеей - по шагам вы не можете определить, является ли это GUI или веб-страницей, и некоторыеиз шагов включает в себя несколько действий пользовательского интерфейса:

http://code.google.com/p/wipflash/source/browse/Example.PetShop.Scenarios/PetRegistrationAndPurchase.cs

Надеюсь, вы найдете это интересным и, возможно, это поможет.Удачи!

Answer 2

Я думаю, тебе просто нужно немного отступить.

BAD: Когда я щелкаю заголовок столбца, строки сортируются по столбцу, по которому я щелкнул.

GOOD: Затем я сортирую строки по имени, или иногда по почтовому индексу, если имя очень распространено, например, «Смит».

Пользовательская история / рабочий процесс представляет собой последовательность то, что пользователь хочет достичь , а не последовательность действий как он этого добивается.Вы собираете Что , чтобы вы могли определить лучшие Как * для всех пользователей и вариантов использования.

---

Рассматривая отдельный аспект вашего поста:

Если я скажу это в сценарии «При щелчке по заголовку столбца», это означает, что эта функция основана на некоторой таблице или сетке, но на данный момент мывсе еще просто пишу пользовательские истории, поэтому пользовательского интерфейса пока нет.

Если бы это было от пользователя, а не от вас, он бы показал скрытое ожидание что на самом деле есть таблица или сетка с заголовками столбцов.Даже если исходить от вас, это не совсем бесполезно, так как вы тоже можете быть пользователем.Это может быть недальновидно, думать о сетке только потому, что она исходит из SQL-запроса, или она может быть точной, потому что это презентация, в которой вы ожидаете данных. Творческий интерфейс не плохая вещькак таковой, но игнорируя ожидания пользователей.

Answer 3

Пользовательские истории извлекают выгоду из того факта, что вы описываете конкретные взаимодействия, и как только вы знаете конкретные данные и поведение системы для них, вы также можете добавить больше информации о том, как вы взаимодействуете. Это позволяет вам использовать некоторые инструменты, такие как Cucumber, который с Selenium позволяет вам переводить историю в тест. Вы можете пойти еще дальше и, например, для веб-приложений - захватывать все страницы, с которых вы начинаете конкретную историю, и собирать все взаимодействия с этой страницей, что приводит к некоторой информационной архитектуре, которую вы можете использовать для документации или создания прототипов, а затем для тестирования пользовательского интерфейса.

С другой стороны, это делает ваши истории несколько хрупкими, когда дело доходит до изменений пользовательского интерфейса. Я думаю, что гибкий подход к размышлениям такой же, как и в случае с изменениями дизайна - не проектируйте в будущем, делайте самые простые вещи, в будущем вам, возможно, придется все равно изменить его.

Если вы разобрали свои пользовательские истории со всеми конкретными вещами (даже входными данными), у вас получатся варианты использования (по крайней мере, в их простейшем формате, зависит от того, как вы пишете свои истории). Варианты использования в этом отношении совсем не хрупкие, они определяют только цели. Это делает их устойчивыми к изменениям, но затрудняет автоматическую передачу информации с помощью инструментов.

Что касается процесса, RUP / UP выводит пользовательский интерфейс из вариантов использования, но я думаю, что agile по своей природе является инкрементным (я не скажу итеративный, это исключило бы такие гибкие методы, как FDD и Kanban). Это означает, что при реализации новой истории вы добавляете в свой интерфейс то, что необходимо. Это только делает более разумным добавление особенностей пользовательского интерфейса в истории. Проблема в том, что это не очень хороший способ создания пользовательского интерфейса или, в более общем смысле, пользовательского интерфейса. Это именно то, что можно назвать слабым местом гибкой. Agile манифест концентрируется на функциональном программном обеспечении, но это все. Насколько я знаю, нет гибких методов проектирования UI или UX.

Answer 4

Полагаю, вы можете написать вокруг этого, сказав "когда я сортирую информацию по X, тогда ..." Но тогда вам придется изменить свой сценарий, чтобы удалить всеупоминание о данных, отображаемых в формате сетки, что может привести к довольно тупой записи.

Я думаю, что было бы неплохо начать с разработки пользовательского интерфейса как можно скорее.В случае, который вы упомянули выше, я думаю, что было бы совершенно уместно дополнить пользовательскую историю наброском соответствующего пользовательского интерфейса, как вы это себе представляете, а затем уточнить его по мере продвижения.Эскиз карандашом на листе бумаги должен быть в порядке.Или вы можете использовать планшет и SketchBook Pro , если вы хотите что-то полностью цифровое.

Моя точка зрения заключается в том, что я не вижу реальной причины, по которой дизайн пользовательского интерфейса должен оставаться в стороне от пользователя.рассказы.Вы, наверное, уже знаете, что собираетесь создать Windows, WPF или веб-приложение.И можно с уверенностью предположить, что когда вы хотите отобразить табличные данные, вы будете использовать сетку.Исключение этих предположений из требований скрывает их, не добавляя никакой реальной ценности.