Що таке User Story і як її писати

User Story (історія користувача) – це неформальне загальне пояснення функцій програмного забезпечення, написане з точки зору кінцевого користувача. Її мета полягає в тому, щоб сформулювати, яку цінність для замовника несе функціонал програмного забезпечення. Вона формулює не тільки бізнес-цінність, а й вимоги для розробки й тестування. User Story називається так, бо вона створюється через розповідь, як історія.

Можна також зустріти й інше визначення – це інструмент, завдяки якому замовник точно дає зрозуміти свої потреби. 

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

Сам формат можна викласти в короткому реченні на кшталт: «Як персона, я хочу, так що...» (As a [person], I [want to], [so that]). Так користувач/замовник пояснює, що саме він хоче і навіщо. 

Далі розглянемо цей шаблон більш детально, щоб стало зрозуміліше, як саме повинна звучати User Story:

«Персона» – для кого ми це створюємо? 

«Хочу» – тут описуються наміри людей, а не функції, які вони використовують. 

«Так що» – яка мета? Якої загальної вигоди потрібно досягти? Яку проблему необхідно вирішити?

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

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

Як писати User Story?

Найперше – писати потрібно з дотриманням норм орфографії та граматики.

Під час написання історії користувача необхідно уникати ненавмисного написання технічних завдань.

Історії користувачів фіксують лише найважливіші елементи вимоги:

• для кого це?
• чого очікуєте від системи?
• чому це важливо?

Існує доволі багато порад з написання User Story. Основні будуть розглянуті далі.

Практичні поради з написання історій користувача: 

• краще написати багато історій менших, ніж кілька громіздких;
• краще писати цілою командою, щоб не загубити важливі для продукту, бізнесу і користувачів нюанси;
• кожна історія в ідеалі повинна бути написана без технічного жаргону;
• точно описати потреби користувача;
• історії повинні бути написані таким чином, щоб за ними можна було протестувати;
• тести повинні бути написані до коду;
• як можна довше варто уникати UI. Історія повинна виконуватися без прив'язки до конкретних елементів;
• кожна історія повинна містити оцінку складності, а також кількості часу для реалізації;
• історія повинна мати кінцівку – тобто завершуватися конкретним результатом;
• історія має бути зрозумілою для всіх учасників проєкту;
• User Story повинна відповідати моделі INVEST.

Далі розглянемо детальніше мнемоніку INVEST – критерій гарної історії:

• I – independent – незалежна від інших історій, тобто історії можуть бути реалізовані в будь-якому порядку;
• N – negotiable – обговорювана, відображає суть, а не деталі; не містить конкретних кроків реалізації;
• V – valuable – цінна для клієнтів, бізнесу та стейкхолдерів;
• E – estimable – оцінюється за складністю і трудовитратами;
• S – small – компактна, може бути зроблена командою за одну ітерацію;
• T – testable – така, яку можна протестувати (перевірити), має критерії приймання.

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