Мета зрозуміла: ви хочете розробити продукт, який забезпечить високу додану вартість для клієнтів. Ви хочете досягти результату, яким будуть задоволені члени команди та зацікавлені сторони. Але як досягти цієї мети? Як ви можете виконати всі вимоги до продукту невеликими, ретельними кроками?
У Agile користувацькі історії виявилися ефективним інструментом для цього. Вони крок за кроком проводять вас від першої ідеї до продукту, готового до продажу. Я покажу вам, що таке користувацькі історії, як їх створювати і яку користь ви можете з них отримати.
Що таке історії користувачів в Agile?
Визначення користувацьких історій в Agile описує вимоги до продукту з точки зору користувача. Іншими словами, користувацькі історії розповідають про те, які можливості та функції повинен мати продукт. Це робить їх центральним інструментом для обговорення та перевірки потреб користувачів і роботи над їх реалізацією зі спільним розумінням.
Історії користувачів - це універсальна мова, яку розуміють і якою розмовляють члени команди, зацікавлені сторони та клієнти. На практиці це означає, що ви можете використовувати користувацькі історії, щоб сформувати розуміння продукту, який бажає отримати клієнт, що залишає мало місця для непорозумінь.
Кілька користувацьких історій разом утворюють кейс використання. Історії користувачів беруть свій початок в Agile Software Development.
Як структуровані гнучкі користувацькі історії?
Історії користувачів описують вимоги та побажання до результату проекту з точки зору замовника або користувача. Гнучкі користувацькі історії мають таку елементарну структуру:
ВООЗ (роль), хоче ЩО (мета/бажання) ЧОМУ (додана вартість)?
Розглянемо детальніше окремі складові користувацьких історій:
ХТО (КОРИСТУВАЧ)
Ви заповнюєте заповнювач WER своїм клієнтом або типовим представником вашої цільової групи. Наскільки детально ви опишете КГД в Історії користувача Agile, залежить від самої Історії користувача і від прогресу проекту. Тому будьте достатньо детальними, щоб створити змістовну історію користувача.
ЩО (ФУНКЦІЯ)
Це місце, де ви розміщуєте побажання користувача. Ви можете запитати себе, чого очікує або чого потребує користувач. Якщо ваш продукт знаходиться на ранній стадії розробки, ви можете сформулювати припущення на основі свого досвіду щодо того, яких функцій очікує користувач. Якщо у вас вже є подібний продукт на ринку, ви також можете вивести бажані функції з відгуків про цей продукт.
ЧОМУ (ДОДАНА ВАРТІСТЬ)
Тільки додаткова цінність показує, чому функція важлива для користувача. Отже, ЧОМУ дозволяє вам чесно поміркувати над тим, наскільки добре ви знаєте вимоги клієнта. Тому що: Легко включити вимогу в історію користувача, наприклад, тому що клієнт висловив бажання її отримати. Але тільки тоді, коли ви розумієте, навіщо це потрібно клієнту, у вас з'являється контекст для реалізації вимоги. Тільки тоді ви зможете поставити питання про те, чи дійсно пропозиція/запит клієнта ефективно задовольняє його реальну потребу –, або чи може бути більш розумний спосіб. Давайте розглянемо приклад:
Клієнт хоче накидку від дощу для їзди на велосипеді. Тому ви можете додати вимогу "накидка від дощу". Або ви можете запитати покупця, навіщо йому потрібен дощовик. Припустимо, клієнт відповідає: "Тому що я не хочу промокнути".
Це означає, що вам не обов'язково мати дощовик. Ви також можете поставити велосипед з інтегрованим дахом. Головне, щоб це вирішувало потребу або проблему клієнта – не намокнути. Чим краще ви розумієте "чому", тим краще ви можете розробити свою історію користувача.
Більшість автобусів Agile їздять по колу....
...і лікувати поверхневі симптоми. Настав час використовувати психологію – для стійкої зміни мислення.
"Ми виявляємо занадто багато несподіваних проблем і помилок на пізньому етапі!"
Що таке історії користувачів в Agile (приклад)?
Тепер ви знаєте окремі компоненти користувацьких історій Agile. Приклад історії користувача Agile може виглядати так:
Як КЛІЄНТ Я б хотіла НАДІЙНИЙ ПАРОЛЬ, ЩОБ ДАНІ МОЇХ КЛІЄНТІВ БУЛИ ЗАХИЩЕНІ.
Ось тут "КЛІЄНТ" користувач, "НАДІЙНИЙ ПАРОЛЬ" функцію і "ЩОБ ДАНІ МОЇХ КЛІЄНТІВ БУЛИ ЗАХИЩЕНІ" додану вартість.
Що таке користувацькі історії в Scrum?
Коли ви працюєте з користувацькими історіями в Scrum, ви додаєте до них критерії прийнятності. Критерії прийнятності описують технічні вимоги, яким повинні відповідати користувацькі історії на момент прийняття. Іншими словами: Критерії прийнятності - це вимоги, які вам потрібні для того, щоб користувацька історія створювала цінність.
Значення користувацьких історій Agile в беклозі може бути більш диференційованим. Тому що: в беклогах історії користувачів можуть не тільки описувати вимоги, але й представляти особливий тип ієрархії. Існує 3 типи ієрархії:
Епоси: Епоси - це широко визначені функціональні області продукту, конкретний обсяг яких все ще може бути незрозумілим.
Особливості: Особливості - це специфічні характеристики виконання в епічному творі.
Історії: Історії - це технічні історії користувачів Agile та історії користувачів у межах функції.
Ви можете реалізувати ці типи ієрархії в рамках спринту. Вони створюють конкретну користь для користувача.
Написання користувацьких історій – Як створювати цікаві користувацькі історії?
Для того, щоб написати корисні історії користувачів в гнучкому управлінні проектами, вкрай важливо провести детальні обговорення з усіма зацікавленими сторонами. Вони повинні дати вам всебічне розуміння цільової групи та продукту, який буде створено. На основі цього ви можете створити, наприклад, персоналії.
Крім того, так звані Критерії інвестуваннястворити переконливу користувацьку історію:
Незалежний: Користувацька історія повинна бути незалежною від інших користувацьких історій. Це означає, що реалізація історії не повинна передбачати, що інша історія була реалізована раніше. Це має перевагу в тому, що ви можете в будь-який момент визначити пріоритетність користувацьких історій або вилучити їх з беклогу.
Давайте ще раз розглянемо приклад з велосипедом. Уявімо, що ви вирішили встановити невеликий дах над сідлом велосипеда замість дощовика, щоб клієнт більше не мокнув. Це була б історія користувача. Але тепер ви розумієте, що спочатку потрібно розробити більш стійке сідло, до якого можна прикріпити дах. Це вже буде інша історія користувача. Обидві історії спираються одна на одну. Це саме те, чого ви повинні запобігти.
Звичайно, іноді не уникнути того, що вам доведеться реалізовувати одну історію користувача перед іншою. Але, як правило, уникайте користувацьких історій, для яких спочатку потрібно реалізувати 20 інших користувацьких історій.
Обговорюється: Написання користувацьких історій іноді може зайняти досить багато часу –, але після цього вони не повинні бути викарбувані в камені. Це означає: Власник продуктуЗацікавлені сторони та розробники завжди повинні обговорювати та вдосконалювати історію користувача разом.
Цінний: Результат користувацьких історій в гнучкому управлінні проектами повинен мати додаткову цінність для клієнта.
Приблизно: Переконлива історія користувача дозволяє команді розробників оцінити, скільки зусиль знадобиться для її реалізації.
Невеликий: Користувацька історія повинна бути настільки "маленькою", щоб її можна було реалізувати за один спринт.
Можна перевірити: Історії користувачів у Scrum повинні бути тестованими. Це єдиний спосіб перевірити, чи дійсно вони можуть бути реалізовані на практиці.
Як отримати вигоду з користувацьких історій в Agile
Якщо ви не знайомі з написанням користувацьких історій в Agile, вони можуть здатися вам додатковою роботою. Однак історії користувачів надають командам важливий контекст для їхніх завдань, додатково пояснюючи важливість кожного завдання.
По суті, це те, як ви отримуєте вигоду від користувацьких історій:
Орієнтація на користувача: Історії користувачів - це як проблемно-орієнтований список справ. Ваша команда може використовувати їх, щоб відстежувати свої завдання і точно знати, як задовольнити потреби користувачів.
Цілісна співпраця: Історії користувачів одразу показують усім залученим сторонам, куди рухаються справи. Таким чином, кожен може об'єднатися і знову і знову вирішувати, як користувач отримає особливо високу додану вартість.
Креативні рішення: Створення користувацьких історій в Agile для розробки програмного забезпечення творчі результати. Тому що: вони змушують команди критично думати про найкраще рішення для кінцевого продукту.
Постійні успіхи: Кожна історія користувача - це невеликий виклик. Тому команди можуть святкувати невеликий успіх після кожної історії. Це мотивує протягом усього процесу розробки.
Висновок
Історії користувачів - важливий інструмент у роботі гнучких команд. Вони знову і знову детально показують вам, для кого ви розробляєте, що і чому. Це не тільки допомагає створити якісний продукт, адаптований для цільової групи, але й тримати команду вмотивованою протягом усього процесу.
Щоб досягти успіху на цьому макрорівні гнучкої роботи, ваша організація в цілому повинна мислити та функціонувати в гнучкий спосіб. Щоб підтримати вас і вашу організацію в цьому, ми працювали разом з відомими експертами, щоб створити Проект Scagile розроблений. На різних вебінарах ми показуємо, як правильно підходити до гнучкої трансформації. Навчання є безкоштовним. Не соромтеся поглянути!
Якщо вам потрібні більш різноманітні запитання для ретроспективи, перегляньте нашу публікацію про це: 32 свіжі ретроспективні методи для початківців та професіоналів (зокрема, з Mario Kart Retro, Marathon Retro та Elon Musk Retro).
