Истории и сценарии, подразумевающие UI

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

Мне нравятся сценарии, в которых говорится следующее:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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