User story — історія не просто так
Стаття про те, що таке user story, звідки вона взялась і як насправді варто її використовувати.
Напевно, багато з нас чули про таку річ як user story і, здається, що тут може бути незрозумілого або як взагалі їх можна використовувати неправильно. Але, як показує мій досвід, на жаль, це відбувається не так рідко.
Часто я чую історії розробників про те, що на їх проекті використовували методологію Scrum і вона не працювала, і взагалі, ця “модна штука” не має нічого корисного і створена лише з метою організувати більше зустрічей, заважаючи при цьому роботі, а також є обґрунтуванням існування Scrum коучів, майстрів і улюбленою іграшкою PMів. Останні кілька місяців я проводжу співбесіди на посаду middle QA і від багатьох часто чую, що вони працюють за видозміненим Scrum або навіть, що ще більш лякаюче, за “майже ідеальним Scrum”. Але як тільки я починаю слухати процеси на їх проекті, мені одразу стає зрозумілою причина, чому дана методологія “не працює у нас” або “не має нічого корисного окрім купи зустрічей”.
Для чого я все це розповідаю і що має спільного Scrum? Так, user story не обов’язково пов’язані виключно з ним і можуть використовуватися в будь-якій гнучкій методології. Але найкраще, на мою думку, вони розкривають свій потенціал саме тут. Також я використовую Scrum як дуже зручну алегорію до user story і до того, як обидва цих інструменти нерозуміло використовуються і часто бездумно, що завдає більше шкоди, ніж користі.
Тож, що ж таке user story? Простими словами, це методика опису вимог через опис користувацької поведінки. І так, це та сама BDD (behaviour driven development), про яку багато з вас, я впевнений, чули. Суть цього підходу полягає в тому, що ви описуєте функціонал через те, як його буде використовувати кінцевий користувач. Часто для опису використовують певний шаблон, за яким звичайно описують історію, наприклад, Gherkin з його ключовими словами Given, When, Then. Типова історія в такому випадку виглядає приблизно так:
Given I have an account in my system. When I open login page And enter my credentials And press submit button Then I should be navigated to Dashboard page.
Подібний формат запису добре відомий бізнес-аналітикам і, хоч це звучить дивно, автоматизованим тестувальникам. І, якщо перші зрозуміло, оскільки вони працюють з користувачами, метриками і складають вимоги, то другі тут виглядають непроханими гостями. Але, думаю, деякі з вас вже розуміють, звідки у AQA беруться ці знання — все реча в Cucumber framework. Він саме побудований навколо концепції BDD і використовує User story як тестову документацію і самі тести. Ідея об’єднати три сутності (user story, test case & test) в одну здається чудовою, і я з цим повністю згоден. Але, як завжди, в наше життя проривається сувора реальність.
Я зустрічав багато тестувальників, які пишуть свої тести з використанням Cucumber і Gherkin, і всі, без винятку, розповідають мені про переваги того, що ці тести є документацією до проекту і тестами одночасно. Але якщо я запитую, хто дивиться на їхні тести, окрім них самих, то в кращому випадку я отримую відповідь “Іноді розробники дивляться, якщо щось зламалося”. Це ще одна демонстрація того, як може спотворюватись початкова задумка user story, коли використовуються її артефакти або методики без чіткого розуміння їхньої призначеності або коли вони використовуються просто через моду, а не для вирішення конкретної задачі.
Або, можливо, вам знайома ситуація, коли фактично використовуються user story для опису завдання, але це робиться post factum, коли завдання вже було поставлено і визначені певні вимоги, а сама історія записується лише тому, що це “потрібно”, оскільки без неї картка в Jira не пройде далі?
Все це приклади неправильного формалізму, коли ми використовуємо інструмент лише тому, що так “повинно бути”, і не розуміємо, як його використовувати і для чого. Тому, коли нам дають пневмомолоток, ми не підключаємо його і забиваємо цвях, а просто стукаємо корпусом і не розуміємо, навіщо всі ці складнощі.
Тож звідки ж з’явилися ці user story і яку проблему вони призначені вирішувати? І все досить просто — це насправді на початкових етапах були історії від користувачів, які писали до підтримки і висловлювали свої бажання щодо наявності певного функціоналу. Їм писали щось на зразок: “Я, бухгалтер компанії, хочу, заходячи на сторінку звітів, мати можливість фільтрувати дані за звітними періодами”. Ці історії потрапляли до розробницької команди в чистому вигляді, без будь-яких змін, де вони могли оцінити їх складність і розбити на менші завдання (отож звідси походять такі поняття, як grooming і story points).
Отже, завдання надходило від самого клієнта у тому вигляді, в якому він його описав, після чого BA міг оцінити його важливість і передати команді розробки для реалізації. На етапі грумінгу команда попередньо оцінювала складність завдання. Зазначу, що це вони робили не у годинах, а саме в балах, по суті, говорячи, наскільки складно реалізувати дану бажану функціональність. Коли ж ця історія потрапляла на етап планування, вже дробили її на менші технічні завдання й починали реалізацію.
І все в описаному підході звучить логічно й відбувається достатньо гармонійно, оскільки слугує конкретній меті, а не існує лише тому, що так прийнято. Спочатку була бажання користувача, при чому він дійсно знає, для чого йому потрібна ця функціональність, якщо він витратив свій час на її опис. Потім йде етап відбору таких завдань за пріоритетністю й важливістю для бізнесу. Після цього розробники оцінюють цю історію, а коли вона потрапляє на планування спринту, до неї додаються технічні завдання, розподілені між конкретними розробниками. І в цьому робочому процесі вже досить складно зробити щось неправильно. Наприклад, почати оцінювати історії у годинах, оскільки це просто безглуздя, оскільки історія представляє собою великий функціонал з багатьма невідомими, а спринт планується на основі завантаженості розробників (в спринт ви будете брати саме історії, й вже після цього будете дробити на менші завдання).
Підсумовуючи написане вище, хочу сказати лише одне: якщо ви відчуваєте, що здійснюєте якусь церемонію Scrum без повного розуміння, для чого вона потрібна і яку проблему вирішує, варто зупинитися і задуматися. Не варто писати user stories лише з метою того, щоб вони були, адже це так прийнято. Якщо у вас немає такого щільного зворотного зв’язку від користувачів системи, то, принаймні, спробуйте разом із замовником формувати опис функціоналу через цей підхід. Ключовим метрикою повинен стати вплив цього функціоналу на кінцевого користувача після його впровадження в продакшн.
