Бачити далі верхівки айсберга: короткий гайд зі складання юзер-сторі

Привіт! Мене звуть Іван Єременко. Протягом восьми років керую компанією Techstack і понад дванадцять — займаюся розробкою продуктів різного масштабу. У статті я розповім, як можна покращити процес постановки завдань, а також розберу приклад ефективного опису юзер-сторі.

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

Типовий процес роботи з новими завданнями

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

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

Зазвичай технічна команда працює так:

1. Product Owner (PO) досліджує ринок, аналізує наявні дані, описує UX та виділяє проблему, яку команді розробки потрібно вирішити.
2. На виході отримуємо опис завдання у вигляді тікета в Jira або на інших платформах.
3. Після чого на грумінгу команда розробки знайомиться з таском, а потім тікет йде у спринт.

Однак часто проблема виявляється більшою або складнішою за те, що лежить на поверхні. Розберемо цю ситуацію на простому прикладі.

Уявіть, що складаючи вимоги до завдання, РО описав трикутник (▲). Після презентації таска команді розробник пішов з розумінням, що йому потрібно зробити трикутник, але не обов’язково саме той, що уявляв собі РО (◢). Завершивши свою роботу, розробник передає завдання на тестування. QA-фахівець теж розуміє, що він тестує трикутник, але бачить його по-своєму (▶). На виході виявляється, що всі працюють над однією фігурою, але розуміють її по-різному.

Так відбувається, коли РО описує лише частину проблеми, показує команді лише «верхівку айсберга». У такому разі під час грумінгу обговорення з великою ймовірністю не піде далі поверхневої частини.

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

Таким чином, коли не до кінця зрозумілий та/або не повністю описаний тікет потрапляє у спринт, це призводить до:

• великої кількості багів і реджектів (50-60% багів виникають через нерозуміння вимог або недостатнє занурення в контекст проблеми);
• проблем із комунікацією;
• фейлів комітменту;
• низької мотивації команди;
• формування звички «розберемося під час спринту».

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

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

Основи складання юзер-сторі

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

Два основних принципи, якими потрібно керуватися, описуючи юзер-сторі:

1) максимально повний опис проблеми користувача;
2) ізолювання описуваної теми від інших.

Юзер-сторі можна описати по-різному, але є перелік компонентів, які мають бути присутніми завжди:

1. Story

Ми, наприклад, обираємо наступний формат:

AS a [роль конкретного користувача]
I WANT [досягти певної мети]
SO THAT [отримати розв’язання своєї проблеми]

Наприклад,

AS A website customer
I WOULD LIKE to get an additional offer during the buying process
SO THAT I can find a worthwhile and satisfying offer that I actually need for my mobile device.

Кількість ролей нічим не обмежена і має описувати всіх стейкхолдерів процесу. На одну роль може припадати декілька історій. Їх має бути стільки, скільки зможуть вичерпно пояснити проблему користувача.

2. Background Info

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

Наприклад,

To increase the average cart, we will display a window with special offers that are fully relevant to customers based on their mobile operating system. 92% of our customers visit us from their mobile devices. We would like to increase customer engagement and make them feel that their experience is more personal as if they were coming to a real store.

3. Scenarios

Сценарії — це прийняті рішення для усунення проблеми. Зазвичай вони готуються PO або в результаті обговорення з третьою стороною, а також можуть доповнюватися командою під час грумінгу.

Кількість сценаріїв залежить від специфіки проблеми та її аспектів. Описати всі можливі варіанти означає дійти до заснування айсберга, тобто описати проблему та її вирішення у всій повноті.

Ми використовуємо наступний формат опису сценаріїв:

Scenario 1

• Given
• When
• Then

Scenario 2

• Given
  • AND:
• When
• Then

Наприклад,

Pre-condition: the customer has added an item to the shopping cart from the ‘Product for Smartphones’ page.

Scenario 1 — Displaying the most relevant product.

GIVEN THAT I’m a website user
WHEN I added some product to the shopping cart
THEN I would like to see an individual offer I would accept.

4. Resources (optional)

Це необов’язковий пункт, який включає докази й підтвердження проблеми: скриншоти, відгуки та ін.

5. Additional Info (optional)

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

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

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

Важливо для розуміння

Щоб привести юзер-сторі у відповідність до заздалегідь визначених стандартів, члени команди повинні мислити в одному напрямку та на старті узгодити критерії, які допомагають стандартизувати формат.

Definition of Ready (DoR) — це критерій, що визначає, чи юзер-сторі містить усі необхідні деталі для всіх стейкхолдерів. Кожна команда матиме свій власний DoR, оскільки він значною мірою залежить від людей і контексту.

Приклад DoR:

• одиниця роботи написана у форматі ’User Story’;
• критерії приймання зрозумілі команді;
• команда оцінила історію;
• команда розуміє, як продемонструвати функції;
• критерії ефективності зрозумілі команді.

Definition of Done (DoD) — набір елементів, які мають бути завершені, перш ніж юзер-сторі буде вважатися виконаною.

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

Переваги ретельно описаної юзер-сторі

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

По-друге, зростає якість грумінгу. Цілісне обговорення завдань допомагає сфокусуватися на проблемі та не перемикати увагу на другорядні речі.

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

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

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

По-п’яте, такий підхід дозволяє легко вимірювати вплив наших дій на продукт. Коли ми знаємо, які проблеми були, як і скільки ми їх вирішували, відстежувати ефективність нашої роботи не важко.

Що зрештою

Головна ознака якісно складеної юзер-сторі — повнота розкриття проблеми, яку команді розробки належить вирішити. Прочитавши таку юзер-сторі, кожен член команди отримує спільне з усіма уявлення про завдання і очікуваний результат. Слабка юзер-сторі або не дає розуміння проблеми взагалі, або призводить до різного уявлення у різних членів команди.

За посиланням наводжу приклад юзер-сторі, який ми використовуємо в Techstack. На підтвердження ефективності цього підходу наведу декілька цифр, що демонструють результат, якого ми змогли досягти на одному з продуктів протягом року.

Якщо раніше на великій 20-поінтовій сторі ми могли видавати 5-10 багів, то зараз звели їхню кількість до 0-1. За меншими сторі (8-13 поінтів) статистика ще краща. Фейли комітментів стали для нас едж-кейсами, а раніше були нормою. Тепер ми можемо прогнозувати якість нашої розробки та робити реалістичні оцінки нашої роботи.

Всім охочим спробувати роботу в такому ж форматі пропоную використовувати наш шаблон.