В розробці програмного забезпечення та управлінні продуктом користувацька історія – це неформальне опис на природному мовою однієї або кількох функцій програмної системи. Приклади User Story часто пишуться з точки зору кінцевого користувача або користувача системи. Вони часто записуються на облікових картках, у нотатках Post-it або у програмному забезпеченні для керування проектами. В залежності від проекту користувальницькі історії можуть бути написані різними зацікавленими сторонами, включаючи клієнтів, менеджерів або членів команди розробників.
Пояснення
Користувальницькі історії – це тип прикордонного об’єкта. Вони сприяють виробленню сенсу і спілкування, тобто допомагають командам розробників систематизувати своє розуміння системи та її контексту.
Приклади User Story часто плутають з системними вимогами. Вимога – це формальний опис потреби; користувацька історія – це неформальне опис функції.
Створення
У 1998 році Алістер Кокберн відвідав проект Chrysler C3 в Детройті і придумав фразу «Історія користувача – це обіцянка для розмови».
З Extreme Programming (XP) користувальницькі історії стали частиною гри планування.
Вимоги
Як складати хороші User Story? У 2001 році Рон Джеффріс запропонував формулу «Три С» для створення користувацьких історій:
У деяких командах менеджер по продукту (або власник продукту в Scrum) несе основну відповідальність за формулювання користувальницьких історій та організацію їх в портфель продуктів. В інших командах будь-хто може написати історію користувача. Приклади User Story написані або для користувачів або клієнтів, щоб впливати на функціональність розроблюваної системи. Користувальницькі історії можуть бути розроблені шляхом обговорення з зацікавленими сторонами, на основі персон або просто складені. Так написано в офіційному керівництві How to do User Story mapping.
Методи
В якості центральної частини багатьох гнучкої розробки методологій, таких як гра в планування XP, власні історії визначають, що повинно бути вбудована в програмний проект. Користувальницькі історії розташовуються по пріоритетам клієнта (або власника продукту в Scrum), щоб вказати, які з них найбільш важливі для системи і будуть розбиті на завдання і оцінені розробниками. Один із способів оцінки – за шкалою Фібоначчі. Це буде воістину приклад хорошої “юзер сторі”!
Коли будуть реалізовані власні історії, розробники повинні мати можливість поговорити про це з замовником. Короткі історії можуть бути важко інтерпретувати, можуть зажадати деяких базових знань, або вимоги могли змінитися з моменту написання історії.
До кожної користувача історії в якийсь момент повинен бути прикріплений один або декілька приймальних тестів, що дозволяють розробнику перевірити, коли вона готова, а також дозволяють замовнику її перевірити. Без точного формулювання вимог можуть виникнути тривалі неконструктивні аргументи, коли продукт повинен бути доставлений.
Спірний статус
Немає переконливих доказів того, що використання користувальницьких історій збільшує успіх програмного забезпечення або продуктивність розробників. Тим не менш, власні історії полегшують пошук сенсу без надмірного структурування проблем, що пов’язано з успіхом.
Обмеження користувальницьких історій включають в себе:
Комунікативне значення
Користувальницькі історії розглядаються як початок розмови. Будучи неформальними, вони відкриті для багатьох тлумачень. Коротко, вони не містять всіх деталей, необхідних для реалізації функції. Тому історії не підходять для укладання офіційних угод чи написання юридичних контрактів.
Відсутність нефункціональних вимог
Користувальницькі історії рідко включають в себе відомості про продуктивність або функціональних вимогах, тому нефункціональні тести (наприклад, час відгуку) можуть бути пропущені.
У багатьох контекстах використовуються власні історії, які також об’єднуються в групи за смисловим і організаційних причин. Різне використання залежить від точки зору, наприклад, з точки зору користувача як власника продукту по відношенню до функцій, або з точки зору компанії по відношенню до організації завдань.
Мітки
В той час, як деякі пропонують використовувати epic і theme в якості міток для будь-якого мислимого типу угруповання користувальницьких історій, керівництво організації прагне використовувати їх для сильного структурування та об’єднання робочих навантажень. Наприклад, Jira, здається, використовує ієрархічно організований список справ, в якому вони назвали перший рівень завдань user story, другий рівень epics (групування користувальницьких історій) та «ініціативи» третього рівня (групування епопей). Тим не менш, ініціативи не завжди присутні в розробці управління продуктами і просто додають ще один рівень деталізації. В Jira існують «теми» (для цілей відстеження), які дозволяють перехресно зв’язувати і групувати елементи різних частин фіксованого ієрархії. У цьому використання “Джира” змінює значення теми з точки зору організації: наприклад, скільки часу ми витратили на розробку теми xyz. Але інше визначення тем – це набір історій, епосів, функцій і т. д. Для користувача, який формує загальну семантичну одиницю або мета, ймовірно, немає загального визначення, тому що існують різні підходи для різних стилів дизайну і розробки продукту. В цьому сенсі деякі також пропонують не використовувати які-небудь жорсткі групи та ієрархії.
Епіки
Великі історії або історії декількох користувачів, які дуже тісно пов’язані, підсумовуються як епічні. Загальне пояснення епопеї таке – користувацька історія, яка занадто велика для спринту.
Безліч епосів або історій, згрупованих за ієрархічним принципом, в основному відомі з Jira.
User Story map: опис
Карта історії являє собою графічну двовимірну візуалізацію відставання продукту. У верхній частині карти знаходяться заголовки, під якими згруповані історії, зазвичай звані «епосами» (великі грубі користувальницькі історії), «темами» (збірниками пов’язаних користувальницьких історій) або «діями». Вони визначаються шляхом орієнтації на робочий процес користувача або «в порядку, в якому ви б пояснили поведінку системи». Вертикально нижче епопей, фактичні приклади User Story map розміщені та впорядковані по пріоритету. Перший горизонтальний ряд представляє собою «ходячий скелет» і нижче, що представляє зростаючу складність.
Таким чином, стає можливим описати навіть великі системи без втрати загальної картини. Відгуки про User Story map, написані користувачами, зводяться до інтерактивності і веселості цього заняття, яке дуже радує людей. Вони заявляють про переваги такого програмного забезпечення. Це, насамперед, те, що вони полегшують оцінку завдань.
Приклади User Story є частиною гнучкого підходу, який дозволяє змістити акцент з написання вимог на їх обговорення. Всі гнучкі користувальницькі історії включають одне або два письмових пропозиції і, що більш важливо, серію бесід про бажаної функціональності.
Шаблон
Що можна сказати про приклади User Story map? Користувальницькі історії – це короткі, прості описи функцій, розказані з точки зору людини, яка бажає отримати нову можливість. Зазвичай це користувач або клієнт системи. Вони зазвичай слідують простого шаблону:
<Тип користувача> я хочу <деяку мета>, тому що <причина>.
Це і є відповідь на питання, як побудувати карту історій User Story mapping. Користувальницькі історії часто пишуться на картках або записках, зберігаються у взуттєвій коробці і розташовуються на стінах або на столах для полегшення планування та обговорення. Як такі вони сильно зміщують акцент з написання функцій на обговорення їх. Насправді ці дискусії важливіше будь-якого написаного тексту. А для останнього ви можете скористатися написаним вище зразком user stories.
Переваги
Одним з переваг гнучких користувальницьких історій є те, що вони можуть бути написані з різним ступенем деталізації. Ми можемо написати власну історію, щоб охопити велику кількість функціональних можливостей. Ці чудові користувальницькі історії зазвичай відомі як епопея. Ось приклад епічної гнучкої користувача історії з продукту для резервного копіювання на пк.
Як користувач, ви можете зробити резервну копію всього мого жорсткого диска. Оскільки епос зазвичай занадто великий для гнучкої команди, щоб завершити його за одну ітерацію, він розбивається на кілька невеликих користувальницьких історій, перш ніж він буде продовжений. Епопея, наведена вище, може бути розбита на десятки (або, можливо, сотні).
Як досвідчений користувач, ви можете вказати файли або папки для резервного копіювання на основі розміру файлу, дати створення і дати зміни. Як користувач, людина може вказати папки, які не підлягають резервного копіювання, щоб резервний диск не був заповнений речами, які йому не потрібно зберігати. Як деталізація додається в користувальницькі історії? Деталі можуть бути додані двома способами:
Коли відносно велика історія розбивається на кілька маленьких, гнучких користувальницьких історій, природно припустити, що деталі були додані. Зрештою, більше було написано.
Умови задоволення
Це просто приймальний тест високого рівня, який буде дійсним після завершення гнучкої користувача історії. Розглянемо наступне, як ще один приклад гнучкої користувача історії:
- Як віце-президент з маркетингу, я хочу вибрати сезон відпусток, який буде використовуватися при оцінці ефективності минулих рекламних кампаній, щоб я міг визначити прибуткові.
В цей приклад користувальницької історії можна додати подробиці, додавши наступні умови задоволення:
- Переконайтеся, що він працює з основними роздрібними свят: Різдво, Великдень, День президента, День матері, День батька, День праці, Новий рік.
- Підтримка свят, які охоплюють два календарних роки (жоден не охоплює три).
- Святкові сезони можуть бути встановлені від одного свята до іншого (наприклад, День подяки до Різдва).
- Курортні сезони можуть бути встановлені за кілька днів до свята.
Будь-хто може писати історію користувачів. Власник продукту зобов’язаний переконатися, що існує безліч незавершених користувальницьких історій, але це не означає, що їх автором є власник продукту. Протягом хорошого гнучкого проекту ви повинні очікувати, що кожен користувач буде мати приклади користувальницьких історій.
Також зверніть увагу, що той, хто пише історію користувача, набагато менш важливий, ніж той, хто бере участь у її обговоренні.
Значення для проектів
Користувальницькі історії написані протягом усього гнучкого проекту. Зазвичай семінар з написання історій проводиться на початку. Всі в команді беруть участь з метою створення журналу очікування продукту, який повністю описує функціональні можливості, які будуть додані в ході проекту або протягом трьох-шести місяців випуску в ньому. Приклади цього є в великому збірнику Example User Story map.
Деякі з цих гнучких користувальницьких історій, безсумнівно, будуть епічними. Пізніше епоси будуть розкладені на більш дрібні історії, які з більшою готовністю помістяться в одну ітерацію. Крім того, нові історії можуть бути написані і додані в портфель продуктів в будь-який час і ким завгодно.
Agile-проекти, особливо Scrum, використовують бэклог продукту, який є пріоритетним списком функціональності, яка буде розроблена в продукті або послузі. Незважаючи на те, що елементи незавершеного виробництва можуть бути такими, які забажає команда, власні історії стали кращою і найбільш популярною формою незавершеного виробництва.
У той час як відставання по продукту можна розглядати як заміну документа вимог традиційного проекту, важливо пам’ятати, що письмова частина гнучкої користувача історії («Як користувач, я хочу…») є неповною до обговорення цієї історії відбуваються. Так написано в американському мануалі User Story mapping and how to use it.
Часто краще розглядати письмову частину як покажчик на реальне вимогу. Користувальницькі історії можуть вказувати на діаграму, що зображає робочий процес, електронну таблицю, що показує, як виконувати обчислення, або будь-який інший артефакт, який бажає власник продукту або команда.
