User Story Canvas

User Story Canvas

Максим Гапонов, Михаил ПодурецLuxoft

Максим ГапоновAgile Coach, Luxoft

В ИТ больше 10 лет. Был разработчиком, руководителем отделов, менеджером проектов, менеджером продуктов и техническим директором. Работал в стартапах и в крупных компаниях. Опыт в Agile более 7 лет.PSM I, CSPO, ICP, ICP-BVAАккредитованный тренер ICP, ICP-BVA

Михаил ПодурецAgile Coach, Luxoft

В IT c 2006 года, работал инженером, руководителем проектов, Скрам Мастером, Владельцем продукта, делал ПО для самолетов, ALM для тех, кто делает самолеты.

PSM I, CSPO, ICP, ICP-ATFАккредитованный тренер ICAgile

А, собственно,О чем речь?

Немного о правилах

Давайте знакомиться

Что не так с пользовательскими историями?Они слишком универсальны:

• Как супер-клей, который склеивает что угодно с чем угодна

• Должны отражать все знания, которые мы имеем по продукту

• Не совсем понятно, что в них надо включать, а что - нет

Слишком большие, слишком маленькие:

• Делаем их общими - утрачиваем контроль

• Делаем их детальными - занимаемся только их поддержкой

Масштабированные/распределенные рабочие среды:

• Пробелы в коммуникациях приводят к переделкам

• Недостаток стандартизованного описания

• Потеря фокуса в обсуждениях

Как должно было бы быть по-хорошему (by Jeff Patton)Что важно учесть:

• Для кого, что и почему?

• Окружающий контекст

• Распределенное понимание

• Возможные ограничения

• Масштабированность/распределенность рабочей среды

А вот и он — User Story Canvas

Поговорим о коммуникациях

Кто вовлечен?Ключевая персона

• Вы же уже используете персоны?

• Оснвной тип пользователя

• Задает контекст и способствует эмпатии

Консультанты

• У кого есть опыт?

• Есть ли доступ к эспертам?

• Коллеги, которые делали что-то подобное?

Заказчики

• Кто ваши заказчики?

• Каковы ожидания заказчиков?

• Возможен ли конфликт интересов?

Заинтересованные лица

• Чьи интересы необходимо учесть?

• Возможен ли конфликт интерсов?

• Кого может затронуть?

• Всех ли мы учли?

Поговорим о контексте

Что окружает?Определение потребности

• Напрямую адресует почему

• Какую именно потребность мы хотим адресовать?

• Чего пользователь хочет в реальной жизни?

• Как правило, глаголы

Контекст использования

• Что окружает пользователя?

• Что предшествует и приводит к использованию?

• Что пользователь будет делать с результатами?

Поговорим об истории

Что делаем?Пользовательская история

• Придерживаемся обычного формата

• Фокус на кто, что и почему

Критерии приемки

• Как определить, что функциональность готова полностью?

• У вас есть стандарты описания критериев приемки?

Возможные решения

• Всегда существует больше одного способа для получения результата

• Не забывайте про принцип Output vs Outcome

• Используйте опыт, знания и креативность коллег

Поговорим о выполнимости

Что может помешать?Ограничения

• Какой опыт и знания необходимы для реализации?

• Какие инструменты понадобятся (БД, фреймворки, API и т.д.)

Необходимые данные

• Доступ к каким данным необходим для реализации?

• Могут ли данные или способы их использования затронуть другую функциональность?

Зависимости

• Есть ли заисимости с другими историями в текущем релизе?

• Есть ли зависимости с другими историями в следующих релизах?

Поговорим о результатах

Где мы?Результат

• Вспоминаем почему. Почему это нужно в продукте для нас? Почему нужно для пользователя?

• Какие метрики будут использоваться для отслеживания результата реализации? Готовы ли они?

• Какие результаты метрик будут оцениваться как положительные/отрицательные? Как мы будем реагировать?

Обратная связь

• Какие способы будут использованы для сбора обратной связи после реализации?

• Есть ли у нас все необходимое для сбора обратной связи?

• Как мы будем интерпретировать результаты? Как будем реагировать?

Примеры использования User Story CanvasСессии улучшения бэклога

• Релиз - для обсуждения на общем уровне

• Спринт - для обсуждения подробностей

• Помогает сфокусировать обсуждения

• Распределение обсуждений разных частей по разным совещаниям

Настройка процессов discovery

• Формирование и поддержание распределенного понимания

• Стандартизация процесса документирования продукта

• Настройка инструментов проектного/продуктового управления

Как это было?

Узнать побольше

That’s all,Peace!