User story – що це, для чого і чи можна обійтися без них?

Історії користувачів, або ж user story, – це частина аджайл-підходу, що допомагає перефокусувати увагу з написання на обговорення вимог. Кожна історія складається з одного, максимум двох речень. Її задача – сколихнути обговорення фічей і функціональності, які ця історія репрезентує.

Юзер сторі – це спосіб описати потрібну функціональність елементів продуктового беклогу. Високопріоритетні user story зазвичай краще деталізовані; низькопріоритетні – гірше. Більше деталей додаються командами зі зростанням пріоритетності історії – або створюючи критерії прийому (acceptance criteria), або ж розділяючи великі сторі на менші. Ну, або і те, і інше.

Нижче ми розповімо більше про user story, шаблони їх написання, а також покажемо кілька прикладів.

Переклад статті Майка Кона здійснено для вас командою BrainRain.

Що таке user story?

Історія користувача (юзер сторі, user story) – це стислий, простий опис фічі, поданий з перспективи людини, якій потрібен новий функціонал. Зазвичай це – користувач або замовник системи. User story пишуться за простим шаблоном:

Як < тип користувача >, я хочу < мета >, щоб < причина >.

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

Сьогодні історії користувачів так само легко складаються в тасках Jira або картках Trello. Та не дозволяйте тому факту, що історія користувачів живе всередині інструменту, збивати вас із пантелику. Видаляйте її легко і назовсім, коли user story стає неактуальною!

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

Як виглядає хороша user story?

Agile юзер сторі складаються з трьох аспектів (трьох С), названих Роном Джефрісом у 2001 році:

1. Card – картка: письмовий опис історії, що використовується для планування і в ролі нагадування.
2. Conversation – розмова: комунікація довкола історії, що слугує для її деталізації.
3. Confirmation – підтвердження: тести і документація, які можуть використовуватися для визначення готовності історії.

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

Як писати user story

Щоб писати гарні історії в Scrum, потрібно розуміти базовий шаблон user story, фокусуватися на користувачеві, а також мати чітку картину потрібної функціональності.

Шаблон user story

Як < тип користувача >, я хочу < мета >, щоб < причина >.

Зразки історій користувачів

Це реальні приклади user story, що описують бажану функціональність ранніх версій сайту Scrum Alliance.

• Як зареєстрований учасник сайту, я можу заповнити заявку на отримання ліцензії Certified Scrum Trainer, щоб мати змогу читати курси Certified Scrum Master (CSM) і Certified Scrum Product Owner (CSPO) і сертифікувати учасників цих курсів.
• Як тренер, я хочу, щоб у моєму профілі був список моїх найближчих курсів і посилання на детальну сторінку кожного курсу, щоб перспективні учасники могли знайти мої курси.
• Як відвідувач сайту, я можу бачити старі новини, яких більше немає на головній сторінці, щоб мати доступ до інформації з минулого або новин, про які згадують інші.
• Як відвідувач сайту, я можу бачити перелік усіх запланованих сертифікаційних курсів за сторінками, якщо їх багато, щоб мати змогу обрати курс, що підходить мені якнайкраще.

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

Хто пише історії користувачів?

Та будь-хто.

Чи пише юзер сторі Продакт Оунер?

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

Між іншим, автор юзер сторі – значно менш важливий, ніж учасники її обговорення.

Коли пишуться історії користувачів?

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

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

А можна більш загальні приклади історій користувачів?

Звісно, ось, наприклад, типові юзер сторі для сайту розміщення вакансій і пошуку роботи:

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

Зразки епіків

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

Великі юзер сторі зазвичай менш деталізовані і відомі широкому загалу під назвою “епіки”.

Ось приклад такого епіку з десктопного бекап-продукту.

• Як користувач, я можу створити бекап усього мого жорсткого диску.

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

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

Як деталізуються історії користувачів?

Є два способи додавати деталей у юзер сторі:

• Розділяючи історію на менші;
• Додаючи критерії прийому до user story (acceptance criteria).

Коли відносно велика історія розділяється на менші, природньо буде припустити, що з’являються нові деталі. Зрештою, навіть кількість контенту мусить зрости.

Критерії прийому – це високорівневий тест прийому, який стане здійсненним після завершення роботи над гнучкою юзер сторі. Розгляньмо наступний зразок історії:

• Як віце-президент маркетингу, я хочу провести рев’ю перфомансу минулих рекламних кампаній у святкові періоди, щоб виявити, які з них були прибутковими.

Додаймо деталі через критерії прийому:

• Переконайтеся, що переглянуто найважливіші для торгівлі свята: Різдво, Великдень, День Президента, День матері, День батька, День праці, Новий рік.
• Включіть сюди свята, які розповсюджуються на два календарних роки.
• Святкові періоди можуть тривати від одного свята до іншого (наприклад, від Дня подяки до Різдва).
• Святкові періоди можна встановлювати за певну кількість днів перед настанням свята.

Чи можуть юзер сторі замінити вимоги?

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

Хоч продуктовий беклог може розглядатися як заміна документу з вимогами на традиційному проєкті, та важливо пам’ятати, що написана частина історії користувача (“Як користувач, я хочу…”) незавершена, аж доки по ній не проведено дискусію.

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