Історії користувачів у Scrum: все, що вам потрібно знати

Мета зрозуміла: ви хочете розробити продукт, який забезпечить високу додану вартість для клієнтів. Ви хочете досягти результату, яким будуть задоволені члени команди та зацікавлені сторони. Але як досягти цієї мети? Як ви можете виконати всі вимоги до продукту невеликими, ретельними кроками? 

У Agile користувацькі історії виявилися ефективним інструментом для цього. Вони крок за кроком проводять вас від першої ідеї до продукту, готового до продажу. Я покажу вам, що таке користувацькі історії, як їх створювати і яку користь ви можете з них отримати.

Визначення користувацьких історій в Agile описує вимоги до продукту з точки зору користувача. Іншими словами, користувацькі історії розповідають про те, які можливості та функції повинен мати продукт. Це робить їх центральним інструментом для обговорення та перевірки потреб користувачів і роботи над їх реалізацією зі спільним розумінням. 

Історії користувачів - це універсальна мова, яку розуміють і якою розмовляють члени команди, зацікавлені сторони та клієнти. На практиці це означає, що ви можете використовувати користувацькі історії, щоб сформувати розуміння продукту, який бажає отримати клієнт, що залишає мало місця для непорозумінь. 

Кілька користувацьких історій разом утворюють кейс використання. Історії користувачів беруть свій початок в Agile Software Development.

Історії користувачів описують вимоги та побажання до результату проекту з точки зору замовника або користувача. Гнучкі користувацькі історії мають таку елементарну структуру:

ВООЗ (роль), хоче ЩО (мета/бажання) ЧОМУ (додана вартість)?

Розглянемо детальніше окремі складові користувацьких історій:

ХТО (КОРИСТУВАЧ)

Ви заповнюєте заповнювач WER своїм клієнтом або типовим представником вашої цільової групи. Наскільки детально ви опишете КГД в Історії користувача Agile, залежить від самої Історії користувача і від прогресу проекту. Тому будьте достатньо детальними, щоб створити змістовну історію користувача.

ЩО (ФУНКЦІЯ)

Це місце, де ви розміщуєте побажання користувача. Ви можете запитати себе, чого очікує або чого потребує користувач. Якщо ваш продукт знаходиться на ранній стадії розробки, ви можете сформулювати припущення на основі свого досвіду щодо того, яких функцій очікує користувач. Якщо у вас вже є подібний продукт на ринку, ви також можете вивести бажані функції з відгуків про цей продукт.

ЧОМУ (ДОДАНА ВАРТІСТЬ)

Лише додана вартість показує, чому користувачеві важлива певна функція. Отже, «ЧОМУ» дозволяє вам чесно оцінити, наскільки добре ви знаєте потреби клієнта. Адже: включити вимогу в User Story просто — наприклад, тому, що клієнт висловлює таке побажання. Але тільки коли ви розумієте, чому клієнту це потрібно, ви маєте контекст для реалізації цієї вимоги. Лише тоді ви можете запитати, чи пропозиція/побажання клієнта ефективно задовольняє його фактичну потребу — або чи є, можливо, більш розумний спосіб. Розглянемо приклад: 

Клієнт хоче накидку від дощу для їзди на велосипеді. Тому ви можете додати вимогу “накидка від дощу”. Або ви можете запитати покупця, навіщо йому потрібен дощовик. Припустимо, клієнт відповідає: “Тому що я не хочу промокнути”. 

Це означає, що вам не обов’язково постачати дощовий плащ. Ви також можете запропонувати велосипед з вбудованим дахом. Головне, щоб потреба чи проблема клієнта була вирішена — а саме, не промокнути. Чим краще ви розумієте «чому», тим краще зможете розробити свою User Story.

Що таке історії користувачів в Agile (приклад)?

Тепер ви знаєте окремі компоненти користувацьких історій Agile. Приклад історії користувача Agile може виглядати так: 

Як КЛІЄНТ Я б хотіла НАДІЙНИЙ ПАРОЛЬ***,*** ЩОБ ДАНІ МОЇХ КЛІЄНТІВ БУЛИ ЗАХИЩЕНІ.

Ось тут “КЛІЄНТ” користувач, “НАДІЙНИЙ ПАРОЛЬ” функцію і “ЩОБ ДАНІ МОЇХ КЛІЄНТІВ БУЛИ ЗАХИЩЕНІ” додану вартість. 

Коли ви працюєте з користувацькими історіями в Scrum, ви додаєте до них критерії прийнятності. Критерії прийнятності описують технічні вимоги, яким повинні відповідати користувацькі історії на момент прийняття. Іншими словами: Критерії прийнятності - це вимоги, які вам потрібні для того, щоб користувацька історія створювала цінність.

Значення користувацьких історій Agile в беклозі може бути більш диференційованим. Тому що: в беклогах історії користувачів можуть не тільки описувати вимоги, але й представляти особливий тип ієрархії. Існує 3 типи ієрархії:

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

Особливості: Особливості - це специфічні характеристики виконання в епічному творі.

Історії: Історії - це технічні історії користувачів Agile та історії користувачів у межах функції.

Ви можете реалізувати ці типи ієрархії в рамках спринту. Вони створюють конкретну користь для користувача. 

Для того, щоб написати корисні історії користувачів в гнучкому управлінні проектами, вкрай важливо провести детальні обговорення з усіма зацікавленими сторонами. Вони повинні дати вам всебічне розуміння цільової групи та продукту, який буде створено. На основі цього ви можете створити, наприклад, персоналії. 

Крім того, так звані Критерії інвестуваннястворити переконливу користувацьку історію:

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

Давайте ще раз розглянемо приклад з велосипедом. Уявімо, що ви вирішили встановити невеликий дах над сідлом велосипеда замість дощовика, щоб клієнт більше не мокнув. Це була б історія користувача. Але тепер ви розумієте, що спочатку потрібно розробити більш стійке сідло, до якого можна прикріпити дах. Це вже буде інша історія користувача. Обидві історії спираються одна на одну. Це саме те, чого ви повинні запобігти.

Звичайно, іноді не уникнути того, що вам доведеться реалізовувати одну історію користувача перед іншою. Але, як правило, уникайте користувацьких історій, для яких спочатку потрібно реалізувати 20 інших користувацьких історій.

Обговорюється: Написання User Stories іноді може зайняти багато часу - але після цього вони не повинні бути висічені в камені. Це означає: Власник продукту Зацікавлені сторони та розробники завжди повинні обговорювати та вдосконалювати історію користувача разом. 

Цінний: Результат користувацьких історій в гнучкому управлінні проектами повинен мати додаткову цінність для клієнта.

Приблизно: Переконлива історія користувача дозволяє команді розробників оцінити, скільки зусиль знадобиться для її реалізації.

Невеликий: Користувацька історія повинна бути настільки “маленькою”, щоб її можна було реалізувати за один спринт.

Можна перевірити: Історії користувачів у Scrum повинні бути тестованими. Це єдиний спосіб перевірити, чи дійсно вони можуть бути реалізовані на практиці.

Якщо ви не знайомі з написанням користувацьких історій в Agile, вони можуть здатися вам додатковою роботою. Однак історії користувачів надають командам важливий контекст для їхніх завдань, додатково пояснюючи важливість кожного завдання.

По суті, це те, як ви отримуєте вигоду від користувацьких історій:

Орієнтація на користувача: Історії користувачів - це як проблемно-орієнтований список справ. Ваша команда може використовувати їх, щоб відстежувати свої завдання і точно знати, як задовольнити потреби користувачів.

Цілісна співпраця: Історії користувачів одразу показують усім залученим сторонам, куди рухаються справи. Таким чином, кожен може об’єднатися і знову і знову вирішувати, як користувач отримає особливо високу додану вартість. 

Креативні рішення: Створення користувацьких історій в Agile для розробки програмного забезпечення творчі результати . Тому що: вони змушують команди критично думати про найкраще рішення для кінцевого продукту.

Постійні успіхи: Кожна історія користувача - це невеликий виклик. Тому команди можуть святкувати невеликий успіх після кожної історії. Це мотивує протягом усього процесу розробки.

Історії користувачів - важливий інструмент у роботі гнучких команд. Вони знову і знову детально показують вам, для кого ви розробляєте, що і чому. Це не тільки допомагає створити якісний продукт, адаптований для цільової групи, але й тримати команду вмотивованою протягом усього процесу. 

Щоб досягти успіху на цьому макрорівні гнучкої роботи, ваша організація в цілому повинна мислити та функціонувати в гнучкий спосіб. Щоб підтримати вас і вашу організацію в цьому, ми працювали разом з відомими експертами, щоб створити Проект Scagile розроблений. На різних вебінарах ми показуємо, як правильно підходити до гнучкої трансформації. Навчання є безкоштовним. Не соромтеся поглянути!

Якщо вам потрібні більш різноманітні запитання для ретроспективи, перегляньте нашу публікацію про це: 32 свіжі ретроспективні методи для початківців та професіоналів (зокрема, з Mario Kart Retro, Marathon Retro та Elon Musk Retro).

До речі, одним з найкращих методів сталого розвитку agile мислення членів команди є впровадження agile Health Check. Наш безкоштовний конструктор Team-Health Check може допомогти вам задати правильні запитання - просто перегляньте.