USER STORY для бізнес аналітика

Сьогодні ми поговоримо про те, що таке user story загалом, як поняття, розглянемо кілька причин, з яких user stories з’явилися у сфері девелопменту та в IT-компаніях.

Подивимось, як складати юзер сторі й розглянемо кілька простих прикладів.Поговоримо про INVEST-критерії, які допомагають нам складати правильну user story, а також про acceptance criteria — обов’язкову частину юзер сторі, що допомагає окреслити все, що необхідно зробити в межах user story.

Також розглянемо приклад, який я підготував до цієї статті, а саме user story в Jira.Подивимось, як вона виглядає «в реальному житті», і детальніше зупинимося на перевагах і ризиках, пов’язаних із використанням user stories на практиці.

Що таке user story?

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

Чому юзер сторі взагалі з’явились у software development та IT?

Насправді вони почали з’являтися практично 20–25 років тому. І раніше вони не застосовувалися широко, або ж застосовувалися в інших сферах, але не в IT.

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

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

При цьому нам уже не так важливий документ, що описує все до найменших деталей — нам важливий результат. Але з іншого боку, потреба ставити завдання розробникам нікуди не зникла. Їм, як і раніше, треба розуміти, що робити наступного тижня. І тут з’явилися user stories — спосіб опису вимог, що задовольняє Agile-принципи.

Як виглядає user story?

Вона дуже проста: це одне-два речення, що складаються з трьох частин:

«Я, як X, хочу Y, щоб Z…»

де X — це персонаж, від імені якого ми розповідаємо, для кого ми розробляємо функціонал;Y — те, що йому потрібно (завдання для розробника чи команди);Z — найважливіша частина: навіщо це потрібно користувачеві, яку саме цінність він отримає.

Ось кілька простих прикладів.

1. «Як співробітник першої лінії підтримки, я хочу відповідати на звернення за допомогою шаблону, щоб пришвидшити обробку схожих звернень».

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

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

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

Далі поговоримо про INVEST-критерії. Що це таке?

Це шість критеріїв, яким кожна юзер сторі має відповідати, аби задовольняти Agile-принципи.

1. Independent (незалежність) — кожна юзер сторі має бути автономною. Якщо у вас є дві user stories, що залежать одна від одної, і ви плануєте одну в перший спринт, а іншу в другий, то після першого спринту користувач усе одно не зможе скористатися функціональністю, бо частина її реалізації залежить від другої user story. Це суперечить Agile.

2. Negotiable (відкритість до обговорення) — юзер сторі не має містити надмірних деталей на кшталт крайових випадків, специфічних перевірок тощо. Усе це можна з’ясувати під час розмови — наприклад, на плануванні чи грумінгу.

3. Valuable (цінність) — кожна юзер сторі повинна нести цінність. Якщо вона не приносить користі, це не user story, а просто технічне завдання.

4. Estimatable (можливість оцінки) — юзер сторі має бути сформульована так, щоб команда могла її оцінити: за складністю чи часом. Якщо ви читаєте історію на кшталт «Як зареєстрований користувач, я хочу, щоб сайт був зручнішим», то незрозуміло, як її оцінити, адже «зручнішим» — надто розпливчасте поняття.

5. Small (невелика) — юзер сторі має бути достатньо маленькою, щоб уміститися в один спринт. Якщо ваша команда бере 10 умовних одиниць завдань на спринт, а юзер сторі оцінили в 12, її не встигнуть зробити за один спринт. Тоді краще розділити її на дві менші.

6. Testable (можливість тестування) — юзер сторі має піддаватися перевірці. Це досягається завдяки acceptance criteria, про які поговоримо далі.

Якщо подивитися на практичну частину, то юзер сторі як артефакт (документ) складається з чотирьох елементів:

1. User Story: ті самі одне-два речення «Я, як X, хочу Y, щоб Z…».

2. Acceptance Criteria (критерії приймання) — характеристики, яких має дотримуватися функціонал, щоб ми вважали завдання виконаним. В acceptance criteria зазначається, що входить у рамки історії, чого в ній немає, можливі обмеження, нефункціональні вимоги тощо. На основі цих критеріїв тестувальники пишуть тест-кейси.

3. Additional Materials (додаткові матеріали) — будь-яка допоміжна чи додаткова інформація: прототипи, діаграми, скрипти, правила та стандарти, контакти експертів. Тобто все, що допоможе розробникам реалізувати завдання.

4. Comments / History (коментарі / історія) — у більшості інструментів на кшталт Jira чи TFS є можливість залишати коментарі, що фіксують домовленості, досягнуті під час обговорень, щоби нічого не губилося і було враховано.

Ось кілька прикладів acceptance criteria (на прикладі юзер сторі про шаблони звернень).

1. «Вибір шаблону здійснюється за допомогою випадаючого списку з вбудованим пошуком за ключовими словами». Це проста, «людська» мова, зрозуміла всім.

2. Можна оформити acceptance criteria у вигляді ще однієї user story: «Як оператор, я хочу вибирати шаблон…». Це цілком припустимо й дає гнучкість у разі потреби розбити велику історію на кілька менших.

3. Можна використовувати формат на кшталт тест-кейса, де є Given/When/Then:

   • Given: У зверненні існує шаблон із макросами.

   • When: Користувач обирає цей шаблон.

   • Then: У підставленому тексті всі макроси замінюються на конкретні дані заявника.

Це більш структурований і прозорий спосіб описання критеріїв приймання, який до вподоби тестувальникам.

4. Якщо вам важко описати всі деталі безпосередньо в історії, але є вже затверджена специфікація чи діаграма процесів, то в acceptance criteria можна просто вказати, що реалізація має відповідати конкретному документу.

5. Не забувайте про нефункціональні вимоги, наприклад: «Текст підставляється впродовж пів секунди після вибору шаблону».

6. Також корисно описувати межі історії: наприклад, «Редагування шаблону входить до іншої user story». При цьому варто додати посилання на неї.

До цієї статті  я підготував приклади юзер сторі в backlog. Я взяв за основу вебсайт школи SMART і сформував кілька тестових завдань, які зобразив у backlog.

Ось ви бачите перший спринт із трьома завданнями: «кнопка “Залишити заявку”», «кнопка “Дізнатися детальніше”» тощо.

Можна відкрити будь-яку user story, наприклад, подивитися, який у неї пріоритет, статус, оцінка (скільки балів), у якому спринті вона має бути виконана тощо.

Власне, саме описання: «Як X, я хочу Y, щоби Z…».

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

Щоб розробникам було простіше, я додав скриншот аналогічної кнопки на іншій сторінці — це теж спрощує їм роботу.

У Jira є можливість додавати коментарі, і вся історія змін зберігається. Тож коли хтось інший відкриє цю user story, він побачить усі уточнення та відповіді.

Тепер поговоримо про переваги й ризики, пов’язані з використанням user stories.

Переваги

1. Вони зрозумілі всім, бо описані простою людською мовою без формальних шаблонів.

2. Не потребують багато часу на складання (раніше ми витрачали купу часу на опис і підтримання документації, а тепер можемо зосередитися на цінності).

3. Фокус на цінності для користувача. Це відповідає Agile-принципам, коли і розробник, і продукт-оунер, і будь-хто в команді може запропонувати ідеї реалізації.

4. Ними легко керувати: вони маленькі, незалежні, їх можна планувати, розбивати чи об’єднувати.

Ризики

1. Можуть виникати непорозуміння чи різне тлумачення, бо описи в user stories «побутові» й не завжди однозначні.

2. Потрібно, щоб у команди був достатній досвід і знання контексту. Коли люди тільки починають працювати, юзер сторі можуть бути надто узагальнені, і ви ризикуєте в результаті отримати щось не те, що очікували. На початкових етапах варто додавати більше деталей (наприклад, у acceptance criteria, додаткові специфікації). Коли команда вже «в темі», деякі деталі можна опустити.

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

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

У таких випадках більше пасують специфікації, технічні завдання і, відповідно, waterfall- або інші лінійні підходи, а не Agile.