Стаття буде корисна Junior-фахівцям, які так чи інакше працюють з документацією на проекті. У статті розглядаються як самі історії користувача, так і критерії, за якими можна написати хорошу історію. Зі статті читач зможе почерпнути і як писати історії, і як правильно доповнити їх деталями, і які деталі важливі, і як не перевантажити історію.
Вступна інформація про User Stories
Що таке User Stories
Зараз User Stories є одним з головних прийомів роботи бізнес-аналітиків і Product Owner. Бізнес-стейкхолдери розповідають ці історії, щоб показати команді розробки суть і цінність завдання, яку треба реалізувати. Вони короткі, написані діловою мовою і тому зрозумілі всім зацікавленим особам проекту.
Дати містке визначення цього прийому складно. Його зовнішня простота змушує зводити його опис до зовнішніх характеристик. Тому я, як автор, хотів би дати читачеві кілька визначень.
В якості першої відповіді наведемо «офіційне» визначення з книги М. Кона “Користувацькі історії: гнучка методологія розробки ПО”.
Історії користувача – це короткий опис функціональності, деталі якої повинні уточнюватися в ході усних обговорень між зацікавленими особами проекту.
Таке визначення не допомагає розібратися в суті прийому і його поширеності серед користувачів. Невже головне – це записи або те, що деталі повинні уточнюватися? Думаю ні. Тому я не кинув копання і почав дивитися інші джерела. Безліч сайтів пропонує таке визначення:
User Story – це короткий запис суті завдання в форматі “As a … I want to … so that I can …”.
Ця відповідь теж не задовольнила мою цікавість. Таке визначення ставить на чільне місце формат. Адже User Story може існувати і без якоїсь частини (As a user, I want to save data) і бути написаною без обговорення інтровертним продакт-овнером. Але найголовніше – про це буде нижче – User Story може бути написана за зовсім іншим форматом!
Пройшовши коло обговорень з ментором, прочитавши і подивившись багато статей і відео, я зрозумів, що головне в історії користувача – це цінність, яку користувач отримає від функції. Тому я спробував згенерувати визначення:
User Story – це прийом запису вимог, який допомагає команді розробки зрозуміти потребу клієнта і після обговорення вибрати, описати і затвердити те рішення, яке задовольнить цю потребу.
Щоб зрозуміти, чим є сама потреба, давайте розглянемо наступний приклад. Людина хоче їсти. Так, ми можемо нагодувати людину рибою. І тоді він буде ситий цілий день. Але в цьому справжня потреба цієї людини? Навряд чи, адже завтра людина зголодніє. Уважний читач уже здогадався, що головна потреба людини – інструмент, яким можна добути їжу (наприклад, вудка).
Дуже важливо відзначити, що історія і її цінність може бути спрямована не тільки на якусь групу користувачів. Вона може бути спрямована на команду розробки (оновити компонент, додати компонент, переробити код …), Product Owner або представників бізнесу.
Далі в статті я використовую однорядкові приклади історій користувача: “Як Х, я хочу Y, щоб Z”. Проте, багато аналітиків використовують інший підхід, який вважається навіть більш канонічним.
Так, історії пишуться в три рядки:
Як Х,
Я хочу Y,
Щоб Z.
Job Stories
В цілому Job Stories – схожа з US техніка. Можна назвати їх прийомом-субститутом, адже зазвичай вони не використовуються разом і виконують максимально схожу функцію. Job Stories представляють вимоги у вигляді дії, яку виконує користувач. Вони не описують саму функцію, а лише концентрують увагу команди на потреби.
Job Stories концентруються на психологічній частини фічі, на емоціях, тривогах та інше, що може виникнути під час використання функції.
«Тіло» JS ділиться на три частини:
- Situation: дає контекст про всю JS, який допомагає dev-команді придумати можливе рішення.
- Motivation: описує невидиму руку, яка веде юзера до використання даної функції.
- Expected Outcome: описує, що отримає користувач після використання функції.
Job Stories можуть писатися по двом форматам:
В один рядок:
When X I want to Y so I can Z “або” When X, actor is Y so that Z.
У три рядки:
When X
I want to Y
So I can Z.
Приклад:
When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so that I can go out to dinner with my friends.
Питання, які слід задавати під час написання сторі
Під час написання історії для аналітика важливий не тільки її текст, а й той зміст – цінність, проблема – яка описується цим текстом. Щоб написати історію, яка зможе вирішити проблему користувача, аналітику треба краще зрозуміти користувача і задати собі наступні питання.
- Чи вирішує це справжню проблему юзера?
- Чи є у такого рішення будь-які side effects? Чи впливає це на продукт в цілому?
- Які наслідки від такого рішення?
Запитання можна поставити і стейкхолдерам. Наприклад, перше питання має сенс адресувати Product Owner в команді якого ви працюєте. А другий і третій – самій команді розробки, вони напевно зможуть вказати на якісь підводні камені.
А при роботі з іншими стейкхолдерами і з’ясуванні причин потреби у них аналітик може використовувати знаменитий прийом «5 чому?».
Три С в User Story
Перше визначення говорить про комунікації і картки, але не згадує згоду. Ці три поняття утворюють “the 3 C’s of User Stories”.
- Card – за задумом автора методу історії пишуться на фізичних картках. У реальності вони пишуться в Jira та Confluence, тому ми не так обмежені в детальності.
- Conversation – кожна сторі – це безліч мітингів навколо неї, які і спрямовані на розуміння деталей.
- Confirmation – перед початком роботи клієнт дає згоду на таке рішення, а команда повністю впевнена в здійсненності рішення.
User Personas
Цей метод являє собою детальний опис користувача продукту. Опис користувача повинен бути конкретним і детальним, адже за його описом члени команди повинні зрозуміти, що це цільова аудиторія програми, з якою вони роблять.
Створюючи чіткого і детального персонажа, аналітик вимог або Product Owner зменшує ймовірність того, що потреби користувача будуть забуті або замінені на потреби тих членів проектної команди, які ставлять себе на місце користувачів.
Картка персонажа не зобов’язана бути повністю правильної, але вона повинна містити максимальну кількість деталей.
Найбільш важливими деталями персонажа є його ім’я, місце роботи (роль в системі), місце проживання. Причому ім’я і роль в майбутньому можуть використовуватися і при написанні історій:
Як Георгій, я хочу друкувати документи, щоб я міг працювати над ними поза комп’ютером.
Варто також відобразити маркетингові характеристики персонажа такі як бажані бренди, страви, захоплення та хобі. Ці характеристики важливі не тільки, щоб знати для кого ми створюємо ПО, але і як його рекламувати і продавати. Опис повинен також розкривати і характер персонажа. Він веселий або частіше хмуриться? Він ділиться інформацією в соцмережах або зовсім не веде їх?
В описі слід відобразити і завдання, які найбільш важливі для персонажа в його роботі з системою. Це допоможе всій команді побачити потреби персонажа і допоможе створити стимул для покупки преміум-версії або підписки.
Не варто забувати і про ще одну важливу деталь. Персонажі не можуть «гуляти» з продукту в продукт, але людина, яка створює їх опис, може звертатися до давно створених образів як за натхненням, так і за шаблоном опису.
Створивши одного персонажа, можна відпочити і насолодитися виконаною роботою. Однак не варто зупинятися, тому, що саме набір персонажів (від 3 до 10) допоможе в майбутньому вибудувати систему, яка допоможе пріоритезувати історії, завдяки розумінню того, що потрібно тому чи іншому персонажу. А якщо щось потрібно двом з трьох персонажів, то слід кинути всі сили на цю функцію.
Що ж в сухій практиці використання User Personas?
На практиці автор статті переконався, що команді не важливі багато речей з опису Persona: бренди, біографія, боязні … Я думаю, що найбільш актуальна інформація, яку слід було б помістити в опис Persona – це роль в системі, цілі від її використання, а також основні кейси.
Негативний персонаж
Не всі персонажі повинні створюватися, щоб показати користувачів системи. Завдання деяких вказати, кому в додатку немає місця.
Наприклад:
Створюючи будь-який додаток для таксі, ми згадаємо, що в процесі замовлення традиційно є 3 учасники: клієнт, водій, оператор. Швидше за все, завданням нашого додатку буде автоматизація роботи оператора так, щоб клієнт міг зв’язатися з водієм безпосередньо. В такому випадку самому оператору в системі не буде місця.
Ключовий персонаж
Ключовими персонажами є ті, для кого і буде проводитися проектування рішення. Такий персонаж уособлює групу користувачів, яка буде або найчастіше користуватися додатком, або має якісь особливості, через які їм слід користуватися додатком інакше. Такі персонажі заслуговують окремих інтерфейсів в системі.
Наприклад:
Давайте повернемося до додатка для саппорту. У ньому обидва персонажі, які все-таки будуть користуватися системою, будуть ключовими. Так, тому, хто буде усувати скарги, потрібен інтерфейс, який показує скарги і допомагає вибудувати маршрут. У той же час клієнту, швидше за все, потрібно подивитися всі його скарги і залишити нову.
INVEST
За критеріями INVEST ми можемо судити, чи добре написана User Story і чи можна над нею працювати.
I – Independent – Незалежний
Слід уникати залежності між історіями, через те, що іноді це призводить до проблем під час імплементації. (Приклад: завдання А не може бути реалізоване без завдання Б, однак завдання А – дуже важливе, а Б лише бажано мати в готовому продукті).
На практиці це прагнення не завжди можна досягти. Наприклад, в разі залежності декількох історій одна від одної, слід шукати інший спосіб розбити їх.
Наприклад:
Ми хочемо додати в наш продукт підтримку банківських карт MasterCard, Visa і третьої системи. Тоді найпростіше розділити цю сторі на три. У першій, найбільшій, розробник повинен додати підтримку банківських карт в цілому і якусь зі списку. А інші дві можуть піти в іншу сторі, яка залежить від першої.
N – Negotiable – Обговорюваний
Після написання чернетки історії слід обговорити її зі стейкхолдерами і, можливо, внести зміни, виправити помилки. В ході обговорення команда ще не говорить про те, як дана історія буде реалізована, а обговорюється лише те, як буде задовольнятися потреба користувача.
V – Valuable – Цінний
Кожна User Story повинна нести користь як користувачу, так і продукту, а опис має створюватися так, щоб цінність була найбільш очевидна. Так команда розробки буде розуміти, навіщо це потрібно реалізовувати.
Якщо цінність історій, які несуть новий функціонал або покращують старий, очевидна, то з тими, які зав’язані на технічній стороні продукту, не все так очевидно. Але й історії, в рамках якої команда позбавляється від легасі-коду, робить рефакторинг або переносить старий функціонал на нову інфраструктуру (наприклад, в нову базу даних) несуть цінність як для продукту, так і для користувача. Швидше за все, користувач відчує їх завдяки поліпшенню чутливості або швидкості роботи системи. Це слід відобразити в описі такого завдання.
E – Estimable – Оцінюваний
Історія повинна бути настільки ясно написана, щоб у розробника було достатньо розуміння, адже без нього він не зможе видати оцінку, близьку до правди. Є три причини, чому dev не може видати оцінку:
- історія занадто велика;
- в описі недостатньо даних;
- розробнику потрібно більше досвіду.
Однак докладніше про оцінки поговоримо в відділі “Оцінка історій”.
S – Small – Компактний
Цей пункт говорить не про сам опис під історією, а про її розмір, час на реалізацію. На багатьох проектах команди встановлюють рамки, в які повинна вміститися історія. Так, часто можна почути про правило, згідно з яким історія повинна укладатися в робочий день. Однак на інших же історією користувача може вважатися функція, на реалізацію якої потрібно кілька місяців часу розробника.
T – Testable – тестуємий
Суть цього пункту не тільки в тому, що команда тестувальників повинна розуміти, що перевіряти, а й в тому, що історія користувача повинна володіти чимось, що можна подивитися, запустити.
Однак не варто забувати, що варто писати історії так, щоб QA-команда могла зрозуміти, які кейси та сценарії їй тестувати. Для створення цього розуміння аналітику вимог слід користуватися критеріями приймання та описом сценаріїв по Gherkin. Детальніше про ці прийоми можна прочитати в розділі “Як додати деталей до історії”.
Як додати деталей до історії?
Дуже важливо розуміти, що коли робота над “тілом” сторі закінчена, починається робота над деталями, які і допоможуть команді зрозуміти, що треба реалізувати. Серед способів додати деталі самими знаменитими є Acceptance Criteria і сценарії по Gherkin.
Acceptance Criteria
Що таке АС
Елемент User Stories, який доповнює їх так, що команда починає бачити історію в деталях. Цей інструмент допомагає зрозуміти, що має бути зроблено, щоб задовольнити потребу бізнесу.
АС допомагають побачити фічу з точки зору кінцевого користувача, встановити межі фічі і створити розуміння того, що повинно бути зроблено і що буде перевірятися.
Їх треба розуміти максимально буквально, тому що це ті критерії за якими ми розуміємо, виконана історія чи ні.
Для чого потрібні
- Показують фічу з точки зору кінцевого користувача.
- Для розуміння завдань бізнесу.
- Досягнення консенсусу з бізнесом щодо якоїсь сторі.
- Служать базою для тестів.
- Допомагають оцінювати сторі.
Правила написання
- Ми пишемо їх не в формі should, а в теперішньому часі (суть в тому, що людина читає і бачить, якими “здібностями” володіє користувач або система).
- Повинні бути перевіряємі. -> pass / fail result прописаний чітко.
- Повинні бути вимірні.
- Пишуться ДО роботи над завданням.
- Включають функціональні і нефункціональні критерії.
- Містять приклади.
- Користувач може вибрати колір. Приклад: є дропдаун з кольорами.
- Не занадто вузькі (прив’язані до одного юз-кейсу-приміром) і не дуже широкі (зрозуміло де зроблено і як працює).
- Не містять технічного арго.
Що робити, коли треба вибрати одне з декількох рішень?
Тоді на допомогу приходить Evaluation Criteria. Використовуються, щоб оцінити цінність декількох рішень і вибрати потрібну.
Наприклад:
Компанія хоче пообідати в італійському веганські ресторані, де грає жива іспанська гітара. Тоді ресторан, який підійде, повинен відповідати трьома критеріями:
1. Ресторан повинен бути італійським.
2. Ресторан повинен подавати вегетаріанські страви.
3. У ресторані грає жива іспанська гітара.
Gherkin
Gherkin – це спосіб опису сценаріїв використання систем, який зрозумілий розробникам, тестувальникам, бізнесу. Він будується за суворим синтаксисом і тому дозволяє “обходити” багато вольності природної мови.
Ці сценарії використовуються найчастіше для опису критеріїв приймання і можуть стати відмінним помічником для автоматизації тестування. Їх великим мінусом є нечитабельність, адже сценарії являють собою довгі тексти, в той час як АС – це найчастіше 1-2 рядки тексту.
Наприклад:
Scenario: Dr Bill posts to his own blog.
GIVEN I am logged in as Dr Bill
WHEN I try to post to my blog
THEN I should see “Your article was published”
Базовий синтаксис Gherkin
- Given – це те ж саме, що Precondition в Use Case. Те, що повинно бути виконано перед початком сценарію.
- When – то, що пускає в хід систему; головна суть цього юзкейсу.
- Then – то, що має відбутися в кінці юзкейсу.
- And – для ускладнення сценарію разом з given, when, then. Вважається поганим тоном перевантажувати сценарій великою кількістю and-конструкцій, показує, що в ньому занадто багато деталей.
- But – використовується з Then і вказує на те, що не повинно трапитися як підсумок юзкейса.
- Feature – об’єднання безлічі сценаріїв в одну функцію. Включає Сторі, АС і сценарії цієї сторі.
- Background – встановлює precondition відразу для всіх сценаріїв, щоб не переписувати.
- Scenario Outline / Examples – використовуються разом, щоб скомбінувати кілька сценаріїв, де трапляються різні повідомлення.
Наприклад:
1) Пишеться сценарій-скелет.
Scenario Outline: Dr Bill posts to his own blog.
Given I Have published <number of blogs>
When I try to post a new blog
Then I should see <message>
2) Створюється таблиця з прикладами.
В даному прикладі ми повинні показати зв’язок між кількістю постів в блозі і тим, яке повідомлення побачить користувач. наприклад:
| Number of blogs | Message |
| >5 | Your article was published. |
| 5 or <5 | Please, pay for posting. |
- Tags – засіб для угруповання сценаріїв (в тегах можна вказувати тікети, особливості системи, групи користувачів і ін.)
- Steps – це Given, When, Then у вигляді нумерованих кроків.
Короткий відгук про використання Gherkin
Складно зробити однозначний висновок щодо корисності Gherkin. Я багато разів намагався почати постійно використовувати його на проекті. Gherkin відмінно підходить для опису складних сценаріїв з розгалуженням, варіантами. Проте, цей спосіб не викликав позитивні відгуки з боку (взагалі не викликав) команди розробки або тестування. Виходить так, що балом в “деталях” до історій правлять критерії приймання – саме на них команда дивиться найчастіше під час оцінки та вивчення завдань.
Хвороби поганих користувальницьких історій
Як не всі фломастери червоні, так і не всі призначені для користувача історії хороші. Існує кілька типових рис, які характерні поганим історіям. Давайте розглянемо найбільш поширені з них.
Занадто багато інформації про функціонал в “So that …”
“So that” – це частина про цінність історії, а не функції, які будуть в її рамках реалізовані.
Антиприклад.
Як відвідувач кафе, я хочу, щоб моє замовлення десь зберігалось, щоб я міг дивитися історію замовлень, роздрукувати чеки, відправити чеки по email.
Потенційна проблема з цією історією в тому, що команда бачить “замовлення десь зберігалось”, то на цьому і закінчує розгляд історії, естімацію, так як думає, що завдання-то і не дуже складна, але ж тут так багато функціоналу!
Приклад можливого рішення.
Як відвідувач кафе, я хочу дивитися історію замовлень, бачити чеки, друкувати чеки, щоб я міг змінювати чеки, порівнювати їх, відправляти нові замовлення в ресторан.
Ми розширили частину “I want …”, щоб кожна “хотілка” з третьої частини історії була співвіднесена з функцією з другої частини. Так команда точно побачить, що завдання не таке просте і там є над чим подумати. Але навіть така історія не стає хорошою, адже хто завгодно замучиться читати такий довгий “історичний роман”.
“Історичний роман
Історії повинні бути короткими. В ідеалі вони повинні поміщатися на канцелярський стікер, який повинен клеїтися на реальну дошку.
Антиприклад.
Як відвідувач кафе, я хочу дивитися історію замовлень, бачити чеки, друкувати чеки, щоб я міг переглядати їх, порівнювати їх, відправляти такі ж замовлення в ресторан.
Як вчинити з такою великою історією? Її слід розділити на кілька!
Приклад
Як відвідувач кафе, я хочу дивитися історію замовлень, щоб я міг зробити таке же замовлення в майбутньому.
Як відвідувач кафе, я хочу бачити чеки, щоб я міг їх порівнювати.
занадто конкретні
Історія – не місце для деталей. Переповненість історії негативно позначиться на декількох аспектах. По-перше, вона не залишає місця для творчості розробнику – він стає просто руками, які роблять, що сказали; по-друге, деталі перетворюють історію в історичний роман.
Антиприклад.
Як відвідувач ресторану, я хочу, щоб різні види продуктів були позначені різними кольорами (м’ясо – # FF0000, крупи – # A52AFA, овочі – # 808000), щоб я міг легко розрізняти їх.
Кращий спосіб поліпшити таку історію – прибрати конкретні приклади. Якщо в самих кольорах є якась важливість, їх можна помістити в критерії приймання.
Приклад
Як відвідувач ресторану, я хочу, щоб різні види продуктів були позначені різними кольорами, щоб я міг легко розрізняти їх.
1. Для м’яса використовується колір # FF0000.
2. Для круп використовується колір # A52AFA.
3. Для овочів використовується колір # 808000.
“Хочу робити, щоб робити”
Однією з поширених хвороб історій автор вважає історії “хочу Х щоб Х“.
Антиприклад.
Як людина, що гуляє в спеку, я хочу морозиво, щоб з’їсти морозиво.
Історія з прикладу не відображає цінність, тільки засіб її досягнення. Припускаю, що людина хоче морозиво, щоб палюче липневе сонце не довело його до сонячного удару.
Висновок
Історії користувача – це дуже корисний формат опису вимог. Він дозволяє команді розробки придумати саме те рішення, яке задовольнить потребу кінцевого користувача.
Але не варто забувати, що самі історії – це верхівка завдання. Дуже важливо акуратно доповнити історію прикладами і деталями, які будуть направляти команду під час імплементації рішення.
Джерела
- When Is a Story Done? Three Criteria to Decide, – Atomic Object. URL: https://medium.com/@atomicobject/when-is-a-story-done-three-criteria-to-decide-1979c7edd1fe
- What is Acceptance and Evaluation Criteria in the context of Business Analysis?, – Business Analysis Excellence. URL: https://business-analysis-excellence.com/acceptance-evaluation-criteria-context-business-analysis/#:~:text=In%20the%20case%20of%20a,’%20or%20’a%20fail
- Gherkin for Business Analysts, – Hewitt, Ryan. URL: https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/3810/Gherkin-for-Business-Analysts.aspx
- Agile Extension to BABOK, – IIBA.
- Business Analysis Body Of Knowledge, – IIBA.
- 10.1 Acceptance and Evaluation Criteria. URL: https://www.slideshare.net/maddyiscrazy/101-acceptance-and-evaluation-criteria
- 7 Tips for Writing Acceptance Criteria with Examples, – Prasad, Durga. URL: https://agileforgrowth.com/blog/acceptance-criteria-checklist/
- Identifying and Improving Bad User Stories, – Suscheck, Charles; Fuqua, Andrew. URL: https://www.agileconnection.com/article/identifying-and-improving-bad-user-stories
- Разработка требований к программному обеспечению, – Вигерс, Карл.
- Пользовательские истории гибкая разработка программного обеспечения, – Кон, М.
- Пользовательские истории. Искусство гибкой разработки ПО, – Паттон, Дж.
- Психбольница в руках пациентов, – Купер, А.
Переклад з оригіналу, розміщеного https://habr.com/ru/post/577420/
3 thoughts on “Гайд по User Stories для Junior BA”