Термін

Користувацька історія

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

Оновлено

Що це означає

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

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

Кожну історію доповнюють критерії приймання, що визначають, коли вимогу виконано. Наприклад, застосунок приймає фото у форматах JPG і PDF, показує підтвердження, а документ з'являється у списку на обробку. Критерії запобігають непорозумінням між замовником і розробниками.

Як це працює на практиці

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

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

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

На що звернути увагу

Користувацька історія - не договірна специфікація. За зовнішнього розроблення за фіксованою ціною обсяг і критерії приймання мають бути достатньо точними, інакше виникнуть спори про те, що було погоджено. Тому за гнучкої співпраці часто обирають модель time and material.

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

Потрібно пояснити термін на вашій конкретній ситуації? Консультації від 55 € / година без ПДВ, залежно від теми та складності.