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

Шаблон рассказа

Во-первых, давайте начнем с того, что создает хорошую пользовательскую историю. Если история написана плохо, всем участникам будет сложно понять цель того, что строится. Для команд, которые я тренирую на тренировках по Agile и XP, я использую следующий шаблон:

Как (личность) я хочу (действие), чтобы я (ценность).

Давайте рассмотрим каждую часть шаблона по отдельности, чтобы понять, почему эта структура так важна.

Как (персона)

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

Например:

Сьюзи - Сюзи - занятая мать двоих детей (роли). Она хочет найти простые рецепты для своих детей, когда она спешит (цели). У нее нет компьютера или ноутбука, и она любит использовать свой телефон только для выхода в Интернет (выбоины).

Итак, первое утверждение в нашей истории должно быть: «Как Сьюзи» или «Как Сьюзи, мать двоих детей».

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

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

Я хочу (действие)

Заявление о действии довольно простое. Это описание функциональности, которую ищет пользователь. Он должен быть ориентирован на ввод и вывод. Вот пример некоторых функций, которые могут понадобиться Сюзи в приложении:

«Я хочу видеть последние рецепты, которые я использовал, когда захожу на страницу своего профиля».

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

Чтоб я (значение)

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

Вот наша оценка функциональности, которую хочет Сюзи:

«Чтобы я мог легко найти рецепт, который я использовал на этой неделе, который понравился моим детям».

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

Что-то пропало

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

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

Критерии приемки

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

Критерии приемлемости могут быть немного более техническими, но все же должны быть понятны заинтересованным лицам, не являющимся разработчиками. Ниже приведен пример критериев приема для истории, над которой мы работаем для Сюзи:

«ДАННЫЕ Сюзи успешно вошли в систему (состояние системы), КОГДА она открывает страницу своей учетной записи (триггер), ЗАТЕМ она увидит 7 последних просмотренных ею рецептов (вывод)».

Чтобы лучше понять эту последовательность, я хотел бы вспомнить пример складывания домино. В заявлении GIVEN мы аккуратно устанавливаем домино для обеспечения точной точности и выравнивания, чтобы все домино упали, если их опрокинуть. Оператор WHEN - это домино, которое мы нажимаем, чтобы запустить цепную реакцию, которую мы установили в данном операторе. Наконец, оператор THEN должен быть доказуемым утверждением; в случае с домино никто из них не должен стоять.

Один очень важный аспект хорошего написания критериев приемлемости - убедиться, что он имеет один триггер и один выход. Это станет критичным позже, когда разработчики попытаются использовать AC в качестве модели для тестирования. Я предпочитаю синтаксис Gherkin (Given / When / Then), потому что он следует той же структуре, что мы используем при написании автоматических тестов в наших системах. Мы можем легко перевести эти критерии приемки в код Arrange / Act / Assert. Это важная ссылка для разработчиков, пытающихся преобразовать историю в реальный код.

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

Две стороны, одна и та же монета

Я был свидетелем того, как несколько команд пытались написать пользовательские истории в форме критериев приемлемости. Вместо этого они случайно пытаются заменить кто / что / почему в пользовательской истории синтаксисом given / when / then. Важно понимать различия и цели каждого из них. Они оба работают вместе, чтобы создать описание функциональности и ее предназначения, но двумя разными способами.

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

Заключение

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

История пользователя:

  • Сначала определите правильный образ. Затем рассмотрите входы и выходы ожидаемого поведения. Наконец, убедитесь, что вы знаете значение, чтобы правильно расставить приоритеты.
  • Шаблон: как (персона), я хочу (поведение приложения), так что (значение для персонажа).

Критерии приемки:

  • Определите требования к состоянию системы перед запуском триггера. Определите единичное действие, которое вызовет поведение системы. Наконец, придумайте безусловное истинное или ложное утверждение.
  • Шаблон: Дано (состояние системы), Когда (триггер), Затем (доказуемое утверждение).