Плоский беклог — це список, відсортований за пріоритетом. Він показує, що будувати далі, але не те, як усі частини поєднуються, і дозволяє легко випустити десять доопрацьованих функцій, які не складаються в цілісний продукт, який користувач може завершити. Карта історій користувача вирішує це, розташовуючи історії вздовж шляху користувача, щоб ви могли побачити весь продукт і вирізати перший реліз, який працює від початку до кінця.
Цей гайд охоплює, як створити карту історій, як перетворити її верхній зріз на обсяг MVP, як перевірити кожну історію за допомогою INVEST та патерни розбиття, які перетворюють великі історії на спринтові. Якщо вам спочатку потрібні основи, почніть з як писати user stories.
Що таке карта історій користувача
Карти історій були запроваджені Джеффом Паттоном, спочатку в статті 2005 року «It's all in how you slice it», а потім у його пості 2008 року The new user story backlog is a map, а згодом у його книзі User Story Mapping (O'Reilly, 2014). Дивіться також його ресурси з картографування історій та запис у глосарії Agile Alliance.
Мапа має два напрямки:
- Зліва направо — це наратив: великі активності, які проходить користувач, у порядку, та кроки всередині кожної. Цей верхній ряд називається хребтом.
- Зверху вниз — це пріоритет і деталізація: під кожним кроком розташовані історії, які роблять його можливим, з найважливішими зверху та альтернативами, граничними випадками і бажаними функціями нижче.
Горизонтальні лінії на мапі поділяють її на зрізи релізів. Усе, що вище першої лінії, — це перший реліз; він має охоплювати кожну активність у хребті, хоча б мінімально.
Як створити карту історій за 6 кроків
Ви можете зробити це на стіні зі стікерами або на цифровій дошці. Запросіть тих, хто буде визначати обсяг, і тих, хто буде розробляти продукт: продукт, дизайн, принаймні одного розробника та, бажано, когось, хто спілкується з клієнтами. Перша мапа для невеликого продукту зазвичай займає робочу сесію на кілька годин.
1. Визначте проблему
Запишіть, для кого призначений продукт, яку проблему він вирішує та який результат покаже, що перший реліз спрацював. Обмежтеся трьома реченнями вгорі мапи. Кожне подальше скорочення оцінюється щодо цього результату.
2. Побудуйте хребет
Запитайте: «Що робить користувач першим, а потім що?» і запишіть кожну активність на картці, зліва направо. Використовуйте дієслова: «Знайти гуляча», а не «Пошук». Потім розбийте кожну активність на кроки. Розповідайте історію вголос, поки працюєте; прогалини стають очевидними, коли хтось каже: «Стоп, як вони сюди потрапили?»
3. Досліджуйте деталі
Під кожним кроком додайте історії, які роблять його можливим: опції, альтернативи, випадки помилок, потреби адміністратора. Ще не фільтруйте. Саме тут мапа окуповує себе, оскільки люди помічають відсутні елементи, коли бачать увесь шлях одразу.
4. Знайдіть ходячий каркас
Ходячий каркас (термін Алістера Кокберна) — це найтонша версія продукту, яка працює від початку до кінця. Оберіть одну історію під кожним кроком, без якої користувач не може обійтися, і перемістіть її наверх. Якщо під якимось кроком немає нічого суттєвого, запитайте, чи належить він взагалі до хребта.
5. Розріжте релізи
Проведіть горизонтальні лінії, щоб згрупувати історії в релізи. Дайте кожному зрізу назву, яка вказує на результат, наприклад «Власники можуть забронювати та оплачувати одну прогулянку», а не «Реліз 1». Кожен зріз має бути придатним до використання самостійно та відповідати на питання, яке у вас є щодо продукту.
6. Сплануйте перший зріз і тримайте мапу живою
Напишіть критерії прийняття для історій у першому зрізі (наш шаблон історії користувача має три формати), перевірте кожну за INVEST, розбийте занадто великі та перемістіть їх у беклог спринту. Тримайте мапу видимою та оновлюйте її після кожного релізу; це інструмент планування, а не одноразовий результат воркшопу.
Приклад: карта історій для додатку для прогулянок із собаками
Ось стисла мапа для маркетплейсу, що з’єднує власників собак із місцевими гулячами. Стовпці — це хребет; кожен ряд — це зріз релізу.
| Зріз | Реєстрація | Знайти гуляча | Забронювати прогулянку | Оплата | Під час прогулянки | Після прогулянки |
|---|---|---|---|---|---|---|
| Walking skeleton (MVP) | Реєстрація за електронною поштою; додавання одного собаки | Перегляд списку затверджених гуляльників поблизу поштового індексу | Надсилання запит на час; гуляльник приймає запит через електронну пошту | Оплата карткою під час бронювання | Гуляльник позначає початок і завершення прогулянки | Власник отримує підсумкове повідомлення |
| Реліз 2 | Вхід через Google або Apple; кілька собак | Фільтрування за ціною та доступністю; профілі гуляльників із фото | Прийняття та відхилення в додатку; нагадування | Збережені картки; автоматичне повернення коштів при скасуванні | Живе розташування на карті | Оцінки та відгуки |
| Пізніше | Реферальні коди | Улюблені гуляльники | Щотижневі повторювані бронювання | Підписки та чаювання | Фотооновлення під час прогулянки | Повторне бронювання в один дотик |
Зверніть увагу на те, чого не входить у skeleton: немає живого відстеження, немає відгуків, немає повідомлень у додатку, а затвердження гуляльників відбувається вручну. Але власник все одно може пройти шлях від реєстрації до завершення та оплати прогулянки, чого достатньо, щоб перевірити, чи будуть люди бронювати незнайомця для прогулянки зі своєю собакою.
Як карта перетворюється на обсяг MVP
Верхній зріз хорошої карти — це ваш обсяг MVP. Використовуйте ці перевірки, перш ніж зобов’язатися:
- Він охоплює кожну діяльність у хребті. Продукт, який дозволяє бронювати, але не оплачувати, — це не MVP; це половина демо.
- Він обслуговує одного основного користувача та один головний шлях. Вторинні ролі (адміністратори, партнери) отримують мінімум, необхідний для підтримки шляху, часто це електронна таблиця або ручний крок.
- Він перевіряє конкретне припущення. Напишіть поруч із ним запитання, на яке відповідає цей зріз, наприклад «Чи будуть власники платити, перш ніж зустрітися з гуляльником?»
- Ручна робота за лаштунками допустима. Затвердження гуляльників вручну або надсилання підсумків самостійно є прийнятним для перших користувачів і показує, що варто автоматизувати.
- Він вписується у ваш бюджет і графік. Якщо ні, скоротіть історії в межах кожного стовпця (розбийте їх, використовуючи наведені нижче шаблони), а не викидайте цілі стовпці.
Для засновників без технічного співзасновника карта також є найкориснішим документом, який можна передати розробницькій команді: вона показує весь продукт, перший реліз та обґрунтування скорочень на одній сторінці. Наш гайд щодо створення MVP засновником без технічної освіти покриває, що робити з ним далі.
Чек-лист INVEST
Щойно історії опиняться на карті, перевірте кожну з них у першому зрізі за INVEST, абревіатуру, яку Біл Вейк запропонував у 2003 році в INVEST in good stories, and SMART tasks.
| Літера | Значення | Запитання для перевірки | Якщо не відповідає |
|---|---|---|---|
| I | Незалежність | Чи можемо ми побудувати та випустити це, не чекаючи на іншу історію? | Об’єднайте тісно пов’язані історії або розбийте їх інакше, щоб кожна приносила результат самостійно |
| N | Переговорність | Чи залишається рішення відкритим для обговорення? | Видаліть деталі реалізації з історії; залиште їх у примітках |
| V | Цінність | Чи помітить користувач або бізнес, якщо це буде випущено? | Об'єднайте технічні завдання з історією, якій вони слугують |
| E | Оцінюваність | Чи команда має достатньо інформації, щоб оцінити обсяг? | Проведіть обмежений за часом спайк або поставте запитання, що блокують оцінку |
| S | Малість | Чи вкладається це комфортно в один спринт? | Розбийте це за одним із наведених нижче шаблонів |
| T | Тестованість | Чи можемо ми сформулювати критерії приймання, які можна перевірити на проходження або провал? | Замініть розмиті слова («швидко», «легко») на спостережні результати |
Незалежність — найскладніший критерій для повного виконання, і це нормально вважати його ціллю, а не правилом. Дрібність і тестованість — ті, щодо яких варто бути суворими.
Як розбивати історії користувача
Розбивайте історії вертикально: кожен фрагмент має все одно надавати щось, що бачить користувач, через усі шари системи. Розбиття за шарами («створити базу даних», «створити API», «створити екран») дає фрагменти, які не надають нічого, доки не буде завершено всі три, що суперечить самій ідеї. Ці шаблони, зібрані в Humanizing Work guide to splitting user stories Річардом Лоуренсом і Петером Гріном, покривають більшість випадків.
Кроки робочого процесу
Розбийте багатокроковий процес на його кроки або спочатку створіть просту кінцеву версію, а потім додавайте кроки. «Забронювати прогулянку» перетворюється на: запитати слот; гуляч приймає; власник отримує підтвердження. Пізніше: гуляч пропонує інший час.
Варіації бізнес-правил
Якщо в історії є кілька правил, спочатку випустіть найпоширеніше. «Повернення коштів за скасування» перетворюється на: повне повернення, якщо скасовано за 24 години; часткове повернення в межах 24 годин; без повернення після початку прогулянки.
Варіації даних
Почніть з одного типу даних і додавайте інші. «Пошук за локацією» перетворюється на: пошук за поштовим індексом; потім за поточною локацією; потім за виділенням області на карті.
Спершу успішний шлях, потім неуспішні
Спочатку створіть основний шлях успіху, потім обробляйте помилки як окремі історії, впорядковані за частотою виникнення та ступенем шкоди. «Оплата карткою» перетворюється на: успішна оплата; картка відхиlena; провайдер оплати недоступний.
Операції
«Керування собаками» приховує створення, перегляд, редагування та видалення. Часто для першого релізу потрібні лише створення та перегляд.
Варіації інтерфейсу або платформи
Спочатку випустіть на одній платформі або з одним методом вводу. Web замість mobile, або англійська замість інших мов, якщо це дозволяють ваші перші користувачі.
Спочатку проста версія, відкладіть продуктивність
Спершу зробіть, щоб працювало, потім зробіть швидким. Список гулячів, який завантажується за три секунди для 50 гулячів, підходить для пілотного міста; оптимізуйте, коли цифри це виправдають, як окрему історію.
Спайк
Коли історію неможливо оцінити через невідоме («чи можемо ми отримати поточну локацію у фоновому режимі на обох платформах телефонів?»), виділіть короткий, обмежений за часом дослідження. Результатом спайка є знання та краще оцінена історія, а не випущений функціонал.
SPIDR: коротка версія для запам'ятовування
Майк Коун групує основні техніки розбиття під абревіатурою SPIDR: Spikes, Paths, Interfaces, Data and Rules (Five simple but powerful ways to split user stories). Якщо історія занадто велика і ви не впевнені, з чого почати, пройдіться по п'яти в цьому порядку.
| Техніка | Розбити за | Приклад |
|---|---|---|
| Spikes | Спочатку дослідіть невідоме | Дводенний спайк щодо фонової локації перед оцінкою живого відстеження |
| Шляхи | Альтернативні шляхи через історію | Спочатку оплата карткою, потім — гаманцем |
| Інтерфейси | Тип пристрою, браузера або інтерфейсу | Спочатку бронювання власником через веб, потім — через мобільний додаток |
| Дані | Типи або діапазони даних | Спочатку одна собака на бронювання, потім — кілька |
| Правила | Бізнес-правила, спочатку спрощені | У пілотному режимі немає правил скасування; політика повернення коштів — окрема історія |
Часті помилки при створенні карти історій
- Картографування функцій замість дій користувача. Хребет у вигляді «Вхід, Панель керування, Налаштування» описує екрани, а не подорож.
- Створення першого зрізу лише в одному стовпці. Досконалення реєстрації до того, як з’явиться бронювання, залишає вас без можливості тестувати.
- Надмірна деталізація карти. Якщо ви пишете критерії приймання на дошці, ви перейшли від картографування до уточнення вимог.
- Картографування без розробників у кімнаті. Зрізи, намальовані без їхньої участі, часто приховують дорогі історії на початку.
- Вважати карту закінченою. Після кожного релізу переносьте отримані знання на карту та знову визначайте наступний зріз.
Щоб побачити добре сформовані історії, які можна адаптувати для вашої карти, дивіться наші прикладах user story.
Інструменти для картографування історій
Стіна та стікери досі найкраще підходять для першої сесії, коли всі в одній кімнаті. Для віддалених команд загальні дошки, такі як Miro та FigJam, мають шаблони карт історій, а спеціалізовані інструменти, наприклад StoriesOnBoard, синхронізують карти з трекерами беклогу. Jira та подібні трекери можуть показувати історії, згруповані за епіками, що дає вам хребет, але зазвичай потрібен плагін або дошка, щоб побачити зрізи релізів. Оберіть інструмент, який ваша команда буде тримати відкритим; карта, яку ніхто не оновлює, втрачає корисність протягом одного-двох спринтів.
Часті запитання
Що таке картографування історій користувача?
Техніка, запропонована Джеффом Паттоном, для розташування історій користувача вздовж подорожі користувача (хребет, зліва направо) та за пріоритетом (зверху вниз). Горизонтальні лінії ділять карту на зрізи релізів, щоб команда могла планувати релізи, які працюють від початку до кінця.
Яка різниця між картою історій та беклогом продукту?
Беклог — це єдиний список, упорядкований за пріоритетом. Карта історій показує ті самі історії в двох вимірах: за діями користувача та за пріоритетом, щоб ви могли побачити, як вони поєднуються, і чи охоплює реліз усю подорож.
Що таке «ходьбовий скелет»?
Найтонша версія продукту, яка працює від початку до кінця, з однією ключовою історією під кожним кроком подорожі. Термін походить від Алістера Кокберна; на карті історій це зазвичай перший зріз релізу.
Що означає абревіатура INVEST?
Незалежні, Обговорювані, Цінні, Оцінювані, Малі та Тестовані. Білл Вейк запропонував її у 2003 році як чек-лист для якісних історій користувача.
Наскільки малою має бути історія користувача?
Достатньо малою, щоб команда могла завершити, протестувати та продемонструвати її в межах одного спринту, і бажано протягом кількох днів. Якщо історія регулярно займає весь спринт, розбийте її.
Що таке SPIDR?
Набір із п’яти технік розбиття історій, описаних Майком Коном: Spikes, Paths, Interfaces, Data та Rules.
Хто має брати участь у сесії картографування історій?
Люди, які визначають обсяг, та люди, які його реалізують: власник продукту або засновник, дизайнер, принаймні один розробник, і бажано хтось, хто спілкується з клієнтами, наприклад, підтримка або продажі.
Маєте карту або лише ідею та потребуєте побудувати перший зріз? Ми можемо допомогти вам визначити обсяг MVP, який працює від початку до кінця, та випустити його короткими спринтами. Дивіться наші щомісячні плани розробки.