— Что является одним из самых мощных инструментов адаптации команды?
— Для того чтобы команда была эффективной и добивалась лучших результатов, необходимо время от времени думать о том, что можно делать лучше или хотя бы по другому, и не повторять ошибок.
Именно для этого, всем Agile-командам рекомендуется мощнейший инструмент адаптации — регулярная ретроспективная встреча. Причём, в отличие от «разбора полётов» в конце проекта, такую встречу необходимо проводить регулярно в течение всего срока проекта. Именно в периодичности и краткосрочности кроется секрет адаптации команды. Важно часто смотреть по сторонам и адаптироваться к изменениям окружения команды, чтобы оставаться гибким с точки зрения бизнеса и достижения целей, — и делать это как можно чаще.
— Практику командного самоанализа добавили в Scrum в виде обязательной встречи. Почему?
— Человек сам по себе «сложная система» и, когда группа людей объединяется в команду для достижения общих целей, — это ещё более сложная система, с учётом всех взаимоотношений и невидимых связей.
Получается, что мы строим сложные программные системы с помощью сложных человеческих систем. Говорить о какой-то определённости и предсказуемости в такой ситуации просто невозможно.
Для уменьшения сложности нам нужно как можно меньше правил. Среди немногих оставшихся в Scrum и других методах предписаний самое главное, на мой взгляд, — правило адаптации. Самоанализ или Ретроспективная встреча была добавлена в Scrum метод как механизм внутренней адаптации, который заменяет собой огромное количество других правил. Вы можете выбросить некоторые другие практики, кроме этой.
— Если нельзя всё предсказать заранее, то как избежать повторения ошибок?
— Если у вас есть толковые и мотивированные участники команды, то, регулярно общаясь, они могут договориться о том, как избежать повторения ошибок.
Не зря, последним из принципов Гибкой Разработки ПО (Agile Manifesto Principles, http://agilemanifesto.org/iso/ru/principles.html) была указана необходимость регулярно анализировать и корректировать стиль своей работы:
Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Именно в этом смысл гибкости: невозможно предсказать, зато можно адаптироваться и избежать повторения ошибок.
— Как полученный опыт может помочь в будущем?
— Ретроспектива, или «взгляд назад», — именно в анализе опыта через призму свершившихся событий можно найти крупицы мудрости и понимания того, как нужно делать правильно.
Каждый раз, планируя что-то или принимая какое-то решение, мы свято верим, что это решение самое правильное и наш план самый точный. Во всяком случае, на данный момент мы уверены в этом. Лишь спустя время мы эмпирически видим на собственном опыте, как реальность отличается от наших предположений.
Именно пересмотр своего опыта, анализ событий, трендов и их причин позволяет корректировать поведение команды и достигать лучших результатов. Даже плохие новости лучше узнавать раньше, когда ещё есть шанс что-то исправить.
— Что помогает добиться лучших результатов?
— Опыт может помочь в будущем, только если он качественно проанализирован. Поэтому лишь половина встречи должна быть посвящена сбору фактов и предположений — вопрос «что можно улучшить?». А вторая половина должна быть посвящена анализу первопричины (root cause) и выработке плана изменения поведения или конкретных действий по улучшению ситуации.
К сожалению, нередко начинающие Agile-команды усваивают практику Ретроспектив без понимания смысла и причин этой практики. В результате используют упрощённый формат Ретроспективы, который вычитали в книжке, статье, услышали на тренинге или подсмотрели у соседней команды.
Опасность такого подхода в том, что видимая часть практики Ретроспективы — это ещё не всё, что нужно для того, чтобы команда добилась лучших результатов. То, что ускользает от взгляда многих неопытных команд — это анализ причин озвученных проблем и выработка систематических решений. Этот опыт лежит в области здравого смысла и более глубокого понимания, зачем вообще делается та или иная практика.
— Расскажите вкратце об основных моментах ретроспективной встречи.
— Как я уже говорил выше, важно отделять практики и отдельные примеры проведения Ретроспективы от принципов и общей структуры, которые являются более универсальными. Так, например, начинающие Agile-команды узнают на ознакомительных тренингах или просто в книгах, что, мол, Ретроспективы — это простая практика. И что, мол, достаточно спросить, что было хорошо, что можно улучшить, и на этом Ретроспективу закончить.
В реальности это не так. Хорошую Ретроспективу можно условно разделить на несколько этапов:
-
Установите сцену (до 5% встречи) — тут фокус на обучении, безопасность участников, активное вовлечение всех;
-
Соберите данные (30-50%) — идёт вспоминание событий за прошедший период, сбор проблем, фактов и т. п.;
-
Сгенерируйте идеи (20-30%) — делается анализ собранных данных, выделение главного, поиск первопричин проблем;
-
Решите, что делать (15-20%) — вырабатывается чёткий план действий по устранению причин в виде конкретных задач, добавляются новые практики, которые стоит попробовать;
-
Закройте ретроспективу (10%) — подводятся итоги, даётся обратная связь по самой встрече, вносятся идеи о том, как следующую Ретроспективу сделать ещё лучше.
Соблюдение всех этих этапов гарантирует, что мы действительно сфокусированы на практическом изучении своего прикладного (эмпирического) опыта. Со временем опытные команды могут проводить эту встречу достаточно быстро, хотя для начинающих я бы рекомендовал не экономить на этой встрече и изучать приёмы для лучшего проведения каждого этапа.
— Какие бывают форматы проведения таких встреч?
— Как видите, описанная выше структура позволяет на каждом этапе применять разные практики. Поэтому сложно говорить об одном, пусть даже самом популярном, формате — его попросту нет.
Этому посвящён мой доклад на AgileDays: я привожу ряд практик, которые можно использовать на каждом этапе. Обладая даже минимальным набором практик, ведущий Ретроспективной встречи уже может сделать десятки комбинаций. Немаловажную роль играют фасилитационные (модераторские) навыки самого ведущего и максимальное вовлечение всех участников. Эта встреча должна быть интерактивной, а не очередным «собранием по поводу».
Чаще всего можно слышать о вопросах, которые помогают на этапе сбора данных: «что было хорошо», «что можно улучшить». Для команд, которые уже работают вместе некоторое время, это мощный инструмент. Для начинающих команд я бы вводил дополнительные вопросы или даже шаблонные структуры для сбора данных.
Опять же, сильно влияет период, за который проводится Ретроспектива, и, как результат, масштаб принятых решений.
— Ваши советы коллегам?
— Прежде всего, рекомендую помнить, что мы не делаем Agile, а стараемся быть Гибкими в наших решениях, в образе мыслей. В начале освоения Agile-стиля мышления нам, конечно же, нужны простые практики, с которых мы можем начать. И нет ничего страшного в том, чтобы первую Ретроспективу провести «по шаблону», который, например, можно услышать в моём рассказе. Можно даже использовать этот шаблон некоторое время, чтобы команда привыкла учиться.
И тогда должен наступить момент, когда сам процесс обучения становится важнее того, как именно вы это делаете. Вот тогда вы начнёте искать ещё варианты проведения того или иного этапа Ретроспективы. И, уверен, вы сможете придумать свои варианты, о которых с удовольствием послушают участники следующих конференций.
Будьте Гибкими! :-)
Беседовала Екатерина Кахраман
Тимофей Евграшин
Тимофей Евграшин — тренер и консультант по внедрению гибких методологий управления проектами Agile/Scrum в Ciklum Consulting , автор блога The Improved Methods . Более 12 лет создает и руководит командами по разработке программного обеспечения.