User Stories - этот подход к описанию знаний о продукте просто понять и очень сложно использовать :) Кроме того, складывается ощущение, что при его использовании забывается самая главная часть - умение рассказывать истории о продукте и формировать общее понимание без необходимости подробного описания всех спецификаций, которые все равно никто никогда не читает. Мы постарались собрать все темы, которые необходимо осветить для беспрепятственной реализации задумок и разработали специальный инструмент для фасилитации обсуждений - User Story Canvas
2. Максим Гапонов
Agile Coach, Luxoft
В ИТ больше 10 лет. Был разработчиком, руководителем
отделов, менеджером проектов, менеджером продуктов и
техническим директором. Работал в стартапах и в крупных
компаниях. Опыт в Agile более 7 лет.
PSM I, CSPO, ICP, ICP-BVA
Аккредитованный тренер ICP, ICP-BVA
3. Михаил Подурец
Agile Coach, Luxoft
В IT c 2006 года, работал инженером, руководителем проектов,
Скрам Мастером, Владельцем продукта, делал ПО для
самолетов, ALM для тех, кто делает самолеты.
PSM I, CSPO, ICP, ICP-ATF
Аккредитованный тренер ICAgile
8. Что не так с пользовательскими историями?
Они слишком универсальны:
• Как супер-клей, который склеивает что
угодно с чем угодна
• Должны отражать все знания, которые
мы имеем по продукту
• Не совсем понятно, что в них надо
включать, а что - нет
Слишком большие, слишком
маленькие:
• Делаем их общими - утрачиваем
контроль
• Делаем их детальными - занимаемся
только их поддержкой
Масштабированные/распределенные
рабочие среды:
• Пробелы в коммуникациях приводят к
переделкам
• Недостаток стандартизованного
описания
• Потеря фокуса в обсуждениях
9. Как должно было бы быть по-хорошему (by Jeff Patton)
Что важно учесть:
• Для кого, что и почему?
• Окружающий контекст
• Распределенное понимание
• Возможные ограничения
• Масштабированность/
распределенность рабочей среды
12. Кто вовлечен?
Ключевая персона
• Вы же уже используете персоны?
• Оснвной тип пользователя
• Задает контекст и способствует
эмпатии
Консультанты
• У кого есть опыт?
• Есть ли доступ к эспертам?
• Коллеги, которые делали что-то
подобное?
Заказчики
• Кто ваши заказчики?
• Каковы ожидания заказчиков?
• Возможен ли конфликт интересов?
Заинтересованные лица
• Чьи интересы необходимо учесть?
• Возможен ли конфликт интерсов?
• Кого может затронуть?
• Всех ли мы учли?
14. Что окружает?
Определение потребности
• Напрямую адресует почему
• Какую именно потребность мы хотим
адресовать?
• Чего пользователь хочет в реальной
жизни?
• Как правило, глаголы
Контекст использования
• Что окружает пользователя?
• Что предшествует и приводит к
использованию?
• Что пользователь будет делать с
результатами?
16. Что делаем?
Пользовательская история
• Придерживаемся обычного формата
• Фокус на кто, что и почему
Критерии приемки
• Как определить, что
функциональность готова полностью?
• У вас есть стандарты описания
критериев приемки?
Возможные решения
• Всегда существует больше одного
способа для получения результата
• Не забывайте про принцип Output vs
Outcome
• Используйте опыт, знания и
креативность коллег
18. Что может помешать?
Ограничения
• Какой опыт и знания необходимы для
реализации?
• Какие инструменты понадобятся (БД,
фреймворки, API и т.д.)
Необходимые данные
• Доступ к каким данным необходим
для реализации?
• Могут ли данные или способы их
использования затронуть другую
функциональность?
Зависимости
• Есть ли заисимости с другими
историями в текущем релизе?
• Есть ли зависимости с другими
историями в следующих релизах?
20. Где мы?
Результат
• Вспоминаем почему. Почему это
нужно в продукте для нас? Почему
нужно для пользователя?
• Какие метрики будут использоваться
для отслеживания результата
реализации? Готовы ли они?
• Какие результаты метрик будут
оцениваться как положительные/
отрицательные? Как мы будем
реагировать?
Обратная связь
• Какие способы будут использованы
для сбора обратной связи после
реализации?
• Есть ли у нас все необходимое для
сбора обратной связи?
• Как мы будем интерпретировать
результаты? Как будем реагировать?
21. Примеры использования User Story Canvas
Сессии улучшения бэклога
• Релиз - для обсуждения на общем
уровне
• Спринт - для обсуждения
подробностей
• Помогает сфокусировать обсуждения
• Распределение обсуждений разных
частей по разным совещаниям
Настройка процессов discovery
• Формирование и поддержание
распределенного понимания
• Стандартизация процесса
документирования продукта
• Настройка инструментов проектного/
продуктового управления