Написання юзер сторі (історії користувачів) є ключовою практикою в agile software розвитку, що допомагає команді зрозуміти та приорітезувати вимоги проекту і є ефективним шляхом до комунікації з стейкхолдерами та членами команди. Написання ефективних юзер сторіс це важлива навичка для бізнес аналітиків. Таким чином, ви можете бути впевненими, що юзер сторі є чіткими, ліконічними та зрозумілими для всіх, хто бере участь в проекті.
Юзер сторі виникли в Extreme Programming приблизно в 1998 році та стали популярними з появою Agile на початку 2000-х. Основний шаблон для написання історій користувачів: «Як [тип користувача], я хочу [дія], щоб [ціль].», однак ви можете змінювати цей стиль залежно від потреб вашої команди Agile. Нижче, я покажу деякі поради щодо написання історій користувачів Agile та деякі ключові міркування та техніки, про які слід пам’ятати.
Почніть з користувача (user)
Юзер сторі (історії користувачів) завжди повинні починатися з користувача і зосереджуватися на проблемі, яку користувач намагається вирішити. Це полегшує стейкхолдерам і членам команди розуміння вимоги та її важливість. Наприклад, замість того, щоб написати «Як системний адміністратор, я хочу мати можливість створювати резервні копії бази даних», пишеться «Як користувач, я хочу мати можливість легко відновити втрачені дані у разі збою системи».
Визначте користувача, визначте дію та вкажіть мету
Почніть із визначення типу користувача, для якого ви пишете історію. Це може бути клієнт, співробітник або будь-яка інша особа, яка буде взаємодіяти з продуктом.
А потім визначте, яку конкретну дію потрібно виконати користувачеві, щоб досягти своєї мети. Це може бути функція, яку вони хочуть використати, завдання, яке вони мають виконати, або проблема, яку вони мають вирішити.
І після цього вкажіть, що користувач сподівається досягти, виконавши цю дію. Це може бути бізнес-ціль, наприклад збільшення продажів, або особиста ціль, наприклад, економія часу.
До теми: ВІГЕРСОПЕДІЯ – Найважливіший урок про розробку програмного забезпечення за останні 50 років
Притримуйтесь простоти, лаконічності та якості
Історії користувачів мають бути простими та зрозумілими, короткими та по суті. Вони повинні бути написані простою мовою, уникаючи технічного жаргону. Мета полягає в тому, щоб переконатися, що всі, хто бере участь у проекті, розуміють вимоги та можуть легко повернутися до них у разі потреби. Хороша історія користувача має бути чимось, що можна зробити за один спринт.
Рішення, яке допоможе в цьому, полягає у використанні методу INVEST, мнемоніки, що означає незалежний (Independent), договірний (Negotiable), корисний (Valuable), оцінний (Estimable), невеликий (Small) і той, який можна протестувати (Testable). Це добре відома структура, яка допомагає оцінити якість історій користувачів у гнучкій розробці програмного забезпечення.
Пишіть короткі та описові розповіді
Історії користувачів мають бути короткими та лаконічними, зосереджуватися на одній вимозі чи функції. Описові історії ефективніші, ніж розпливчасті або двозначні історії. Наприклад, замість того, щоб написати «Як користувач, я хочу, щоб система була швидкою», напишіть «Як користувач, я хочу, щоб система завантажувалася протягом 2 секунд».
Пишіть для команди
Історії користувачів є інструментом спілкування для команди розробників. Переконайтеся, що вони написані чітко та легко для розуміння всією командою. Наприклад, замість використання шаблону «Як… я хочу… щоб…» використовуйте шаблон «Я хочу», який є ще одним поширеним і ефективним способом написання історій користувачів. Це допомагає зосередитися на користувачеві та його потребах і полегшує розуміння вимог. Формат такий: «Як [користувач], я хочу [вимоги]».
Також спробуйте застосувати прийом «Картка, розмова, підтвердження» (Card, Conversation, Confirmation). Це формула для створення та вдосконалення історій користувачів у гнучкій розробці програмного забезпечення. Крім того, спосіб гарантувати, що історії користувачів чітко визначені та добре зрозумілі всій команді.
Це цікаво: Історії користувача vs. Історії роботи (User vs. Job Stories)
Включайте критерії прийняття (acceptance criteria)
Критерії прийняття (acceptance criteria) — це умови, які мають бути виконані, щоб юзер сторі (історія користувача) вважалася завершеною. Вони забезпечують ясність і гарантують, що кожен, хто бере участь у проекті, розуміє, що потрібно для завершення історії. Під час написання юзер сторі (історій користувачів) важливо включити критерії прийняття, переконавшись, що вони чіткі, стислі та такі, що їх можна протестити. Використовуйте формат критеріїв прийняття структури, як-от «Дано-коли-потім». Цей формат допомагає чітко визначити умови, за яких юзер сторі (історія користувача) повинна вважатися завершеною. Наприклад: «Дано, що користувач увійшов у систему; Коли вони натискають кнопку «Додати до кошика»; Потім товар повинен бути доданий до кошика користувача, і загальна сума кошика має відповідно оновитися».
Фокус на цінності
І останнє, але не менш важливе: зосередьтеся на цінності, яку історії принесуть користувачеві. Це допомагає визначити пріоритетність вимог і гарантує, що найцінніші історії розглядаються в першу чергу. Наприклад, замість того, щоб написати «Як користувач, я хочу мати можливість змінити свій пароль», напишіть «Як користувач, я хочу мати можливість змінити свій пароль для підвищення безпеки».
Щоб написати найкращі юзер сторі (історія користувача) Agile, зосередьтеся на користувачеві, будьте простими, пишіть короткі та описові історії, використовуйте формат «Я хочу», включаючи критерії прийняття, і зосередьтеся на цінності, або все ж застосуйте формулу « Картка, розмова, підтвердження» та метод INVEST для оцінки історій користувачів, щоб переконатися, що історії зосереджені на потребах і цілях користувачів, їх можна ефективно впроваджувати та перевіряти та надавати цінність для бізнесу.
Крім того, написання ефективних історій користувачів має вирішальне значення для успіху будь-якого проекту гнучкої розробки програмного забезпечення. Бізнес-аналітики, які можуть написати чіткі та лаконічні історії користувачів, які зосереджуються на потребах користувачів і створюють цінність для бізнесу, можуть допомогти переконатися, що кінцевий продукт відповідає потребам користувачів і бізнесу.
Оригінальна стаття – Writing Agile User Stories: Key Considerations and Techniques від Erivan Ramos, переклад – Оксана Агратіна, ревью – Іван Вільчавський. Оригінальне зображення від Kelly Sikkema з сайту Unsplash.
Дякую за статтю. В принципі непогано як оглядова стаття про техніку юзер сторі. Але на спеціалізованому сайті про бізнес аналіз хотілось би читати щось більш грунтовне. І бажано не просто переклад статей з англійської мови. Але не сприйміть як критику. Дякую що стараєтесь і розвиваєте напрямок!
Привіт, Макс. Дякую за коментар. Категорично підтримую усі побажання і готовий підтримувати усіх авторів, що пишуть якісні матеріали українською. Наразі таких небагато і пишуть дуже рідко. Тому наразі виходимо з цієї ситуації і забезпечуємо такий формат – виключно переклади.