Знайома ситуація: ви звертаєтеся до ІТ-компанії з проханням оцінити вартість розробки, а у відповідь отримуєте відмовки на кшталт «надішліть нормальне ТЗ — тоді порахуємо». Або завуальовану пропозицію спершу щедро оплатити складання докладної специфікації, а вже потім, на її підставі, зробити розрахунок вартості. Так давно вже ніхто не робить.
Чому «нормальне ТЗ» — це відповідь ні про що
При цьому ніхто до ладу не може пояснити, що таке те саме «нормальне» ТЗ. І, що важливіше, ніхто не гарантує: коли документ нарешті буде складений, вартість розробки залишиться для вас прийнятною. Виходить дивна угода — ви платите за текст, який лише згодом покаже, чи по кишені вам сам проєкт.
Потрібен інший вхід у розмову про гроші: такий, де оцінка й документація з'являються одночасно, а не одне після одного.
Після того як був описаний метод подання вимог бізнес-рівня через user stories, усе інше безнадійно застаріло.ANIART
Що таке user story
User story — це коротке формулювання наміру, яке описує щось, що система має робити для користувача.
- User story не є детальним описом вимог — тобто детального опису інтерфейсу чи реакцій на дію в ній немає. Це обговорюване подання наміру.
- Вона коротка й легко читається — зрозуміла розробникам, стейкхолдерам і користувачам.
- Найголовніше: кожна user story легко піддається естимуванню, тож зусилля, потрібні для реалізації, можна визначити швидко.
Як виглядає ідеальна історія
Ваша ідеальна user story має виглядати так:
Як <РОЛЬ користувача>, я <ДІЯ>, <ЦІННІСТЬ>.
А далі до цього формулювання додаються три блоки:
- Критерії приймання.
- Обробка помилок.
- Технічні нотатки.
Роль
Це користувачі або групи користувачів. Наприклад, у вашій системі їх не дуже багато — Користувач, Гість, Оператор і Адміністратор.
Дія
Це суть історії, «що потрібно зробити». Що можна поліпшити. Дія має бути одна — основна. Немає сенсу описувати «авторизується й виконується пошук» або «вказує параметри пошуку й виконує пошук». Зазначте ту дію, яка вам справді потрібна.
Важливо описувати історію на рівні «ЩО?» робиться, а не «ЯК?». Це головне в історії. Опишіть проблему, а не її розв'язання.
Цінність
Ваша історія обов'язково має мати цінність — результат, обов'язково має впливати на когось. Цей вплив зрештою веде до мети, яка має для вас цінність. Поняття цінності (value) можна замінювати на вплив (impact).
Приклади з реальних проєктів
Нижче — приклади того, як виглядають користувацькі історії, узяті з реальних проєктів.
Що ви отримуєте, підготувавши історії
Підготувавши user story, ви сформулювали бізнес-цінність для кінцевого користувача. Але принада користувацької історії ще й у тому, що вона формулює не лише бізнес-цінність, а й вимоги для розробки та тестування.
Тобто той самий набір історій служить чудовою документацією бізнес-рівня — щоб швидко зрозуміти, що саме робить ваша система.
Оцінка
Кожна історія піддається естимуванню, тож зусилля на реалізацію визначаються швидко — без попереднього багатотижневого опису.
Документація
Готові історії — це business level документація: із них видно, що робить система, без занурення в інтерфейси.
Вимоги до розробки
Формулювання наміру з критеріями приймання одразу лягає в роботу команди розробки.
Основа для тестування
Критерії приймання дають те, за чим історію перевіряють на відповідність — тести пишуться до коду.
Поради щодо написання користувацьких історій
- Краще написати багато менших історій, ніж кілька громіздких.
- Кожну історію в ідеалі варто писати, уникаючи технічного жаргону.
- Історії мають бути написані так, щоб їх можна було протестувати. Тести мають бути написані до коду.
- Якомога довше варто уникати UI: історія має виконуватися без прив'язки до конкретних елементів.
- Кожна історія має містити оцінку.
- Історія повинна мати кінцеву цінність — тобто приводити до конкретного результату або справляти вплив.
- Історія має вміщуватися в ітерацію.
INVEST: критерії якості user story
Скрам-посібник пропонує шість критеріїв, за якими перевіряють якість історії. Ось вони — і те, як ми читаємо кожен із них у роботі.
| Критерій | Scrum guide | ANIART |
|---|---|---|
| Independent | Reduced dependencies = easier to plan | Незалежна. Максимально зменшені взаємозалежності з іншими історіями. Історію легко виокремити й реалізувати. |
| Negotiable | Details added via collaboration | Обговорювана. Опис достатній для розуміння всіма учасниками: після прочитання всі готові вносити доповнення. |
| Valuable | Valuable | Несе зрозумілу цінність. |
| Estimable | Too big or too vague = not estimable | Придатна до оцінки. Надто великі або нечітко сформульовані історії складно оцінити конкретно. |
| Small | Can be done in less than a week by the team | Достатньо компактна, щоб бути зробленою менш ніж за тиждень при роботі всієї команди. |
| Testable | Good acceptance criteria | Тестована. Достатні критерії приймання, щоб перевірити історію на відповідність їм. |
Як це працює на практиці
- Формулюємо намір. Для кожної ролі — Користувач, Гість, Оператор, Адміністратор — записуємо одну основну дію та цінність, до якої вона веде.
- Додаємо критерії приймання. До кожної історії — умови, за якими її перевірятимуть, а також обробку помилок і технічні нотатки.
- Перевіряємо за INVEST. Історія, яка не проходить за «Small» чи «Estimable», розбивається на дрібніші.
- Оцінюємо. Кожна історія отримує оцінку — і з цих оцінок складається вартість розробки.
