В этой статье мы поделимся с вами техникой Example Mapping для командной работы над спецификациями. Мы применили эту технику на Актуализации Бэклога Продукта (PBR) с продуктовой группой LeSS. Попробуйте и вы!
Об Example Mapping мы узнали из блога Мэтта Вина — автора тестового фреймворка Cucumber. Хотим отметить очевидные плюсы техники:
- добавляет структуру в обсуждение элементов Бэклога Продукта;
- помогает найти пробелы в знаниях;
- позволяет создать первоначальную версию приёмочных тестов сразу на PBR.
Мы уже писали о важности эффективного проведения Акутуализации Бэклога Продукта (PBR) в статье Эффективный PBR часть I. Статья, которую вы сейчас читаете, детально раскрывает технику Example Mapping.
Example Mapping для PBR
“Организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникации в этой организации”
— Мэлвин Конвей
Следуя закону Конвея, мы не хотим чтобы команды были ограничены выбором в принятии решений по дизайну разрабатываемых систем из-за неэффективной коммуникации. Поэтому одно и правил LeSS звучит как:
- Каждая команда – это самоуправляемая, кросс-функциональная, колоцированная, и долгоживущая структурная единица.
Наилучший способ взаимодействия в такой команде — это собрать всех необходимых людей в одном месте и обменяться имеющимися знаниями.
На встречу были приглашены 5 команд из продуктовой группы LeSS, стейкхолдеры из смежных подразделений, которые выступали главными заказчиками функциональности и, конечно же, Владелец Продукта.
Наша цель заключалась в том, чтобы детально проработать TOP-5 элементов Бэклога Продукта.
Порядок действий был следующий:
1. Обозначили 5 хранителей знаний (экспертов) на каждому из выбранных элементов. Эти люди оставались на станциях все время.
2. Образовали смешанные группы из 5 команд, которые присоединились к экспертам.
3. Мы подготовили вымышленный пример фичи “Предотвращение нелегального использования топливной карты” и обучили группы технике Example Mapping
И объяснили цветовое обозначение для стикеров:
- История — описание элемента Бэклога Продукта
- Правило — это один из критериев по которому мы поймем что фича реализована как задумывалась, иначе говоря голубые стикеры — это критерии приёмки фичи
- Пример — конкретный пример описывающий правило, Действие => Результат
- Вопрос — если на текущий момент в группе возникает вопрос, на который группа не может в таком составе ответить, вопрос пишется на розовый стикер для дальнейшего прояснения
Обратите внимание на то, что использование разных цветов стикеров необходимо для визуального отображения количества тех или иных элементов на флипчарте. Снабдите каждую команду стикерами нужных цветов.
4. Запустили World Cafè — фасилитационный формат, где есть “хозяин” станции, в нашем случае им являлся эксперт, к которому присоединились группы участников. Группы работали на станциях: проясняли требования и наполняли флипчарт, используя Example Mapping.
По истечении времени группа переходила на следующую станцию и работала там с другим экспертом. И так продолжалось до тех пор пока все группы не побывали на всех станциях.
5. После того как все группы побывали на всех станциях произошла презентация результатов работы.
Что у нас получилось:
- Обратили внимание, что на одной из станции образуется большое количество вопросов. Оказалось, что много информации уже было написано в базе знаний, но прошло порядочно времени. Знания забылись. Мы нашли ноутбук, залезли в БЗ и выгрузили ключевые моменты на стикеры.
- Большое количество голубых стикеров — сигнал к тому что эта фича большая. Хорошая новость! Ее можно разбить прямо по правилам!
- Все 5 команд продуктовой группы познакомились в равной степени с каждым элементом Бэклога Продукта (PBI), а значит каждая команда сможет взять любой из них на Планировании Спринта.
- Правила, описанные на зелёных стикерах, уже в первый же день работы в Спринте могут использоваться для автоматизации приемочного тестирования. Более того, подход test-first теперь становится неизбежным 🙂
Попробуйте и Example Mapping! Будем рады услышать от вас идеи, ваши находки и улучшения 🙂
Напоминаем, что 14-16 октября у нас состоится первый тренинг Professional Scrum Developer (PSD) на русском языке — лучший тренинг для Скрам-команд, которые создают реальное программное обеспечение. На тренинге мы подробно разберём тему PBR, а также другие темы эффективной работы.
Читайте и другие наши посты про PBR в нашем блоге: Эффективный PBR часть I и Мультикомандное уточнение Бэклога Продукта
