Сьогодні техніка "User Story" (історія користувача) є найпопулярнішою технікою для опису вимог в ІТ-проектах. Чому ця техніка стала такою популярною? Стислість формулювання та орієнтованість на цінність для стейкхолдера. Все це зробило User Story оптимальним варіантом Agile.
User story мають бути написані так, щоб їх міг прочитати та зрозуміти як представник бізнесу, так і член команди розробки. І при цьому історії мають відповідати критеріям якості.
Критерії якості вимог
Загальноприйнятий набір критеріїв якості описується акронімом INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable.
INVEST каже, що історія користувача повинна:
не залежати від інших історій користувача,
її межі мають бути предметом переговорів,
вона має приносити достатню цінність для клієнта,
команда розробки повинна мати можливість оцінити складність розробки,
вона повинна бути досить маленькою, щоб її можна було розробити за одну ітерацію, і
її можна протестувати, щоб переконатися, що вона відповідає потребам клієнта.
У цій статті ми поговоримо про те, як бізнес-аналітику зробити історії досить маленькими або, іншими словами, як декомпозувати великі історії.
Що таке SMALL?
Почнемо з того, що критерій якості Small для історій користувача є доволі суб'єктивним. Те, що одна команда вважає за невелику історію, для іншої може здатися величезним епіком. Наприклад, історія відноситься до функціональності перегляду інформації про користувачів системи у вигляді таблиці з операціями сортування, фільтрації, групування та пошуку за рядом атрибутів. Якщо команда реалізовуватиме всі ці операції з 0, то роботи багато, і історію слід розбити. Але якщо в розробці використовується стандартний компонент, який все це підтримує з коробки, доцільність розбиття на окремі історії під великим питанням.
І все ж таки великі історії – головний біль для product owner-а та команди розробки, у тому числі бізнес-аналітика. Якщо історія взагалі не поміщається в один спринт, то фундаментальне правило регулярної доставки цінності клієнту порушується. Навіть якщо розробка однієї історії займає цілком один спринт, то є значний ризик, що за результатами спринта бізнес не отримає нічого. Якщо щось може піти не так, то воно піде не так. Тому стандартна рекомендація: до спринту має входити 6-10 історій користувача.
Не дивлячись на те, що всі історії користувачів відносно унікальні, Майк Кон запропонував 5 універсальних підходів до декомпозиції, які описуються акронімом SPIDR (якщо хочете, можете додати літеру Е між D та R та отримати павука 😊)
SPIDR або 5 підходів до декомпозиції User Story
SPIDR розшифровується як Spike, Path, Interface, Data, Rules. Давайте розглянемо кожну складову докладно.
Spike (Спайк)
Spike — це дослідницька задача, яка виконується з метою допомогти команді розробників краще зрозуміти, що потрібно для реалізації історії користувача. У деяких випадках історія велика, тому що в ній є багато технічних невідомих. Спайки допомагають розібратися у складних технічних аспектах, провести дослідження чи експерименти.
Приклад:
Історія користувача: "Як користувач, я хочу оплачувати покупки через різні платіжні системи, щоб вибрати найбільш вигідний/зручний спосіб."
Якщо раніше ми не працювали з цими платіжними системами, то для команди історія може бути занадто велика.
Не дивлячись на те, що ми говоримо про підходи до розбиття історій користувача, вам не обов'язково формулювати спайк у форматі User Story. Спайк не приносить сам собою користь бізнесу. Він приноситиме лише непряму цінність, допомагаючи команді краще розуміти, як реалізувати відповідну історію.
Скоріше вам підійде звичайний формат завдання. Для нашого прикладу це: "Дослідити API різних платіжних систем і з'ясувати, як їх інтегрувати."
Як зрозуміти, що вам потрібен спайк
Спайк потрібен, якщо у команди недостатньо інформації, щоб розбити історію на підзадачі в процесі планування спринту. За перший спринт команда зможе завершити спайк, а вже в наступному взяти відповідну історію користувача і розбити її на підзадачі, використовуючи знання, отримані в ході дослідження.
Те, що спайк йде першим в абревіатурі SPIDR, не означає, що з нього потрібно починати. Скоріше, вірно зворотнє - цей метод слід розглядати тільки після оцінки інших методів. В ідеалі, будь-яке технічне дослідження повинно проводитися в рамках того ж спринту, що і історія користувача.
Path (Шлях)
Іноді історія користувача буває великою, тому що користувач може використовувати кілька альтернативних шляхів для досягнення результату.
Приклад:
Історія користувача: "Як користувач, я хочу відновити пароль, щоб отримати доступ до свого облікового запису."
Шляхи:
Шлях 1: "Як користувач, я хочу відновити пароль через електронну пошту."
Шлях 2: "Як користувач, я хочу відновити пароль через SMS."
Ще один популярний приклад: у разі оформлення замовлення користувач може здійснити покупку за допомогою кредитної картки або подарункової картки, купленої кимось іншим.
У цьому випадку ми можемо розбити цю історію таким чином: одна історія для покупок за допомогою кредитної картки та інша історія для підтримки використання подарункової картки. Може виникнути питання: а чи варто розбивати історію про покупку за допомогою кредитної картки на окрему історію для Visa та окрему історію для MasterCard? Скоріше ні, ніж так. А ось варіант оплати через PayPal, Stripe буде доцільно розділити на окремі історії.
Interface (Інтерфейс)
Interface — це поділ історії за різними інтерфейсами або взаємодіями з користувачем. Це особливо корисно, коли історія стосується зміни або додавання функціональності до інтерфейсу програми.
Приклад:
Історія користувача: "Як користувач, я хочу переглядати історію замовлень, щоб бачити свої попередні покупки."
Інтерфейси:
Інтерфейс 1: "Як користувач, я хочу переглядати історію замовлень на веб-сайті."
Інтерфейс 2: "Як користувач, я хочу переглядати історію замовлень у мобільному додатку."
Інший приклад — створення спочатку простого інтерфейсу користувача, а потім окрема історія, яка робить інтерфейс користувача більш зручним. Наприклад, додавання функції drag&drop.
Ще один приклад – експорт даних у різних форматах. Спочатку історія може включати вивантаження у форматі Word, Excel і PDF. Цю історію можна поділити на три – по одній на кожен формат.
Data (Дані)
Data — це декомпозиція історії по різних наборах даних або типах даних. Це може бути корисним, коли історія стосується роботи з великими або складними наборами даних.
Приклад:
Історія користувача: "Як адміністратор, я хочу аналізувати звіти про продаж, щоб приймати управлінські рішення."
Дані:
Дані 1: "Як адміністратор, я хочу аналізувати звіти про продаж по регіонах."
Дані 2: "Як адміністратор, я хочу аналізувати звіти про продаж за категоріями продуктів."
Якщо ми створюємо каталог товарів, то окремо можна створити історію для управління текстовою інформацією про товар — назва, ціна, залишок на складі тощо — і ще одну, щоб додати зображення товару.
Rules (Правила)
Rules — це декомпозиція історії по різних бізнес-правилах або логічних умовах. Це допомагає розбити складну бізнес-логіку на простіші частини.
Історії користувача можуть мати безліч правил для забезпечення надійної функціональності. Одним з варіантів поділу історій користувача є пом'якшення правил для першої історії та обробка їх у наступній. Наприклад, ми можемо відкласти реалізацію вимог до продуктивності, рівня доступу або суворої валідації даних.
Приклад:
Історія користувача: "Як новий користувач, я хочу зареєструватися на сайті, щоб отримати доступ до додаткових функцій."
Правила
Правило 1: Валідація електронної пошти
1. Як новий користувач, я хочу, щоб система перевіряла правильність формату моєї електронної пошти при реєстрації, щоб уникнути помилок під час введення.
Критерії приймання:
Користувач вводить адресу електронної пошти на сторінці реєстрації.
Система перевіряє, чи адреса електронної пошти відповідає допустимому формату.
Якщо неправильний формат, система виводить повідомлення про помилку.
Правило 2: Мінімальна довжина пароля
Як новий користувач, я хочу, щоб система вимагала мінімальну довжину пароля під час реєстрації, щоб забезпечити безпеку мого облікового запису.
Критерії приймання:
Користувач вводить пароль на сторінці реєстрації.
Система перевіряє, чи пароль мінімальної довжини (наприклад, не менше 8 символів).
Якщо пароль надто короткий, система виводить повідомлення про помилку.
Висновок
Щоб правильно декомпозувати власні історії вам знадобиться практика. Прислухайтеся до зворотнього зв'язку від команди:
Чи влаштовує їх поточний розмір історій?
Історії здаються їм надто великими чи надто маленькими?
Які аспекти з SPIDR викликають у них складності?
При цьому не потрібно намагатися залучати всю команду до декомпозиції. Ризик тут полягає в тому, що у вас може не вистачити технічних знань, щоб вибрати найкращі варіанти декомпозиції. Наприклад, ви можете розділити історію на трохи менші історії, і це матиме сенс з погляду бізнесу, але насправді це значно ускладнить технічну реалізацію та/або тестування.
Зайве дроблення ускладнює процес управління беклогом, збільшує витрати на обговорення, створення підзавдань та інші накладні витрати. Шукайте золоту середину.
Чим частіше ви будете практикувати SPIDR, чим краще ви знатимете проект і бізнес, чим довше ваша команда залишатиметься стабільною, тим краще буде результат декомпозиції. Можна стверджувати одне: якщо розділити історії та зробити їх невеликими, команді буде набагато простіше регулярно приносити користь бізнесу та успішно досягати цілей спринту.
Якщо хочете попрактикувати написання якісних історій – приходьте на наш комплексний тренінг з бізнес-аналізу. Якщо відчуваєте, що вам заважає відсутність технічних знань, то чекаємо на курс «Technical skills for Business Analyst». Розклад тренінгів від Art of Business Analysis
コメント