Визначення поняття USER STORY
User story — це опис функціональності або частини функціональності, написаний повсякденною або діловою мовою і показує, що робить або має робити користувач.
На відміну від формальної документації User story забезпечує швидкий спосіб обробки вимог замовника без виконання адміністративних завдань, пов'язаних з її обслуговуванням.
Переваги
Рекомендуємо курс по темі
Для проектного менеджера:
- допомагає створити правильну архітектуру програми;
- скорочує час відповідей на питання про логіку додатка розробників, дизайнерів, тестувальників;
- User stories просто оновлюються і можуть бути використані в якості документації.
Для дизайнерів:
- дає уявлення про кількість макетів, необхідних для покриття всієї програми;
- застерігає від створення зайвих необхідних екранів / кнопок / функциональностей.
Для розробників:
- Features є основою для написання приймальних тестів при розробці через тестування (TDD і BDD);
- допомагає уникнути різночитань документації (технічних умов і вимог замовника), а також помилок в логіці програми.
Для QA:
- служить основою для написання тест-кейсів і чек-листів;
- допомагає швидко зрозуміти логіку програми.
Для клієнтів:
- дає гарне уявлення про програму, про те, як вона працює;
- клієнт може самостійно описати нові функціональні можливості, використовуючи наш формат User story, який запобігає неправильному тлумаченню вимог.
Формат USER STORIES
Рекомендуємо курс по темі
Ви можете зустріти такі формати User story:
Mike Cohn, добре відомий автор User stories, вважає частину "so that" опціональною:
"As a role, I want goal / desire"
Chris Matts припустив, що «полювання за якістю» стало першим кроком в успішній реалізації програмного забезпечення, і запропонував наступний формат:
"In order to as 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 з архітектурою додатків;
- показує, як зміни впливають на структуру програми;
- дозволяє клієнтам створювати нові вимоги і побажання, які будуть більш зрозумілими для розробників.
