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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

http://code.google.com/p/wipflash/source/browse/example.petshop.scenarios/petregistrationandpurchase.cs

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

ПЛОХОЙ: Когда я нажимаю заголовок столбца, ряды отсортируются по столбцу, который я нажал.

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

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

---

Глядя на единственный аспект вашего поста:

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

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