Користувацькі історії з User Story Canvas

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

Практика опису вимог до продукту за допомогою користувацьких історій (User Story) давно і міцно закріпилися в Agile-процесах як основний інструмент для наповнення Беклогу Продукту. Користувацькі історії описують великі і малі проблеми реальних персон, які очікують від продуктів і послуг отримати кращий досвід, порівнюючи з тим як це працює у них зараз. Користувацькі історії допомагають розробникам зосередитися на розв’язанні проблем користувача, а не тільки виконання технічних завдань.

Складні користувацькі історії

Спочатку “користувацька історія” була призначена як інструмент для поліпшення розуміння вимог від замовників. Щоб використовувати цей інструмент правильно, Рон Джеффріс запропонував три принципи:

• Картка: історія коротко записується на картці за шаблоном:
  • AS < define user > I WANT < descibe experience > SO THAT < describe benefit >;
• Розмова: розробники вивчають картку, спілкуються з Власником Продукту, щоб отримати знання про домен, зрозуміти контекст, запропонувати ідеї для реалізації;
• Підтвердження: для того, щоб не забувати про важливі деталі в процесі обговорення, команда документує важливі домовленості.

Перші два принципи досить просто зрозуміти і зазвичай не викликають запитання як це має працювати. Третій принцип допускає різні варіанти документування домовленостей між власником продукту і командою розробників. Занотовувати домовленості у вигляді критеріїв прийняття (acceptance criteria) є загальноприйнятою практикою, але знання і контекст не передаються в тій самій структурній формі, так що тут ми покладаємося на вдачу. Підтверджувати тільки “критерії прийняття” достатньо для простих історій, але не для складних.

Максим Гапонов, автор інструменту User Story Canvas, ретельно досліджував, чому розробка вимог складних історій часто призводить до негативного результату, і вказав на наступні причини:

• Ми описуємо у вигляді користувацьких історій всі знання про продукт, навіть якщо частина знань просто не клеїться як “історія”;
• Не зрозуміло, що включати;
• Якщо їх узагальнити – втрачаємо контроль;
• Робимо їх деталізованим – займаємося тільки їхньою підтримкою;
• Комунікаційні прогалини призводять до частих змін у вимогах;
• Відсутність стандартного опису;
• Втрата фокусу у дискусіях.

Знання про продукт

Для того, щоб описати складну користувацьку історію, необхідно розібратися в контексті продукту, отримати необхідні знання про бізнес-домен. Багато аспектів можуть просто пройти повз увагу розробників і, як наслідок, користувачі будуть вимагати допрацьовувати те, що вже зроблено. Для того, щоб вирішити цю проблему, ми можемо використовувати User Story Canvas, інструмент, який мотивує підтвердити більше аспектів з власником продукту, ніж просто “критерії прийняття”.

Заповнення User Story Canvas

Канва користувацької історії має чітку структуру (див. зверху) і вимагає певного порядку заповнення.

Блок комунікацій: перші чотири кроки називаються комунікаційним блоком. Команда погоджує категорію кінцевого користувача, чим більш конкретна категорія, тим більш сфокусовано вийде обговорити інші деталі. Далі Власник продукту та команда ідентифікують конкретних експертів бізнес домену, які можуть прояснювати розробникам деякі нюанси вже в процесі розробки. Також вписують конкретні імена замовників та інших зацікавлених сторін. Команда повинна чітко розуміти, по яких питаннях і з ким вони можуть спілкуватися для уточнення їхніх вимог. Таким чином, власник продукту не стане вузьким місцем в процесі реалізації складних історій. Аналіз блоку комунікацій дозволить власнику продукту визначити можливих учасників для Sprint Review, планувати наперед та підтверджувати участь стейколдерів на цій зустрічі.

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

Блок користувацької історії: сьомий, восьмий і дев’ятий кроки заповнюються як перехід від проблеми до вирішення. Зрозумілий контекст допоможе сформулювати саме ту історію, яка матиме позитивний вплив на кінцевого користувача. Крім того, цей досвід повинен бути описаний у вигляді декількох можливих рішень з їх плюсами і мінусами. Наприклад, дешево і сердито, або дорого та багато. І в кінці цього блоку важливо задокументувати “критерії прийняття”.

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

Блок очікуваних результатів: останні два кроки домовляємося про обробку і інтерпретацію зворотного зв’язку від користувачів. Вважається, що історія успішно реалізована, якщо відповідає критеріям прийняття від власника продукту. Але це не зовсім так: історія на то є “користувацькою”, тому що збирати зворотний зв’язок потрібно від користувачів. Команда повинна розуміти, як збирати інформацію про використання продукту. Може розробникам варто інтегрувати реалізовану історію з Google Analytics, або розробити свій власний механізм для відстеження реального використання нових функціональних можливостей.

Користування User Story Canvas

Учасники останнього мітапу, на якому ми розбирали цей інструмент, погодилися, що стріляти по горобцям з гармати не варто. Тобто, це нормально використовувати полотно для великих і складних історій. Повне ім’я інструменту User Story Discussion Canvas, що означає інструмент має використовуватися для фасилітації процесу обговорення користувацьких історій. На таких зустрічах, дискусія має розпочинатися з попередньою оцінкою історії за розміром і складністю, з тим щоб знайти правильний інструмент для обговорення.

User Story Discussion Canvas прекрасно вписується в процес обговорення складних і великих історій. Великі, але не складні історії (це також трапляється), варто починати одразу з шаблонів розбивки (User Story Splitting Patterns). Якщо реалізація історії не об’ємна, але складна і заплутана в обмеженнях і залежностях, Максим Гапонов рекомендує заповнювати User Story Canvas частково, тільки ті блоки, про які важливо домовитись і задокументувати. Зрозумілі і не великі за розмірами історії не потребують комплексного інструменту для обговорення.

Онлайн фасилітація User Story Canvas

Фасилітація онлайн зустрічей, з використанням User Story Canvas, має проходити без зайвих ускладнень. Для цього вам знадобляться:

• Підготована дошка в Mural або Miro. Саму канву з високою роздільною здатністю можна отримати за посиланням нижче;
• Почати зустріч в Zoom з попередньою оцінкою історії за складністю та обсягом, щоб переконатися, що Busines Model Canvas буде сприйматися командою як корисний інструмент;
• Процес складається з п’яти кроків по 10 хвилин. Вам знадобиться від 30 до 90 хвилин, щоб заповнити канву, в залежності від складності історії;
• Для обговорення кожного блоку канви, фасилітатор зустрічі виставляє час і відкриває конференцзал на 10 хвилин. Після того, як він закриває приміщення, збирає зворотний зв’язок, відповідає на питання, і знову відкриває кімнату на 10 хвилин, щоб обговорити наступний блок.

Завантажити модель User Story Canvas

Висновки

Як і будь-який інший інструмент фасилітації, User Story Canvas має своє застосування. Обговорення складних історій з простими інструментами призводить до втрати багатьох важливих знань і, як наслідок, ми отримуємо багато проблем з реалізацією, доставкою та різноманітних конфліктів.

P.S. Корисні ресурси

• Основні XP: карта, розмова, підтвердження Рона Джеффріс
• Почати з дизайну-Стенфордський d. школа
• Прагматичні персони: поклавши користувача назад в історії користувачів
• Інвестуйте в хороші історії, і РОЗУМНІ завдання-XP123
• Двадцять способів розбити історії

Слава Москаленко, CEO Agile.Live