User Stories та Use Cases простими словами
Привіт! Мене звуть Віталій Жданов, я ІТ-спеціаліст, спеціалізуюсь на системному адмініструванні. Знайшов свою професію на все життя майже відразу. Постійний саморозвиток став звичним, тому пройшов курс лекцій по будуванню комп’ютерних мереж Cisco. Через 2 роки мені захотілось більшого, ніж просто обслуговувати обладнання, усувати і запобігати несправностям. Одного дня я подав заявку на грант на навчання в SkillsUp на курсі по управлінню проектами. Коли я отримав запрошення на курс, зрозумів, що зірвав куш. В мене є мрія, звучить вкрай масштабно, навіть дещо божевільно, проте, поки що, збережу інтригу.
User Stories та Use Cases є різними інструментами документування вимог, які використовуються в процесі розробки програмного забезпечення. Кожен із них має свою функцію. Наприклад, User Stories використовуються для визначення функціональних вимог до системи з погляду користувача та мовою бізнесу, Use Cases — для більш детального опису взаємодії користувача із системою у визначених сценаріях.
Що ж таке User Stories? Уявімо, що до нас звернувся представник MIT Consulting LTD та попросив створити мобільний застосунок для медитації. У цьому випадку звернення виглядатиме орієнтовно так: «Я, як людина, яка слідкує за своїм психічним здоров’ям і медитує, хочу мати застосунок для медитації, щоб входити в стан глибокого трансу за допомогою спеціального пристрою, слухаючи відповідну музику для покращення процесу». У цій User Story ми маємо всі потрібні компоненти:
- Роль (представник MIT Consulting LTD).
- Об’єкт бажання замовника (мобільний застосунок для медитації).
- Ціль (щоб входити в стан глибокого трансу, слухаючи відповідну музику для покращення процесу).
Водночас відбувається деталізація User Story — представник компанії зазначає, що хоче, щоб застосунок був доступний для широкого кола користувачів та мав інтерфейс, який зрозуміють навіть люди з низькою комп’ютерною грамотністю. Users Stories створюються тільки для відображення потреб замовника з найбільш важливими деталями, вони не мають бути надто об’ємними. Якщо не виходить зробити коротку User Story, варто розбити її на декілька дрібних. Звичайно, застосунок приведений лише для прикладу. Тут буде багато ітерацій, тому потрібно багато дрібних User Stories. Наведу декілька прикладів:
«Я, як майбутній правовласник застосунку, хочу, щоб спеціальний пристрій, який користувачі будуть надягати на голову, взаємодіяв із застосунком через Bluetooth».
«Я, як майбутній правовласник, хочу, щоб застосунок давав змогу користувачу обирати спосіб медитації конкретно під себе — з урахуванням віку, статі, свого звичайного артеріального тиску, пульсу та інших ключових параметрів. Це сприятиме більшій ефективності медитації».
Формула User Story: Я, як [Х], хочу [Y], щоб [Z], де
X — людина, яка висловлює запит;
Y — ціль запиту; те, із чим до вас прийшов клієнт;
Z — фінальна мета, через яку людина звернулася; бізнес-цінність.
Use case (юзкейс, сценарій використання) можна описати як сценарій взаємодії користувача з продуктом. Юзкейс має такі дані:
- хто використовує продукт;
- що користувач хоче зробити;
- ціль певної дії користувача;
- кроки, які робить користувач, щоб виконати дію;
- опис результату взаємодії системи з користувачем.
Якщо подумати, юзкейс у деякому сенсі — більш детальний варіант User Story, оскільки крім перших трьох пунктів містить кроки, які робить користувач для виконання певної дії та її результат.
- Визначте основного учасника (актора). Актором може бути людина, інше ПЗ або обладнання
- Опишіть мету. Зазначте основну ціль або задачу варіанту використання з погляду актора.
- Перелічіть кроки. Детально опишіть кроки, пов’язані з досягненням мети варіанту використання, починаючи з першої дії актора і продовжуючи до завершення варіанту використання.
- Додайте варіації. Враховуйте будь-які потенційні варіації кроків, пов’язаних зі сценарієм використання, як-от альтернативні шляхи чи сценарії винятків.
- Результат. Опишіть кінцевий результат або результат варіанта використання, який повинен відповідати меті актора.
Я б написав юзкейс для BFB Training так:
- Хто? Кінцевий користувач.
- Що він хоче зробити? Провести медитацію.
- Яка ціль дії? Зняти напругу після важкого робочого дня.
- Які кроки виконує користувач під час виконання цієї дії?
4.1. Вмикає Bluetooth на своєму телефоні.
4.2. Під’єднує смартфон до спеціального пристрою для зчитування активності головного мозку та надягає його на голову.
4.3. Відкриває застосунок.
4.4. Натискає на іконку з написом «почати медитацію».
4.5. Пристрій на голові аналізує активність мозку, на основі якої застосунок обирає режим медитації, підбирає музику.
4.6. Користувач медитує.
4.7. Медитація закінчується, людина заспокоєна і знімає пристрій із голови.
4.8. Користувач натискає на іконку «Зберегти дані медитації».
4.9. Людина закриває застосунок.
4.10. Користувач знімає з голови пристрій, від’єднує його від телефону та вимикає Bluetooth на смартфоні
- Як реагує продукт на дії користувача? Застосунок взаємодіє з пристроєм, підбирає режим медитації, зберігає інформацію в базу даних на сервері.
Це юзкейс нормальної взаємодії користувача із застосунком із д. Якщо щось пішло не так, наприклад, людина хотіла зберегти дані про медитацію, а смартфон не під’єднаний до інтернету, користувач побачить напис: «З’єднання з інтернетом відсутнє або нестабільне. Будь ласка, перевірте підключення». Це вже буде юзкейс із нестандартним сценарієм.
Важливо, аби досвідчений аналітик умів документувати вимоги й через User Stories, і через Use Cases. І хоча вони мають різні функції та використовуються на різних етапах проєкту, вони доповнюють один одного та дають змогу розробникам і замовникам чітко зрозуміти, яким має бути кінцевий продукт та які функції він мусить мати. Розуміння вимог користувачів та бізнес-цінності допоможе розробити ефективну й корисну систему, яка задовольнить потреби клієнтів та принесе користь їхньому бізнесу.
Автор статті
Віталій Жданов
Cистемний адміністратор з 2-річним досвідом, студент SkillsUP за напрямком «Управління ІТ-проектами», відкритий до нових можливостей в кар’єрі.
Сертифікат про закінчення курсу по побудові мереж на базі обладнання Cisco:
https://www.udemy.com/certificate/UC-d8e7c424-1043-4884-8503-12af5e93e645/
Марина Мельник :
Пишаюся студетом Віталієм. Радію, спостерігаючи за тим, як мої студенти та учні стають затребуваними фахівцями