что такое ретро в agile
Как провести ретроспективу
Dec 10, 2018 · 3 min read
Эта статья является для меня шпаргалкой для проведения ретроспективы. Это вдохновитель и конструктор.
Ретроспектива спринта — это возможность для скрам-команды провести инспекцию, направленную на себя, и создать план улучшений командной работы в следующем спринте.
На выходе должно получиться не менее чем одно улучшение, которое, согласно последней редакции Scrumguide, мы берём задачей в следующий спринт.
Максимальная продолжительность Ретроспективы — 3 часа для Спринта длительностью один месяц.
Для двухнедельного спринта ретро будет занимать примерно 1,5 часа.
Не забыть, что на каждом из ретро нужно проинспектировать результаты с предыдущего ретро.
Шаг №1. Создание атмосферы
5% от всего времени. Здесь важно создать хорошее настроение и «включить» всех участников команды в работу.
Шаг №2. Сбор данных
40% от всего времени. Собираем данные о прошедшем спринте: цель, velocity, burndown.
Шаг №3. Генерация идей
30% от всего времени. Обязательно следите за временем и используйте таймер.
Шаг №4. Выбор решений
20 % от всего времени.
Шаг №5. Закрытие
5% от всего времени.
p.s. Рассказываю голосом про ретроспективы
Полезные ссылки
🤖 Сервис Retromat, который позволят посмотреть примеры на каждый из пяти шагов
🤖 Сервиc Fun Retrospectives c различными форматами для проведения ретроспектив
📺 Видео «Ретроспективы. Настраиваем наш процесс разработки» от Сергея Дмитриева CEO компании Unusial Concepts
📺 Видео «Эффективные ретроспективы», от Бориса Вольфсона директор по развитию в HH.ru
📖 Статья «Ретроспектива без бубна и танцев», от Ильи Павличенко сооснователя компании AgileX
📖 Статья «Как проводить крутые ретроспективы», от Ильи Павличенко сооснователя компании AgiliX
📖 Статья «Ретроспектива: как и зачем ее проводить?», от Ирины Цыбденовой экс-ScrumTrek
📖 Статья «Первая ретроспектива, от Романа Петрова Agile Coach в Сбербанке
Ретроспектива в Scrum — как проводить и зачем вообще ретроспектива нужна в Scrum?
Ретроспектива нужна, в первую очередь, для команды. И проводят её для достижения нескольких целей:
Найти «слабые места», обозначить недостатки в процессах работы команды
Запланировать улучшения по процессу
Не давать конфликтам внутри команды перерастать во что-то большее
Расслабиться и порефлексировать 🙂
Проводить рекомендуется в конце каждого спринта. Также можно проводить в конце проекта (обычно ретроспектива по всему проекту занимает целый день или даже больше, в зависимости от размера команды). А ещё лучше иногда проводить ретроспективу ретроспектив, чтобы понять, как можно улучшить само мероприятие.
Стандартно ретроспективу можно разбить на несколько этапов:
Открытие: напомнить команде, почему мы все сегодня собрались и как мы проведем выделенное под ретроспективу время
Проверка гипотез: обзор результатов запланированных улучшений с прошлой ретроспективы
Сбор данных: на этом этапе определяются основные несовершенства
Генерация идей: обсуждение путей улучшения процессов
Определение экспериментов: выбор конкретных мероприятий для следующего спринта, установка метрик для определения эффективности изменений и назначение ответственных за эти эксперименты
Закрытие: резюмируем идеи, кратко проводим ретроспективу спринта
Про ретроспективы и способы их проведения Марк Лоффлер написал крутую книгу «Ретроспектива в Agile». Мы прочитали сами и вам тоже советуем!
«Василий не сделал свою задачу, мы завалили спринт!»: как не повторить старые ошибки в новом проекте
Менеджер проектов в Techstack
Метод Scrum остается одним из самых популярных способов управления командой. Его используют 58% компаний, которые внедрили методологию Аgile (совокупность подходов гибкого менеджмента команд). А самая популярная и эффективная практика в Scrum – ретроспектива. Главное – знать, как ее правильно применять.
Команда Techstack внедрила практику ретроспективы после каждого спринта (короткого временного интервала, в течение которого Scrum- команда выполняет заданный объем работы. – Прим. ред.). Количество успешно выполненных задач на следующем этапе возросло на 30%. Мы стали адекватнее оценивать собственные возможности, лучше понимать сильные и слабые стороны, а еще научились слышать друг друга.
Немного Scrum-теории
Scrum как набор правил для управления разработкой продуктов программного обеспечения появился в 80-е годы прошлого столетия. Термин пришел из популярной американской игры регби. Там он описывает ситуацию, когда игроки наваливаются друг на друга и образуют плотную толпу.
Из спорта эта метафора перекочевала в IT-индустрию: разработка продуктов – тоже командная работа, которая без правильного управления рискует превратиться в полный хаос. Scrum и его инструменты не дают этому произойти.
За последние годы методология эволюционировала, менялась и адаптировалась к реалиям IT-рынка. Сегодня Scrum основывается на пяти базовых постулатах. Один из них – inspect and adapt («анализируй и улучшайся») – реализован в традиционной практике ретроспективы.
Как работает ретроспектива в Scrum
Руководство по Scrum описывает ретроспективу как регулярное собрание команды после каждого спринта для обсуждения удачных и провальных моментов. А также для определения конкретных действий, которые помогут устранить сложности предыдущего спринта, предотвратить возникновение новых и усилить слабые стороны.
Обычно в ретроспективе участвует Scrum-мастер и команда разработки. Но если вы хотите сохранять открытые и доверительные отношения с клиентом, то результатами можно поделиться с ним. Заодно обсудить, какие из пунктов улучшений находятся в его зоне влияния.
Почему команды не хотят участвовать в ретроспективах
Отчет State of Agile за 2020 год показал, что более 80% команд, работающих по методологии Agile, используют технику ретроспективы в своей работе. Казалось бы, если это такой популярный инструмент, то почему многие команды не находятся в процессе постоянного улучшения? И почему большинство разработчиков считают ретро очередным скучным собранием, отвлекающим от настоящей работы?
Причин тому несколько. Вот самые распространенные из них:
Все эти факторы могут отвратить команду от участия в ретроспективе. Чтобы этого не произошло, важно научиться использовать метод эффективно.
Как правильно внедрить метод ретроспективы: лайфхаки и советы
Вот пара фишек, которые помогут проводить ретроспективу так, чтобы она вызывала энтузиазм у команды и приносила пользу проекту.
Ретроспектива призвана улучшать процесс разработки. Но не забывайте, что собрание тоже можно преобразовать. Никто не дает более объективные советы по улучшению, чем сами участники мероприятия.
Небольшой совет: после каждого собрания можно спросить ребят из команды, как они оценивают прошедшее мероприятие, что бы хотелось изменить и почему.
Основная причина отсутствия активности и искренности на ретроспективах – недоверие. Зачем открываться, генерировать предложения по улучшению, если все равно ничего не изменится?
Запомните: задача Scrum-мастера – убирать препятствия в работе команды. У ребят появится вера, если активно внедрять улучшения, мониторить и контролировать, как их выполняют другие участники. Это действительно работает.
Личный опыт. На проекте собралась команда разработчиков, которая никогда не работала по методике Scrum. Ребят шокировало количество свалившихся на них собраний, каждое из которых они считали потерей времени.
Чтобы изменить сопротивление на принятие, я попросила озвучить хотя бы одну сложность, которая мешает работать. Оказалось, что требования к задачам спринта не всегда понятно описаны. И выясняется это, когда работа уже началась. В результате называют слишком оптимистичные сроки выполнения задачи, в которые команда не может уложиться.
Обсудив проблему, мы договорились, какие моменты прописать подробно. Когда требования стали более четкими, команда увидела, что времени на выяснение подробностей тратится меньше и больше остается на разработку. Уже на следующей встрече команда охотнее делилась идеями.
Коллективная ответственность зачастую значит, что она ничья. Проследите за тем, чтобы за всеми решениями был закреплен человек, ответственный за их выполнение. Уточняйте сроки, когда можно ждать готовый результат.
Если у вас команда инициативно сгенерировала большой список с улучшениями, не пытайтесь внедрить все сразу. Дайте ребятам возможность проголосовать за самые важные и возьмите в работу несколько из них.
Если какой-то формат проведения ретроспективы подходил и работал раньше, это еще не значит, что со временем он не утратит свою эффективность. Будьте готовы попробовать что-то новое.
Если формальные ретро утомили команду, добавьте немного геймификации: предложите команде представить, что вы летите на воздушном шаре, и что-то дает шару свободно лететь в небе, а что-то тянет его вниз. Попробуйте коллективно определить, что это может быть.
Личный опыт. В одной из команд мы использовали стикеры и доску для проведения ретро: каждый участник писал свои мысли на стикерах, мы клеили их в соответствующие колонки на доске, группировали и голосовали. Через пару спринтов стикеров становилось меньше, а по поведению ребят было видно, что они делают упражнение с меньшей охотой.
Перед очередным ретро я накупила печенюшек и отправила всех делать чай. Когда ребята вернулись, предложила поболтать на тему прошедшего спринта. Все идеи фиксировала в таблице. Мы распределили ответственных и установили сроки – все важные моменты остались. Новый формат беседы раскрыл мысли, которые невозможно было кратко сформулировать на стикере, и внес разнообразие в уже привычные встречи.
Люди приходят на ретроспективу, погруженные в свои рабочие задачи. Дайте им возможность переключиться и оказаться в текущем моменте. Для этого хорошо подходят короткие упражнения, которые позволят переключить мозг. Примеры, которые я использую со своими командами:
«Никто не знает, что я….» Каждый участник по очереди начинает с этой фразы и продолжает каким-то фактом о себе.
Сила и слабость. Каждый член команды (по желанию) называет свою сильную и/или слабую сторону.
Задача на логику. Попробуйте дать ребятам решить небольшую логическую задачку. Такая совместная работа не только переключит людей с их текущих задач, но и настроит на командный лад.
Комментарии в стиле: «Ох, было что-то плохое в этом спринте, но я уже не помню», – не помогают добиться улучшений. Приучайте себя и команду по ходу спринта делать пометки: что мы делаем удачно, или что произошло такого, чего не стоит больше делать, или идеи, как улучшить процесс. Тогда сама ретроспектива будет емкой, не займет много времени и даст измеримый результат.
Не ставьте процесс выше результата
Ретроспективы ваших команд станут полезными и действенными тогда, когда вы сами в них поверите и научитесь правильно пользоваться этим инструментом.
Помните, что все методологии – не догма. Это не процесс ради процесса, а средства для организации грамотного и эффективного управлении процессами разработки.
Задача хорошего менеджера и Scrum-мастера – знать весь арсенал инструментов, но использовать только те, что полезны и подходят конкретному проекту и команде.
Этот материал – не редакционный 
Это – личное мнение его автора. Редакция может не разделять это мнение.
Ретроспектива в Agile
Ретроспектива в Agile – метод, который помогает быстро найти эффективное решение возникших проблем. В своей книге ведущий agile-коуч Марк Лоффлер учит грамотно анализировать свои победы и поражения. Он объясняет, как применять на практике классические и инновационные инструменты ретроспектив, и приводит примеры, которые помогут вовремя заметить и исправить распространенные ошибки и затем получить ощутимые результаты. Эта книга будет полезна не только scrum-мастерам и руководителям проектов, но и тем, кто только начинает знакомство с Agile. На русском языке публикуется впервые.
Оглавление
Приведённый ознакомительный фрагмент книги Ретроспектива в Agile предоставлен нашим книжным партнёром — компанией ЛитРес.
Глава 1. Ретроспективы 101
Основная цель первой главы — познакомить вас с ретроспективами. Я расскажу, как их использовать в семейной жизни, покажу модель поэтапной организации процессов и дам несколько советов по наполнению этих этапов содержанием. В главе описано все необходимое для начала работы с первой ретроспективой. Итак, начнем.
Что такое ретроспектива
Ретроспектива (от лат. retrospectare) — это обзор, взгляд назад. Когда по ночам, лежа в постели, вы вспоминаете события минувшего дня — это ретроспектива. Если за семейным ужином дети рассказывают, как провели время в школе, а родители делятся впечатлениями о работе — это ретроспектива. Творчество художника, литератора или режиссера тоже можно рассматривать с точки зрения ретроспективы. Например, в рамках ретроспективных выставок демонстрируется целый ряд авторских работ, все важные произведения собраны в одном месте, чтобы дать полную картину творчества художника. Так можно получить общее впечатление и возможность сравнивать различные произведения искусства. Это было бы неосуществимо, имей мы доступ к одному-единственному примеру. Только получив целостное представление, можно оценить ситуацию и понять, почему художник поступил так, а не иначе.
Еще один вид ретроспективы есть на телевидении. В конце каждого года в рамках обзорных программ каналы конкурируют между собой, стремясь привлечь к участию в своих передачах самых веселых, красивых и известных людей. Но развлечение публики — приоритет для телевидения, и оно не слишком заботится о получении полной картины. Именно поэтому годовые «телеотчеты» довольно неоднородны и не позволяют делать выводы или рассматривать связи между различными событиями.
В этой книге словом «ретроспектива» я называю кое-что другое. Точно так же подразумевается взгляд в прошлое, но это только первый шаг. Задача — получить благодаря этому взгляду знания и понимание, которые помогут нам извлечь нужные уроки и правильно адаптироваться. Можно учиться как на успехах, так и на неудачах, а хорошее сделать еще лучше. Это сравнимо с эволюцией: то, что не сработало, вымирает, но все, способствующее сохранению видов, остается и развивается. В конце концов, каждая из таких адаптаций — не что иное, как эксперимент, потому что результат никогда точно не известен. В оптимальном случае эксперименты приводят к улучшению ситуации. Но иногда они только усугубляют ее, и это необходимо анализировать уже в следующей ретроспективе.
Каждую ретроспективу проводит фасилитатор. Он гарантирует, что группа достигнет поставленных целей, и помогает развивать практические результаты, которые станут основой для будущего успеха. Фасилитатор не является участником (правда, в небольших группах это правило не всегда соблюдается). Он сопровождает процесс, но не вовлекается в реализацию решений. Хороший фасилитатор необходим для успешной ретроспективы.
Ретроспектива — это ритуальное собрание сообщества в конце проекта для обзора событий и изучения опыта. Никто не знает всей истории проекта. У каждого человека есть часть истории. Ритуал ретроспективы — это коллективное рассказывание истории и добыча опыта для мудрости.
В своей книге Керт объясняет, чем ретроспективы отличаются от так называемых посмертных и извлеченных уроков. Главная разница в том, что ретроспективы фокусируются на будущих позитивных действиях и используют их в качестве катализатора изменений. Они представляют собой не конец проекта, а вехи в процессе постоянного совершенствования.
Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Этот принцип — одна из главных причин того, что agile-сообщество с энтузиазмом включило ретроспективы в свой рабочий процесс. Люди поняли: не обязательно ждать окончания проекта, чтобы узнать, что произошло, и внести нужные изменения. Достаточно проводить ретроспективу после каждой итерации (то есть определенного периода). Этот интервал не должен превышать одного месяца, иначе есть риск слишком растянуть цикл обратной связи.
Слово «итерация» происходит от латинского iterare, что означает «повторить». Итерации широко применяются там, где задачи решаются пошагово. В информатике итерация — это название процесса выполнения различных шагов до тех пор, пока не будет достигнуто требуемое условие (например, цикл FOR). В Scrum итерация называется «спринт».
Я использую термин «итерация» для описания процесса выполнения проекта в четко определенных, коротких, повторяющихся шагах. После каждой итерации вы останавливаетесь, чтобы определить, была ли и в какой степени реализована цель проекта, и при необходимости адаптируете исходный план. Цель — свести к минимуму риск неопределенности и неожиданностей. Та же процедура может использоваться в управлении изменениями.
Проведение ретроспектив позволяет наладить процесс непрерывного совершенствования, который постоянно проверяет, на правильном ли вы пути, а также дает возможность оперативно вмешаться и внести необходимые изменения. Выделив время для размышлений, вы сумеете решить проблему немедленно, не дожидаясь окончания процесса. Если не проводить ретроспективы до конца проекта, то вы рискуете к началу следующего забыть то, что узнали в текущем. Вы также получаете возможность реализовать улучшения в каждой итерации.
Суть agile-манифеста в следующем: мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь им непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:
• люди и взаимодействие важнее процессов и инструментов;
• работающий продукт важнее исчерпывающей документации;
• сотрудничество с заказчиком важнее согласования условий контракта;
• готовность к изменениям важнее следования первоначальному плану.
Иными словами, не отрицая важности того, что записано справа, мы все-таки больше ценим то, что слева.
Соответствующие 12 принципов выглядят так:
1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны трудиться мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение — наиболее практичный и эффективный способ обмена информацией как с самой командой, так и внутри нее.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
9. Непрерывное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Как видите, некоторые из принципов непосредственно нацелены на разработку программного обеспечения. Однако большинство можно легко применять и в других областях. Аgile-манифест основан на фундаментальной идее о том, что мы живем в сложном и непредсказуемом мире. Так что создание детального плана проекта на несколько лет или даже месяцев вперед не имеет смысла. Как известно большинству людей, которые когда-либо составляли план проекта, после очень короткого времени он лишь отдаленно соответствует реальности.
Agile-разработчики понимают эту ситуацию и стараются минимизировать ее эффект, используя короткие циклы обратной связи и тесно сотрудничая с заказчиком.
На основе agile-манифеста были разработаны различные структуры и процессы. Среди них XP, DSDM, Open UP и, конечно же, очень популярный сегодня Scrum. В то же время идеи agile-разработки программного обеспечения распространились и на другие сферы.
Например, в своей книге The Leader’s Guide to Radical Management Reinventing the Workplace for the 21st Century («Руководство лидера по радикальному управлению: переосмысление рабочего места в XXI веке») [4] Стивен Деннинг описывает применение идей agile-манифеста в области управления.
Ретроспектива новогодней ночи
Несколько лет назад мы с семьей придумали интересную традицию и назвали ее предновогодней ретроспективой. Она проходит очень весело и помогает скоротать время до полуночи (особенно с детьми). Выглядит это так: сначала мы вместе смотрим фотографии и несколько коротких видео (флешку с ними я готовлю заранее), которые сняли в течение года. Этот этап всегда сопровождается весельем и смехом.
Затем мы обсуждаем наши главные результаты и гипотезы за год. Это важно, потому что только так можно понять, имели ли решения, принятые в прошлом году, желаемый эффект. Если нет, то мы обсуждаем, остается ли тема актуальной, и выбираем новые действия. Перебрав гипотезы, начинаем вспоминать, что из прошлогодних событий особенно запомнилось. Мы используем три категории:
• что мне понравилось в прошедшем году;
• что совсем не понравилось (или разозлило);
• за что я хочу сказать спасибо.
Первая категория — это то, что развеселило или порадовало, например семейный отдых в киргизской юрте. Вторая включает в себя все негативные события, такие как «носки повсюду» или «раздражающие родители». Третья категория служит для того, чтобы сказать спасибо жене, маме, детям, братьям и так далее. Соединение благодарности с конкретной ситуацией очень важно. Например: «Спасибо, что позволили мне поиграть с вашими игрушками Skylander [5] » или «Спасибо, что каждое утро готовите мне легкий завтрак».
Пришло время получить знания и понимание. Каждому члену семьи разрешается выбрать наиболее важную для себя тему, и эти темы обсуждаются по очереди. Цель — найти причины, лежащие в основе данной проблемы. Для этого очень подходит метод «5 почему» (5-Why).
Следующий шаг — использовать причины, которые мы нашли, для создания конкретных, измеримых рекомендаций на будущий год. С этой целью проводится короткий мозговой штурм, чтобы собрать информацию о наших темах. Вы не поверите, но порой дети способны придумать что-то интересное даже в отношении совершенно взрослых проблем. Все предлагают свои идеи по каждой теме, и мы выбираем наиболее перспективные, отмечая их цветными точками напротив записей на бумаге. Эта техника называется «голосование точками». У каждого из нас есть три точки — наклейки, которые мы можем поставить напротив любой темы. По окончании мы помещаем только что выбранное решение на видном месте. У нас в доме это пробковая доска, где висят списки дел. Нет ничего хуже, чем когда результаты ретроспективы не видны. Доска помогает нам следить за новыми решениями и обеспечивать их реализацию. Важно отметить, что мы связываем каждое решение с проверяемой гипотезой, которую можем рассмотреть в следующей ретроспективе.
Конечно, ретроспективе нужен достойный финал. У нас в доме все заканчивается новогодним фейерверком.
Модель этапов ретроспективы
Если вы внимательно читали предыдущий раздел, то наверняка заметили, что в преддверии Нового года мы прошли шесть этапов, как показано на рис. 1.1.
Рис. 1.1. Шесть этапов ретроспективы
Первый этап должен определить условия. Он очень важен, потому что каждый участник должен успеть мысленно настроиться на проведение ретроспективы. Если вы пропустите этот шаг, то есть риск, что один или несколько человек «выключатся» из процесса, поскольку будут продолжать думать о своей текущей работе. Подготовка почвы нужна для вовлечения всех участников. Лучше всего начать с небольшого приветствия и поблагодарить всех за то, что пришли. Затем вы как фасилитатор кратко объясните причину и цель ретроспективы, а также ее длительность и агенду. Последнее важно, потому что, в конце концов, мы все хотим знать, на что тратим время.
Убедитесь, что все присутствующие действительно проявляют активность (кратких высказываний достаточно). Тот, кто молчит на этом этапе, вероятно, продолжит в том же духе в течение всего действия. Очень важно, чтобы каждый голос был услышан, иначе вы не получите полную картину. Участникам не обязательно рассказывать длинные истории, пусть каждый скажет несколько слов. Например, представится или кратко опишет свои ожидания от ретроспективы. Обычно такой подход полностью оправдывает себя, и даже самые молчаливые члены команды начинают действовать.
Вы создаете нужную атмосферу, устанавливая правила сотрудничества, или «рабочее соглашение». Некоторые команды уже определили ценности для своей повседневной работы. В этом случае ваша задача — просто напомнить о них и использовать эти ценности. Нет ничего хуже, чем когда потребуется адаптировать часть ценностей для ретроспективы. То же самое происходит, если команда уже определила правила сотрудничества. Многие agile-команды начинают работу именно с создания своего устава.
Устав определяет все правила работы в команде, включая общение и поведение, а также сроки и продолжительность регулярных встреч. У команд разработчиков программного обеспечения также есть список инструментов разработки, которые они используют, и, возможно, ссылки на дальнейшую информацию. Устав — это отправная точка для новых членов команды. Документ должен быть живым и разрабатываться итеративно. Если кто-то из участников утверждает, что устав следует скорректировать, команда обсуждает его предложение и после согласования вносит изменения.
Если у вас еще нет правил сотрудничества, то сейчас самое время их определить. Но почему они так важны?
Допустим, коллега Джеймс приносит на каждую встречу свой ноутбук. Он использует время собрания, чтобы просматривать электронную почту или сидеть в интернете. Начиная ретроспективу без четко установленных правил, вы тем самым невольно поощрите его действия. Джеймс будет раздражать всех, но в отсутствие регламентации невозможно попросить его закрыть ноутбук. Однако если правила определены заранее, их можно применить в любой момент. Еще одно преимущество общих правил сотрудничества состоит в том, что все участники несут ответственность за их соблюдение. Это позволяет фасилитатору сосредоточиться на проведении ретроспективы.
Если у команды нет устава, пригласите участников собраться сразу после ретроспективы, чтобы создать его.
К сожалению, этот этап чаще всего пропускают, потому что люди хотят сэкономить время и сразу начать работу. Но мой опыт подсказывает, что он никогда не был пустой затеей. Если члены команды давно работают вместе, то зачастую это занимает не более пяти минут, которые:
• минимизируют риск того, что кто-то станет упорно отмалчиваться;
• гарантируют, что каждый чувствует себя в безопасной рабочей атмосфере;
• объединяют участников и позволяют им выбросить из головы все лишнее ради этой важной встречи.
Иногда эти пять минут наполняются весельем. Например, вы можете спросить команду: «Если бы в результате последней итерации получился автомобиль, то что это за машина могла бы быть?» Достаточно пары ваших слов — и все вовлечены в работу.
Эта техника описана в книге Дерби и Ларсен [9] и реализуется после того, как вы поприветствовали участников и объяснили цель ретроспективы. Фасилитатор задает краткий вопрос, на который все участники отвечают по очереди и как можно быстрее. Вот несколько примеров:
• Определите одним-двумя словами, на что вы надеетесь в этой ретроспективе?
• Если бы в результате последней итерации получилась страна, то какая?
• Какую метафору погоды (солнечная, облачная, дождливая, грозовая) вы бы использовали, чтобы описать ваше настроение?
Участник может сказать: «Пас». Даже этого достаточно, чтобы его голос был услышан.
Напомним, что в предновогодней ретроспективе мы создали условия, посмотрев фотографии и видео за прошлый год. Поверьте, это было очень весело!
Цель этого этапа — обсуждение гипотез, сформулированных на последней ретроспективе. В идеале они создаются на основе выбранных экспериментов (см. раздел «Этап 5: определение экспериментов» ). Но почему этот шаг так важен?
Допустим, в ходе последней ретроспективы вы обсуждали проблему плохой коммуникации с командой управления продуктом. Менеджера продукта трудно застать, и ответы на вопросы удалось получить только после серьезных задержек. В конце последней ретроспективы вы определили меру, которую необходимо реализовать: менеджер продукта теперь будет доступен ежедневно в строго определенное время. На этот раз можно обсудить текущие вопросы и получить ответы, сократив тем самым задержки до минимума. Гипотеза, которую вы подключили к этому эксперименту, может быть такой: «На текущие вопросы ответы будут поступать максимум в течение суток». Это реальное улучшение по сравнению с недавней ситуацией, когда команде приходилось ждать по несколько недель.
После того как условия ретроспективы установлены, команда проверяет гипотезы. Оказывается, эксперимент был неправильным. Хотя время отклика сокращается, оно все же не дотягивает до 24-часовой отметки. Значит, тема остается. В ходе дальнейшей ретроспективы команда попытается определить причины проблемы, а затем либо адаптировать текущий эксперимент, либо определить новый. Например, в ходе процесса может выясниться, что с менеджером продукта не проконсультировались по поводу изменения, а лишь потребовали внедрить его. И вместо желания теснее работать с командой человек просто разозлился. Использование гипотез позволяет команде работать над проблемой до тех пор, пока она не будет решена или не снизится ее острота.
Если какая-либо из гипотез вопреки вашим ожиданиям не подтвердилась, используйте следующие этапы ретроспективы, чтобы выяснить почему.
Этот пример показывает, что гипотезы — важный инструмент. Некоторые команды просто проверяют, осуществлялись ли меры, выбранные в ходе предыдущей ретроспективы. И лишь немногие пытаются выяснить, имели ли они желаемый эффект. Хотя только в этом случае можно создать улучшение. Это, конечно, не панацея, но она эффективна в большинстве случаев. Гипотезы также помогают сделать ретроспективы значимыми и всерьез сосредоточиться на теме дискуссии.
Теперь мы переходим к сути слова «ретроспектива». Цель данного этапа — сбор данных за четко определенный период. Это может быть последняя итерация (или спринт в Scrum), весь проект или даже последний рабочий день. Время между рассматриваемым событием и ретроспективой должно быть максимально коротким. Главная цель этапа — сформировать общее понимание выбранного периода. Без целостной картины участники не всегда правильно понимают перспективу и друг друга, из-за чего склонны проецировать свои чувства на других. Чтобы создать общую картину, каждый получает возможность представить свой взгляд на вещи.
Вы начинаете со сбора реальных фактов. К ним относится все, что произошло за этот период: от встреч и решений до личного опыта. Важно и то, что считают для себя значительным члены команды. Числа (метрики) также можно указать на этом шаге, например количество выполненных требований или закрытых, открытых и новых ошибок. Чем больше моментов запомнится на этом этапе, тем лучше.
Конечно, можно просто поговорить об этом, но визуализация усилит впечатление. Она упрощает запись информации и незаменима при длительной ретроспективе. Один из примеров визуализации — это линия на стене, которая позволяет увидеть временные связи между событиями (рис. 1.2).
Рис. 1.2. Сбор данных при помощи линии времени
Хотя неопровержимые факты важны, они только часть истории. Не менее существенны мнения людей в данный момент времени, потому что они помогают выявить наиболее значительные события. Сбор фактов и мнений помогает сосредоточиться на проблемах, оказавших на команду максимальное влияние. В то же время эмоциональная окраска высказанных взглядов выявляет ситуации, когда люди чувствовали себя комфортно. А это дает вам возможность чаще воссоздавать подобную атмосферу. Еще одна причина обсуждения эмоциональных вопросов в том, что их часто упускают из виду. А ведь они могут стать источником энергии и мотивации в повседневной работе.
Только поговорив с командой, вы узнаете, что происходит, сумеете правильно подойти к решению проблем, устранить негативные ситуации и закрепить положительную динамику.
Используя этот термин в своей книге, я имею в виду любую профессиональную команду. Это могут быть группы разработчиков, HR-специалистов и так далее. Не составляют исключение и спортивные команды. Другими словами, это группа людей, работающих вместе для достижения общей цели.
Прежде чем перейти к следующему шагу, не забудьте рассмотреть с командой общую картину периода, который вы оцениваете. Это можно сделать, предоставив каждому возможность высказаться или дав людям время поразмыслить над информацией, которую вы собрали (например, при помощи линии времени).
Напомним, что в новогодней ретроспективе мы собрали данные, отсортировав события по трем категориям:
• что мне понравилось в прошедшем году;
• что совсем не понравилось (или разозлило);
• за что я хочу сказать спасибо.
Этап генерации идей используется для понимания ситуации, а также возможных причин и связей. Вы анализируете события, собранные на предыдущем этапе, а затем спрашиваете: «Почему это произошло?» Вам необходимо установить основные причины произошедшего.
Этот этап тоже часто пропускают, как и первый. Многие команды сразу же пытаются определить будущие эксперименты без учета возможных причин сложившейся ситуации. Это поверхностный подход: он снимет симптомы, а не выявит корень проблемы. От этого пользы не больше, чем от приема обезболивающих при переломе ноги. Боль исчезнет на короткое время, но очень быстро вернется, поскольку первопричина не устранена. Вред данной идеи в том, что она только выглядит многообещающей, а на самом деле пускает нас по ложному пути. Кроме того, выполнение этого этапа обеспечивает прочную основу для следующего — определения экспериментов и их гипотез. Не пытайтесь решать все проблемы сразу. Выбирайте те, которые группа считает наиболее важными. Невозможно справиться со всеми трудностями за одну ретроспективу. Этот этап разработан, чтобы помочь команде остановиться, увидеть картину в целом и начать искать первопричины. Не имеет смысла разрабатывать более трех тем во время следующей итерации, так как они наверняка будут не единственным вашим заданием, верно? Для определения разумных и эффективных мер необходимы знания, полученные на этом этапе.