User Story: що це і навіщо застосовується, критерії, приклади – як формулювати і писати власні історії | Розділ 12

Георгій Бірюков Дизайн-інженер "Meta-Chrom". Спеціалізується на дизайні інтерфейсів промислових пристроїв. Досліджує актуальні практики розробки та організації процесів створення інтерактивних систем (UX/UI). Лис 26, 2023 · 3 хв читати

Історії користувача (user story) - Це одиниця важлива для розробки, за допомогою неї описується функціональність продукту з позиції користувача. На відміну від технічного підходу до опису функціональності, історія користувача (user story) фокусується бажаннях користувача, пов'язаних з даною функціональністю. Більшість команд розробників вже спираються на техзавдання, відмовлятися від нього і не потрібно. Просто до ТЗ важливо додати власні історії та точку зору користувачів (point of view).

У чому цінність історій користувача

Користувальницькі історії - основа створення продукту для людей (user-centric), а також вони допомагають інженерам викладатися і шукати найкращі варіанти реалізації. Користувальницькі відображають точку зору користувача (user's point of view) і є короткими та ємними описами, життєвими та легкими по сприйняттю.

Користувацька історія у такому форматі допомагає команді зрозуміти, що (1)саме створюється, (2)навіщо і (3)у чому полягає цінність для кінцевого користувача (end user).

Як створити користувальницьку історію

Історії пишуть продакт-менеджери (product manager) чи власники продукту (product owner) у максимально простому форматі, об'ємом у пару пропозицій. Якщо історія виходить надто насичена нюансами, то її варто розділити на кілька простих історій.Деталі історії користувача додаються після обговорення з командою: продакт-менеджер і команда розвитку продукту (development team). Функції поділяють кілька дрібніших історій, які реалізуються в стислі терміни. Крім того, під час обговорення мають бути визначені умови задоволення вимог чи критерії приймання — це список умов, які потрібно виконати для того, щоб власна історія вважалася реалізованою.

Шаблон користувальницької історії

Як [користувача в такій ситуації], Я хочу [досягти такої мети], у зв'язку з [такоюсь причиною]. Як [type of user], I want to [accomplish some goal] so that [reason].

Як менеджер проекту у digital-агентстві, я хочу відсортувати завдання так, щоб було зрозуміло, що робити в першу чергу.

Приклади історій користувача

• Як менеджер проекту у digital-агентстві я хочу розподілити завдання по термінах
• Як менеджер проекту в digital-агентстві я хочу розподілити завдання відповідальним
• Як менеджер проекту у digital-агентстві я хочу розподілити завдання з пріоритету

Додавання історій користувача в Infinity Roadmap

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

• Крок 1: Відкрийте папку Roadmap
• Крок 2: Відкрийте кліком елемент, до якого ви хочете додати історію
• Крок 3: У розділі User Stories додайте одну або більше історій користувача, присвячених цій функції
• Крок 4: Після закриття власної історії ви можете помітити це в чекліста
• Крок 5: Додайте нову історію після того, як вона з'явиться

Можна скористатися шаблоном User Stories, він допоможе швидше створити власну історію. Це буде зручно тим, хто не використовує Infinity і хоче надихнутись через цей шаблон і тим, хто користується Infinity та хоче прискорити процес.

Користувальницькі історії з прикладами та шаблоном

Історії користувача - це завдання на розробку, які часто виражені у формі «тип користувача + потреба + мета».

Перегляд тем

Короткий опис: історія користувача - це опис функціональної можливості ПЗ простими, загальними словами, складений з точки зору кінцевого користувача. Вона пишеться для роз'яснення, як саме функціональна можливість принесе користь клієнту.

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

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

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

Що таке власні історії в agile?

Користувацька історія - це найменша одиниця роботи в методиці agile. Це кінцева мета, а чи не можливість, сформульована з погляду користувача ПЗ.

Користувацька історія - це опис функціональної можливості ПЗ простими, загальними словами, складений з точки зору кінцевого користувача або клієнта.

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

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

Історії користувача витончено вписуються в методики Agile, такі як Scrum і Kanban. У Scrum користувальницькі історії додають спринти і відстежують на діаграмах Burndown протягом спринту. Команди, що працюють за методикою Kanban, додають власні історії в беклог і пропускають їх через робочий процес. Саме так Scrum-команди вдосконалюють навички оцінки та планування спринту, підвищуючи точність прогнозів та свою гнучкість. За допомогою історій команди Kanban починають професійніше розпоряджатися незавершеною роботою (WIP) і можуть надалі удосконалювати робочі процеси.

Користувальницькі історії також становлять значні елементи методик Agile, такі як епіки та ініціативи. Епіки – це великі робочі завдання, які поділяються на кілька історій. Група епіків утворює ініціативу. Завдяки цим великим структурам щоденні зусилля команди розробників (в роботі над історіями) ведуть до досягнення цілей організації, що виражаються в епіках та ініціативах.

Навіщо потрібні користувальницькі історії?

Для команд розробників, яким agile у новинку, користувальницькі історії здаються зайвим кроком. Чому б просто не розбити великий проект (епік) на кілька кроків, а потім розбиратися з ними? Але з історіями команда отримує необхідний контекст та зв'язок між завданнями та цінністю, що виникає в результаті виконання цих завдань.

Користувальницькі історії мають кілька важливих переваг.

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

Робота з користувачами історіями

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

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

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

Як написати користувальницьку історію

При написанні історій користувача тримайте в розумі наступне.

• Критерії готовності роботи. Як правило, історія вважається "виконаною", коли користувач може зробити те, що було запрошено. Проте чітко сформулюйте мету.
  
• Короткий опис завдань та підзавдань. Визначте, які саме етапи необхідно пройти і хто відповідає за кожен із них.
  
• Типи клієнтів. Для кого? За наявності кількох типів кінцевих користувачів, бажано написати кілька історій.
  
• Етапи як частина ланцюга. Напишіть історію для кожного етапу, що становить більш масштабний процес.
  
• Зворотній зв'язок. Підтримуйте зв'язок із користувачами, щоб побачити проблему чи потребу їх очима.Навіщо гадати, якщо можна почути історію із вуст самих клієнтів?
  
• Час. Час – дуже делікатна тема. Багато команд розробників бояться порушувати питання часу зовсім, покладаючись свої оцінки. Історії повинні виконуватися за один спринт, тому історії, які можуть займати тижні або місяці, слід розбивати на кілька менших історій. Як варіант, вважайте їх за самостійні епіки.
  

Сформулювавши власні історії, подбайте про те, щоб вони були доступні всій команді.

Шаблон і приклади історій користувача

Користувальницькі історії часто представлені у вигляді простої пропозиції наступного виду:

«Як [тип клієнта], [хочу щось], [щоб робити щось]».

Давайте розберемо це формулювання.

• Як [тип клієнта]: для кого ми виконуємо цю роботу? Нам не така важлива посада, скільки особистість, що стоїть за типом клієнта. Ось Макс, наприклад. Нашій команді потрібно мати єдине уявлення, що Макс за людина. На щастя, ми опитали багато Максів. Ми розуміємо, як працює ця людина, як вона думає і що вона відчуває. Ми відчуваємо до Макса емпатію.
• «Хочу те»: у цій частині полягає намір користувача — не можливостей, якими він користується. Чого користувач хоче досягти? У цьому твердженні повинно бути жодного слова про способи реалізації. Якщо ви описуєте якусь деталь інтерфейсу користувача, ігноруючи мету користувача, ви втрачаєте суть.
• "Щоб робити щось": яке місце відведене цьому миттєвому бажанню клієнта в ширшому масштабі? Яку користь загалом хоче отримати клієнт? Яку велику проблему потрібно вирішити?

Історії користувача можуть виглядати, наприклад, таким чином.

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

Дотримуватись такої структури необов'язково, але вона допомагає визначити критерії готовності роботи. Історія виконана, коли згаданий тип клієнта отримує потрібну цінність. В ідеалі команди формулюють свою власну структуру і дотримуються її.

Початок роботи з історіями користувача в agile

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

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

Пов'язані ресурси

• Ресурси з управління проектами
  • Ресурси щодо планування проекту
  • Ресурси із запуску продукту
  • Стратегії з управління проектами для виходу на ринок
  • Ресурси з управління ресурсами
  • Ресурси щодо відстеження завдань
  • Ресурси з управління маркетинговими проектами
  • Ресурси з управління програмами
  • Ресурси для керівників проектів
  • Управління проектами з розробки програмного забезпечення

  User Story: хто пише власні історії і навіщо це треба

  User Story — один із ключових інструментів у проектній та продуктовій розробці. З їхньою допомогою можна визначити, чого насправді хоче користувач, і зробити справді класний продукт. Спільно з експертом Ейч Ларисою Дансаруновою розбираємо, як писати власні історії та яких помилок слід уникати.

  освойте професію
  UX/UI-дизайнер з нуля
  за 9 тижнів

  1. Що таке User Story
  2. Навіщо потрібні User Story
  3. Характеристики User Story
  4. Як писати User Story
  5. Помилки в історіях користувача
  6. Інструменти для роботи з User Story
  7. Поради щодо покращення User Story
  8. Приклади історій користувача
  9. Головне про User Story

  Що таке User Story

  Історія користувача — це спосіб написання вимог до продукту, який використовують у розробці ПЗ.

  Зазвичай User Story складається із трьох частин:

  • роль (хто): Користувач продукту;
  • мета (що): дію, яку хоче зробити користувач;
  • результат (навіщо): що він хоче отримати у результаті.

  Наприклад: «Як [клієнт салону краси], я хочу [мати можливість записатися на стрижку через мобільний додаток], щоб [мені не довелося дзвонити]».
  У межах одного продукту можна написати багато різних user story. А якщо сервіс має різні користувачі, то потрібно прописати історії окремо для кожного.

  Лариса Дансарунова, експерт Ейч, наставник Яндекс Практикума, автор Telegram-каналу @ithumanwork:

  «Раніше для постановки завдання в команді розробки використовувалися формальніші та суворіші способи, наприклад ЧТ, ЧТЗ, SRS, BRD. User Story прийшли як один із способів залишатися AGILE та підтримувати безперервну розробку.І насамперед почали використовуватися в рамках продуктового підходу. Це короткі історії, які допомагають швидко реагувати на зміни та вносити виправлення до продукту».

  Для тих, хто хоче потрапити до ІТ без навичок кодингу, але з реальним досвідом

  Навіщо потрібні User Story

  User Story використовують у роботі бізнес-аналітики, продакт-оунери та проджект-менеджери. Вони допомагають:

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

  User Story - це частина UX, з його допомогою можна покращити користувальницький досвід. Історії допомагають визначити функціональну частину продукту, але не слід плутати їх із User Flow.

  Лариса Дансарунова, експерт Ейч, наставник Яндекс Практикума, автор Telegram-каналу @ithumanwork:

  «User Story кратно підвищує швидкість роботи команди. Можна написати коротку користувальницьку історію замість довгого ТЗ на десять сторінок. При цьому User Story міститиме всі важливі вимоги, які необхідно врахувати у процесі розробки.

  Ще цінність історій користувача в тому, що вони зрозумілі і досить однозначні. Це важливо для команди, де представлено багато різних ролей: розробники, дизайнери, випробувачі, аналітики тощо. д.»

  UI-тестування: що це та як його провести

  Характеристики User Story

  Правильна User Story відповідає критеріям INVEST:

  • Independent (незалежна): може бути реалізована у будь-якому порядку. Погано, якщо завдання А не може бути запущене в роботу без завдання Б. У цьому випадку їх потрібно об'єднати в одну велику незалежну історію.
  • Negotiable (обговорювана): відображає суть запиту, а чи не дає конкретну інструкцію, як виконати завдання. Команда повинна мати змогу обговорити деталі.
  • Valuable (цінна): несе користь клієнтам, бізнесу та стейкхолдерам. Якщо в історії історії немає цінності, то немає сенсу її виконувати;
  • Estimable (оцінюється): за формулюванням історії можна оцінити обсяг роботи. Якщо не виходить, то швидше за все в ній є помилки.
  • Small (компактна): її можна швидко продати. Деякі команди встановлюють тимчасові рамки, яку максимальну кількість часу можна витратити на один користувач сторі.
  • Testable (тестована): її можна перевірити практично.

  Лариса Дансарунова, експерт Ейч, наставник Яндекс Практикума, автор Telegram-каналу @ithumanwork:

  «При складанні користувальницької історії можна орієнтуватися на критерії INVEST. Однак на практиці деякі історії складно підвести під будь-які критерії.

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

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

  INVEST-критерії хорошого User Story. Джерело

  Як писати User Story

  Щоб створити користувач сторі:

  • Визначте роль користувача: це людина, яка використовуватиме конкретну функцію продукту.Наприклад, додатком для обліку фінансів можуть користуватися як звичайні користувачі, так і підприємці.
  • Напишіть ціль: що конкретно хоче зробити юзер. Це може бути завдання, яке йому потрібно вирішити, або інформація, до якої необхідно отримати доступ. Наприклад: "Завантажити звіт про покупки" або "переглянути свої витрати за місяць за категоріями".
  • Визначте результат: навіщо йому треба зробити це, у чому кінцевий мотив. Наприклад, підприємець хоче подивитися витрати за місяць за категоріями, щоб зрозуміти, скільки грошей йде на зарплати працівників.

  Лариса Дансарунова, експерт Ейч, наставник Яндекс Практикума, автор Telegram-каналу @ithumanwork:

  «В основі історій користувача часто лежать дослідження. Багато компаній мають як мінімум дві команди — discovery і delivery. Discovery вивчає, що потрібно цільової аудиторії, а delivery розробляє та доставляє функцію до користувача.

  Ще на користувальницькі історії можуть впливати нові закони, вимоги від продакт-менеджера та стейкхолдерів. Перед тим, як почати формулювати саму історію, важливо зрозуміти, чи можемо ми взагалі це реалізувати технічно. Для цього необхідно проконсультуватися із розробниками».

  Робіть світ зручніше. Створюйте продумані інтерфейси сайтів та програм без навичок програмування. IT-компанії чекають на вас.

  Помилки в історіях користувача

  При написанні користувачеві важливо уникати поширених помилок.

  • Неправильне формулювання«чому»: третина User Story повинна відбивати цінність клієнта, щоб розробники точно розуміли, як потрібно реалізувати функцію.

  Неправильно	Правильно
  "Я як користувач хочу мати можливість додати товар до обраного, щоб не забути його купити".	"Я як користувач хочу мати можливість додати товар до обраного, щоб повертатися до нього, не переходячи в каталог". «Я як користувач хочу отримувати нагадування про товар, що сподобався, щоб не забути його купити».

  • Невідповідність INVEST-критеріям: наприклад, занадто або недостатньо докладна користувальницька історія.

  Неправильно	Правильно
  «Я як Петя хочу авторизуватися в додатку через свою пошту [email protected], щоб мати доступ до особистого кабінету». "Я як користувач хочу мати можливість авторизуватися, щоб мати доступ до особистого кабінету".	"Я як користувач хочу мати можливість авторизуватися за номером телефону в мобільному додатку, щоб мати доступ до особистого кабінету"

  Інструменти для роботи з User Story

  Перші User Story з'явилися в екстремальному програмуванні і записувалися на «картках користувача». По суті це були звичайні стікери. Кожен учасник команди міг узяти листок та записати свою ідею. Потім ці картки групували на спільній дошці — вони завжди були на очах і допомагали у розробці продукту.

  Сьогодні все те саме можна робити онлайн. Для цього використовують:

  • сервіси для управління проектами:Jira, Trello;
  • віртуальні дошки:FigJam, Pruffme, Unidraw та ін.

  Лариса Дансарунова, експерт Ейч, наставник Яндекс Практикума, автор Telegram-каналу @ithumanwork:

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

  Ще іноді використовують дошку Miro чи її аналоги. Це теж інструмент із досить простим інтерфейсом. Там можна скласти карту історій користувача, а потім внести її в Jira».

  Поради щодо покращення User Story

  Щоб ваші User Story завжди були точними та актуальними:

  Це карта історій користувача. З її допомогою можна впорядкувати всі користувачі сторі і відзначити ті, що у команди в пріоритеті.

  Лариса Дансарунова, експерт Ейч, наставник Яндекс Практикума, автор Telegram-каналу @ithumanwork:

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

  Наприклад, ми випускаємо програму з фітнесу, де є уроки, статті та особистий кабінет користувача. Особистий кабінет — це користувальницька історія про зберігання персональних даних, вона буде в пріоритеті і увійде до складу MPV. Інші функції, наприклад, можливість ділитися статтями, можна додати пізніше».

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

  Лариса Дансарунова, експерт Ейч, наставник Яндекс Практикума, автор Telegram-каналу @ithumanwork:

  «Критерії приймання дозволяють перевірити, чи правильно працює User Story. Наприклад, наша користувальницька історія звучить так: "Я як користувач хочу мати можливість авторизуватися за допомогою свого телефонного номера, щоб подивитися уроки в додатку". Тоді найпростіший критерій приймання – можливість ввести номер телефону та пройти авторизацію.

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

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

  Лариса Дансарунова, експерт Ейч, наставник Яндекс Практикума, автор Telegram-каналу @ithumanwork:

  «Будь-яка команда зазвичай переглядає беклог IT-продукту, тому що під час роботи приходить багато різних ідей – нові завдання від стейкхолдерів, ініціативи від самих користувачів, які вони написали через техпідтримку. Все це вноситься в беклог у вигляді напрацювань, і команда переглядає його раз на квартал або спринт. Це називається грумінг чи ревью, його мета – видалити неактуальні пропозиції та взяти в роботу нові ідеї.».

  Приклади історій користувача

  User Story завжди залежить від конкретного продукту. Наприклад, у сфері B2B часто можна виділити конкретного користувача:

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

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

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

  Відмінна риса мобільних додатків у тому, що вони надають користувачеві швидкий доступ із будь-якої точки. Це також буде відображено в User Story:

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

  Головне про User Story

  User Story – це зручний інструмент, за допомогою якого команда може швидко зрозуміти потреби користувачів.

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

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

  професія UX/UI-дизайнер з нуля до про

  Створюйте продумані інтерфейси сайтів та програм без навичок програмування. Зануримо в дизайн-середовище з першого модуля і дамо досвід, який реально стане в нагоді в роботі