Пользовательские истории фокусируют разработчиков на решении проблем пользователей, а не просто выполнении технических задач.
Практика описания требований с помощью пользовательских историй уже давно и прочно укоренилась в гибких процессах, как основной инструмент для наполнения Бэклога Продукта. Пользовательские истории описывают большие и маленькие проблемы реальных персон, которые ожидают от продуктов и сервисов получать лучший опыт, по сравнению с тем, как это работает здесь и сейчас. Пользовательские истории фокусируют разработчиков на решении проблем пользователей, а не просто выполнении технических задач.
Пользовательские истории
Изначально «пользовательская история» предполагалась как инструмент для улучшения понимания требований. Для правильного использования этого инструмента Рон Джеффрис предложил 3 принципа:
- Карточка: история лаконично записывается на карточку, следуя шаблону: As a < define user > I want < descibe experience > so that < describe benefit >
- Разговор: разработчики, изучая карточку, общаются с Владельцем Продукта, для того чтобы получить знания о домене, изучить контекст, предложить идеи для реализации
- Подтверждение: для того, чтобы не забыть важные детали в процессе обсуждения, команда документирует договоренности
Первые два принципа довольно простые для понимания и обычно не вызывают вопросов как это должно работать. Третий принцип допускает самые разные варианты как документировать договоренности между Владельцем Продукта и командой разработчиков. Записывать договоренности в виде приемочных критериев является распространенной практикой, но знания и контекст не передаются таким же структурированным образом, поэтому здесь мы полагаемся на случай. Подтвердить только приемочные критерии достаточно для простых историй, но не для сложных.
Максим Гапонов, автор User Story Canvas, тщательно исследовал вопрос почему проработка требований сложных историй часто приводят к отрицательному результату, и указал на следующие причины:
- Описываем в виде историй все знания о продукте, даже если часть знаний ну просто не клеится как история;
- Не совсем понятно что в них включать;
- Делаем их общими — утрачиваем контроль;
- Делаем их детальными — занимаемся только их поддержкой;
- Пробелы в коммуникациях приводят к переделкам;
- Недостаток стандартного описания;
- Потеря фокуса в обсуждениях.
Знания о продукте
Для того чтобы описать сложную пользовательскую историю, нужно понять контекст продукта, получить необходимые знания о бизнес домене. Многие аспекты могут просто проходить мимо внимания разработчиков и, как результат, получаем пожелания от пользователей, которые требуют переделок. Для того чтобы исправить эту проблему, мы можем использовать User Story Canvas — усовершенствованный инструмент для описания пользовательских историй, который мотивирует подтверждать с Владельцем Продукта большее количество аспектов, чем просто приемочные критерии.
Заполнение User Story Canvas
Канва пользовательской истории имеет четкую структуру (см. рисунок сверху) и требует определенной очередности заполнения.
Блок коммуникаций: первые четыре шага называются блоком коммуникаций. Команда договаривается о категории конечных пользователей и, чем конкретнее категория, тем более сфокусировано пойдет дискуссия о других деталях. Владелец Продукта с командой идентифицируют конкретные имена экспертов бизнес домена, которые могут консультировать команду в процессе разработки, конкретные имена заказчиков и других заинтересованных лиц. Команда должна понимать по каким вопросам и с кем они могут общаться и уточнять требования, чтобы не делать Владельца Продукта узким местом в процессе. Владельцу Продукта такой анализ позволит определить возможных участников Обзора Спринта, заранее запланировать и подтвердить их участие на этой встрече.
Блок контекста: пятый и шестой шаг входит в блок контекста. Команда общается с Владельцем Продукта, чтобы понять и определить потребность пользователей, а также контекст потенциального использования новой функциональности. Договариваемся и записываем чем не устраивает пользователя его текущий опыт, чтобы далее осознанно работать над улучшением.
Блок пользовательской истории: седьмой, восьмой и девятый шаг заполняются как переход от проблемы к решению. Хорошо проработанный контекст поможет сформулировать именно ту историю, которая будет иметь положительное влияние на конечного пользователя. Далее этот опыт нужно описать в виде нескольких возможных решений со своими плюсами и минусами. например дешево и сердито, либо дорого и богато. И в конце этого блока прописать приемочные критерии.
Блок реализации: десятый, одиннадцатый и двенадцатый шаг добавляют всевозможные технические знания о продукте. Нужно обсудить и задокументировать технические ограничения с точки зрения архитектуры, интерфейсов интеграции, поддерживаемые технологии и хранение данных. Важно отметить, какое влияние эти ограничения будут иметь на производительность новой функциональности, скорость реализации и др. Далее нужно указать зависимости на третьи системы, в которые тоже нужно вносить изменения. Ну и использование данных пожалуй самый важный аспект. Какие изменения история может повлечь в существующие схемы данных, какие источники данных понадобятся, есть ли эти данные уже сейчас, это сырые данные или уже обработанные?
Блок ожидаемых результатов: Два последних шага посвящены теме обратной связи от пользователей. Считается что история успешно реализована когда удовлетворяет приемочным критериям от Владельца Продукта. Но это не совсем так: история на то и есть пользовательская, что собирать обратную связь нужно от пользователей. Нужно понять механизм как собирать сведения об использовании, возможно разработчикам следует интегрировать историю с Google Analytics или разработать свой механизм отслеживания реального использования новой функциональности.
Использование User Story Canvas
Участники последнего митапа, на котором мы разбирали этот инструмент, согласились что стрелять по воробьям из пушки не стоит. То есть, использовать данную канву нормально для достаточно больших и сложных историй. Полное название инструмента User Story Discussion Canvas подразумевает что инструмент будет использоваться для фасилитации процесса обсуждения пользовательских историй. На таких встречах следует начинать обсуждение с предварительной оценки размера и сложности истории, чтобы подобрать нужный инструмент для обсуждения.
User Story Discussion Canvas отлично впишется в процесс обсуждения сложных и больших историй. Большие, но не сложные истории (такое тоже бывает) возможно стоит сразу начинать с шаблонов разбивки или User Story Splitting Patterns. Бывает так, что реализация истории не объемная, но сложная и запутанная в ограничениях, зависимостях и ожиданиях. В этом случае Максим Гапонов рекомендует заполнять канву пользовательской истории частично, в тех областях, которые важно проговорить и задокументировать. Понятные и не большие по размеру истории, возможно, вообще не требуют комплексных инструментов для обсуждения и документации.
Онлайн фасилитация User Story Canvas
Фасилитация онлайн совещаний с использованием User Story Canvas проходит отлично. Для этого нужно:
- Подготовить доску в Mural или Miro. Канва в высоком разрешении доступна по ссылке;
- Начать встречу в Zoom с предварительной оценки истории по сложности и объему, чтобы убедиться, что User Story Canvas будет воспринят командой как полезный инструмент;
- Процесс состоит из пяти шагов по 10 минут. Для заполнения канвы вам понадобится от 30 до 90 минут, в зависимости от сложности истории;
- Для обсуждения каждого блока канвы, фасилитатор встречи выставляет время и открывает конференц-зал на 10 минут. По истечении времени закрывает зал, собирает обратную связь, отвечает на вопросы и вновь открывает зал на 10 минут для обсуждения следующего блока.
Выводы
Как и любой другой инструмент фасилитации, User Story Canvas имеет свое применение. Обсуждение сложных историй простыми инструментами приводит к утрате большого количества важных знаний и, как результат, получаем большое количество проблем с реализацией, доставкой, несоответствия ожиданиям и всевозможным конфликтам.
P.S. Полезные ресурсы:
Essential XP: Card, Conversation, Confirmation by Ron Jeffries
Start with design — Stanford d.school
Pragmatic Personas: Putting the User back in User Stories
INVEST in Good Stories, and SMART Tasks — XP123
Twenty Ways to Split Stories
Слава Москаленко, CEO Agile.Live