Це переклад статті Story Mapping: Painting The Big Picture Of Your Product's User Stories. Оригінал можна знайти за цим посиланням. Переклад статт російською за цим посиланням.
Ви пильно вдивляєтеся у свій ноутбук. Звідти на вас вдивляється довгий список User Stories (користувальницькі історії). Ви перетасовуєте деякі з них, намагаючись розташувати їх у раціональному порядку.
Ви постійно пересортовуєте список. То для перегляду всіх Stories, пов'язаних із функцією A, то для перегляду найважливіших Stories за всіма функціями одночасно. Якщо це взагалі можливо.
Ви повторюєте це знову і знову — і губитеся.
Вам потрібна Story Map. Подивімося, як ви можете створити карту за допомогою Story Mapping, але спершу розберімося, що це взагалі таке.
Давайте глибше розберемося:
Що таке Story Mapping?
Якою є мета Story Mapping?
Хто створив Story Mapping?
Які проблеми вирішує Story Mapping?
Переваги Story Mapping
Підводні камені та помилки у Story Mapping
Як створити Story Mapping?
Story Mapping в Agile - що таке (User) Story Mapping?
Story Mapping або User Story Mapping — це метод, який використовується для product discovery: опис нового продукту або нової функції для продукту, що існує.
В результаті виходить Story Map: усі User Stories, об'єднані у функціональні групи. Це допомагає вам стежити за загальною картиною, а також надає всі деталі програми загалом.
Якою є мета Story Mapping?
Основна мета Story Mapping – полегшити product discovery та пріоритизація задач у розробці. Ви досягаєте цього, поміщаючи користувацькі дії та завдання на карту, яка допомагає тримати їх у контексті.
Story Map завжди показує, як кожна окрема історія вписується в додаток загалом. І це дозволяє легко виявляти прогалини й вирішувати, наскільки якась із них важливіша за інших.
Які agile-цінності та принципи підтримує Story Mapping?
Story Mapping підтримує дві цінності Agile Manifesto. «Співпраця із замовником важливіша за узгодження умов контракту» та «Готовність до змін важливіша за дотримання початкового плану».
Ви отримуєте найкращі результати, коли співпрацюєте з (майбутнім) користувачем або експертом у предметній галузі. Хтось, хто близько знайомий із роботою, яку має підтримувати ваш додаток, та проблемами, які він має вирішувати.
Використовуючи Story Mapping, легко реагувати на зміни. Бо коли ви додаєте нову User Story, або змінюєте/видаляєте наявну, легко визначити, що ще потрібно додати, змінити або видалити.
Хто створив Story Mapping?
Джефф Паттон уперше описав Story Mapping у своїй статті «Уся річ у тім, як ви його нарізаєте» (It’s All in How You Slice it) у 2005 році, на той час він уже використовував його протягом кількох років. Але тоді він не називав це Story Mapping. Він придумав цей термін у своїй статті «Беклог нової User Story — карта» (The New User Story Backlog Is a Map) у 2008 році. Він також написав про це книгу: «User Story Mapping: искусство гибкой разработки ПО».
Навіщо використовувати Story Mapping? – Які проблеми вирішує Story Mapping?
Коли ви закінчите знайомство з продуктом, ви, швидше за все, помістите User Stories в список невиконаних робіт на Scrum або Kanban-дошці.
Так правильно чинити щодо зусиль, витрачених на розробки, якщо ви визначилися з порядком будівництва продукту.
Однак можливості управління невиконаними роботами цих інструментів є недостатніми для управління продуктами та їх випуском. Просто тому, що відставання відображається, як довгий плоский список. Фільтрування, маркування та розфарбовування, які ви можете зробити, трохи допомагають, але ви ніколи не побачите повної картини.
Story Mapping вирішує цю проблему, упорядкувавши User Stories в простому зручному макеті.
Які (ще) переваги вам дає Story Mapping?
Story Mapping дає вам низку прямих і непрямих переваг.
Кожен може легко зрозуміти весь додаток - зазвичай це найскладніша частина розробки програмного забезпечення. Story Mapping розповідає історію про те, що вирішує ваш додаток і, як він це робить, для всіх, кого він зацікавив. Кожен може взяти участь у його створенні.
Ви повністю бачите загальну картину свого додатка. Втрата загальної картини - часта причина невдоволення в agile-командах.
Складання та видимість Story Mapping покращує ітеративну та інкрементальну розробку.
Повна картина на руках.
Показує вам, де User Stories вписується у всю систему за секунду.
Допомагає вирішити, що будувати насамперед. Story Mapping дозволяє легко вибирати User Stories з різних функцій, які разом забезпечують значну цінність. Це означає, що ви можете впевнено визначити обсяг та створити MVP або корисний реліз.
Означає, що вам легше уникнути створення чогось, що не працює. Ви не заблукаєте й не забудете важливі деталі, які фактично призведуть до чогось безглуздого, як ніби машини без гальм. Наприклад, таке може статися тому, що ви відкладали незначні Stories, від яких залежать найбільш значні Stories.
Дозволяє вам пройтися по Story Mapping, щоби перевірити її на наявність прогалин: легше виявити, де чогось не вистачає.
Дозволяє приймати рішення про пріоритети з урахуванням контексту всієї системи.
Означає, що ви не сліпо вдивлятиметеся в одну User Story.
Коли ви створюєте фізичну Story Mapping, ви отримуєте ще кілька переваг.
Карта стає координаційним центром для спільної роботи та допомагає спільному розумінню.
Повний контекст, що надається картою, допомагає швидко порівнювати User Stories одна з одною.
Ви можете додавати невеликі стікери до карток User Stories, щоби додавати додаткову інформацію або відзначати Stories для поточної та наступної ітерацій.
Підводні камені та помилки
Найбільш важливі підводні камені та помилки при використанні Story Mapping:
Робота без клієнта або когось близько знайомого з їхньою роботою
Вам необхідно співпрацювати з кимось, хто використовує або буде використовувати ваш продукт для підтримки їхньої роботи.
Без їхнього внеску та погляду ви будете вгадувати: що важливо, а що принесе реальну користь. Ви гратимете в гру «поцілив чи не поцілив» і, ймовірно, даремно витратите свої зусилля на розробку.
Немає мети, немає проблеми, яку потрібно вирішити
Працюючи без проблеми, яку потрібно вирішити та без мети, якої потрібно досягти, вам нема чим керуватися у своїх рішеннях. Ви не розумітимете, коли закінчите. А це приводить до марних зусиль або принаймні до витрат на зусилля, які не на часі.
Не видно карту
Чого очі не бачать, того і серцю не жаль. Без Story Map, яка є видимим нагадуванням про загальну картину вашого додатка, занадто легко відхилитися від курсу. Від цього з'являється небезпека заблукати в бур'янах: ув'язнути в деталях однієї Stories, які не стосуються цілого. Це б'є ще болючіше, коли ці деталі вимагають більших зусиль, ніж потрібно для цінності Stories.
Хоча фізична Story Map краща через додаткові переваги, які вона надає, нині так багато команд працюють віддалено, що у вас не завжди буде така розкіш. Але ви все ще можете візуалізувати карту. Наприклад, у вас може бути спеціальний великий монітор, який показуватиме карту скрізь, де є члени вашої команди.
Як створити Story Map за 6 кроків?
1.Почніть із великих валунів
Визначте великі Stories, широкі дії користувача, які має підтримувати ваш додаток. Це великі Stories, бо в них багато кроків. Ці кроки не обов'язково повинні мати певний порядок чи курс роботи. Насправді багато дій користувача включають кроки, які користувач буде виконувати в різний час і за різними графіками.
Напишіть кожну дію на картці. Розташуйте їх у порядку, зручному для користувача. Якщо хтось говорить про виконання однієї дії, а потім іншої, розташуйте їх у такому порядку. Якщо дії не виконуються одна за одною, просто використовуйте такий порядок, у якому користувач каже про них. Це допоможе розповісти історію додатку іншим людям.
Прирустимо, ви створюєте сайт Fun Events Club. Відвідувачі можуть шукати цікаві заходи, до яких можна приєднатися. Учасники можуть приєднуватися та проводити заходи. А команда сайту виступає, як модератор і перевіряє, чи відповідають нові заходи правилам.
Тоді великі валуни цього сайту, дії користувачів могли б виглядати так.
2.Розбийте свої валуни
Розбийте історію кожної активності користувачів на дрібніші Stories – завдання користувача. Помістіть завдання користувача під діями, до яких вони відносяться, а потім розташуйте їх у тому ж порядку, що й самі дії, або в такому порядку, який буде зрозумілий для користувача.
Для Fun Events Club це виглядає так.
Тепер у вас є те, що називається основою вашої Story Map.
Більшість завдань користувача мають власні кроки або незалежні підзавдання. Помістіть ці підзавдання під (якщо ви йшли горизонтально) завданням користувача, якому вони належать.
Це виглядає таким чином.
І завдання користувача, і підзавдання стають User Stories, які ви реалізуєте. Зрештою, користувачеві, як і раніше, потрібно вибрати захід зі списку, щоби переглянути його деталі або одразу приєднатися до нього.
3.Знайдіть камінці, які відлетіли
Пройдіть карту від початку до кінця з кимось із вашої сторони. Це може бути користувач, розробник, тестувальник або інший, зацікавлений у додатку.
Розкажіть про (типи) користувачів вашого додатку та про те, як вони використовують вашу програму. Це свого роду налаштування гумової качки для вашої Story Map. І це цілком природно виявить те, що ви пропустили. Або тому, що ви подумаєте про них самі, або тому, що ваш співрозмовник вказує на них.
Виявляється, для Fun Events Club ми також пропустили декілька
Коли ви йдете картою з кимось, скористайтеся можливістю, щоб доповнити Story Map з іншою інформацією, яку ви почуєте. Больові точки в поточній системі, можливості яких чекав користувач. Крайні випадки та обмеження, які необхідно враховувати. Напишіть їх на стікері та приклейте на відповідну картку.
4.Розставте свої камінці в ряд
Немає сенсу розставляти пріоритети щодо дій користувачів. Крім дій, які не будуть використовуватися щодня, цілком імовірно, що щось з кожної дії необхідно для створення цілого, яке працює.
Тому зосередьтеся на пріорітизації завдань користувача і підзадач в рамках кожної дії. Додатковою перевагою є те, що вам не потрібно думати про відносну важливість завдань, що належать до різних видів діяльності.
У нашому прикладі з Fun Events Club підзавдання вже розташовані у порядку важливості. Трохи передчасної оптимізації під вашим авторством.
5.Зліпіть цінний перший валун із купи камінців
Виберіть завдання з кожної дії, які необхідні для створення першої версії, яка працює від початку до кінця, навіть якщо вона все ще знаходиться в зародковому стані. Це ваш MVP, ваш мінімально життєздатний продукт.
6.Продовжуйте ліпити
Плануйте наступні випуски, розставляючи пріоритети для завдань, що залишилися. Те, як ви хочете рухатися вперед, залежить від вас.
Ви можете віддати пріоритет найціннішим Stories з кількох або навіть всіх дій користувача. Ви також можете зосередитися на одній дії та віддати пріоритет усім Stories, окрім найменш цінних. І, можливо, ділові люди у вашій компанії захочуть взяти до уваги інші аспекти. Вони перебувають у кращому становищі, щоб вирішити, які особливості та Stories зроблять гарний випуск.
Замість того, щоб малювати лінії між Stories, щоб відзначити, які з них входять до наступних випусків, ви також можете перебудувати карту, щоб показати випуски у вигляді горизонтальних відрізків Stories.
Використання Story Mapping з наявними додатками
Story Mapping підходить не лише для нових додатків. Ви також можете використовувати його для наявних додатків.
Щоб допомогти вам зрозуміти, що робить додаток, і відтворити його загальну картину, щоб ви могли скористатися цією перевагою при просуванні вперед.
І, звичайно ж, намітити нові функції та помістити їх у контекст додатка, що існує.
Якщо ви не можете (не маєте права) спочатку створити повну Story Map наявної програми, принаймні розмістіть усі дії користувача.
Це дасть вам контекст нових функцій.
І це також дасть вам місце для розміщення завдань, які потрібно додати або змінити в теперішніх діях користувача. Наприклад, коли ви створюєте нову функцію для надсилання цільових електронних листів. Вам потрібно буде додати кілька контактів до чинного списку контактів. І вам, ймовірно, потрібно буде додати деякі додаткові можливості фільтрації.
Станьте оповідачем
Пам'ятаєте біль від необхідності розставляти пріоритети Stories у довгому плоскому беклозі?
І наскільки важко було пояснити додаток іншим людям?
Тепер ви знаєте, як Story Mapping може допомогти вам.
Щоб розставляти пріоритети в Stories та збирати випуски, які приносять значну цінність. І розповісти історію вашого додатка, адже користувачі використовуватимуть його. Просто пройдіться по Story Map.
Отже, зробіть своє майбутнє щасливим та скористайтеся перевагами Story Mapping. На стіні або за допомогою цифрового інструменту.
Часті за питання
Що входить до User Storу?
Agile User Storу складаються з одного-двох письмових речень, а також списку ідей, які ви хочете мати за бажаною функціональністю.
Що таке epics?
Epics - це великі колекції User Stories, які можуть охоплювати кілька команд і проєктів. Крім того, вони зазвичай доставляються через серію спринтів.
Що таке story mapping?
Story mapping — це процес, який використовується для опису нового продукту або для надання нової функції продукту, що існує.
Які інструменти потрібні для story mapping?
Для story mapping потрібен інструмент візуалізації, такий, як біла дошка та стікери, або їх цифровий еквівалент.
Скільки часу займає story mapping? User story map необов'язково створювати за один сеанс. Іноді це може зайняти кілька сеансів протягом кількох днів, залежно від розміру, складності та масштабу продукту.
Commentaires