Определение понятия USER STORY
User story — это описание функциональности или части функциональности, написанное повседневным или деловым языком и показывающее, что делает или должен делать пользователь.
В отличие от формальной документации пользовательских историй обеспечивает быстрый способ обработки требований заказчика без выполнения административных задач, связанных с ее обслуживанием.
Выгоды
Рекомендуем курс по теме
Для проектного менеджера:
- помогает создать правильную архитектуру приложения;
- сокращает время ответов на вопросы о логике приложения разработчиков, дизайнеров, тестировщиков;
- User stories просто обновляются и могут быть использованы в качестве документации.
Для дизайнеров:
- дает представление о количестве макетов, необходимых для покрытия всего приложения;
- предостерегает от создания лишних необходимых экранов/ кнопок/ функциональностей.
Для разработчиков:
- Features являются основой для написания приемочных тестов при разработке через тестирование (TDD и BDD);
- помогает избежать разночтений документации (технических условий и требований заказчика), а также ошибок в логике приложения.
Для QA:
- служит основой для написания тест-кейсов и чек-листов (основы QA);
- помогает быстро понять логику приложения.
Для клиентов:
- даёт хорошее представление о приложении, о том, как оно работает;
- клиент может самостоятельно описать новые функциональные возможности, используя наш формат User story, который предотвращает неправильное толкование требований;
Формат USER STORIES
Рекомендуем курс по теме
Вы можете встретить следующие форматы User story:
Mike Cohn, хорошо известный автор User stories, считает часть “so that” опциональной:
“As a role, I want goal/desire”
Chris Matts предположил, что «охота за качеством» стала первым шагом в успешной реализации программного обеспечения, и предложил следующий формат:
“In order toas a receive benefitas a role, I want goal/desire”
Другие варианты:
“As a role, I want goal/desire so that benefit”
“As a role, I can action with system so that external benefit”
В компании Steelkiwi мы используем язык Gherkin, чтобы сделать user stories более читабельными и понятными как для разработчиков, так и для клиентов.
Определение языка GHERKIN
Рекомендуем курс по теме
Gherkinявляется языком, удобным как для восприятия человеком, так и для описания поведения системы. Он использует отступы для определения структуры документа (пробелы или табуляция).
Каждая строка начинается с одного из ключевых слов и описывает один из шагов. Большинство строк в Gherkin начинается с ключевых слов и состоят из функций и сценариев, например:
Давайте рассмотрим приведенный на рисунке выше пример:
- Feature: Короткое, но полное описание необходимой функциональности, которое запускает функцию и дает ей имя.
- Следующие три строки описывают преимущества, которые дает данный функционал.
- Scenario: Конкретная бизнес ситуация, включающая в себя детальное описание.
- Следующие 7 строк описывают действия пользователя, которые соответствуют конкретному коду. Строки, которые следуют за ключевыми словами “Given”, “AND”, “Then” и т.д., сравниваются.
Реализация
Ниже вы можете увидеть, как выглядит начальная часть одной из наших User stories:
User actions: In order to view photos, set likes, view news, upload photos and take part in contests As a user I want to download application from App Store, then register/login, then search photos by artist, view photos, set likes, view news, upload my photo, add photo in contests.
1.1. Registration: In order to Sign up As an unauthorized user I want to open a downloaded application, then click “Sign Up” button, fill in all mandatory fields (email, password, etc), connect to Google+/Facebook/Instagram/Twitter and add friends who are registered in PhotoCulture application, then redirect to Home page.
1.1.1. Download application: In order to Download application from App Store As a user I want to open App Store, then click search button, then input “____”, then click “Install” button.
1.1.2. Sign Up: In order to Sign Up As an unauthorized user I want to open a downloaded application, then click “Sign Up” button, then redirect to “Sign Up” screen, then input correct value in “email” field, input correct value in “password” field, duplicate password value in “confirm password” field, then click “Sign Up” button, then display “Check your email to complete registration” pop up, then confirm registration in my email.
Выводы
Перед тем как написать каждую отдельную User story мы создаем User story, которая описывает end-to-end сценарий поведения приложения и пользовательский сценарий: от регистрации до завершения работы приложения (выхода из системы). В этой User story, мы опишем все действия, которые выполняет приложение, например: просмотр фотографий других пользователей, добавление своих собственных фотографии, участие в конкурсах, получение наград, добавление комментариев и т.д.
После этого мы делаем отдельные User stories, которые описывают некоторые функции более детально. Кроме того, в случае необходимости мы описываем более подробные детали предыдущей User story.
Отличительной особенностью нашей компании является то, что наши User stories не отделены от общей структуры проекта. Мы формируем все User stories из приложения в единый документ, в котором они появляются в древовидной структуре.
Преимущества нашего подхода:
- помогает избежать несовместимости User stories с архитектурой приложений;
- показывает, как изменения влияют на структуру приложения;
- позволяет клиентам создавать новые требования и пожелания, которые будут более понятными для разработчиков.
