Читать книгу Ретроспектива в Agile - Марк Лоффлер - Страница 8

Если вы внимательно читали предыдущий раздел, то наверняка заметили, что в преддверии Нового года мы прошли шесть этапов, как показано на рис. 1.1.

Рис. 1.1. Шесть этапов ретроспективы

Они образуют структуру ретроспективы и основаны на оригинальной модели этапов Эстер Дерби и Дианы Ларсен[7]. То, что описано в этой книге, – расширенная форма идеи этих авторов: я ввел шаг «Проверка гипотез» и развил этап «Определение экспериментов», включив в него гипотезы. Причины я объясняю в этой книге. В следующих разделах подробно описаны все шесть этапов.

ЭТАП 1: ОТКРЫТИЕ

Первый этап должен определить условия. Он очень важен, потому что каждый участник должен успеть мысленно настроиться на проведение ретроспективы. Если вы пропустите этот шаг, то есть риск, что один или несколько человек «выключатся» из процесса, поскольку будут продолжать думать о своей текущей работе. Подготовка почвы нужна для вовлечения всех участников. Лучше всего начать с небольшого приветствия и поблагодарить всех за то, что пришли. Затем вы как фасилитатор кратко объясните причину и цель ретроспективы, а также ее длительность и агенду. Последнее важно, потому что, в конце концов, мы все хотим знать, на что тратим время.

ПРАКТИЧЕСКИЙ СОВЕТ

Убедитесь, что все присутствующие действительно проявляют активность (кратких высказываний достаточно). Тот, кто молчит на этом этапе, вероятно, продолжит в том же духе в течение всего действия. Очень важно, чтобы каждый голос был услышан, иначе вы не получите полную картину. Участникам не обязательно рассказывать длинные истории, пусть каждый скажет несколько слов. Например, представится или кратко опишет свои ожидания от ретроспективы. Обычно такой подход полностью оправдывает себя, и даже самые молчаливые члены команды начинают действовать.

Последний шаг первого этапа также очень важен. Его цель – создать атмосферу, в которой можно рассматривать непростые вопросы. Только в этом случае есть надежда докопаться до сути и устранить реальные причины проблем. Более того, это основа для успешной ретроспективы. «Что происходит в Вегасе, остается в Вегасе»[8].

Вы создаете нужную атмосферу, устанавливая правила сотрудничества, или «рабочее соглашение». Некоторые команды уже определили ценности для своей повседневной работы. В этом случае ваша задача – просто напомнить о них и использовать эти ценности. Нет ничего хуже, чем когда потребуется адаптировать часть ценностей для ретроспективы. То же самое происходит, если команда уже определила правила сотрудничества. Многие agile-команды начинают работу именно с создания своего устава.

ЧТО ТАКОЕ УСТАВ КОМАНДЫ

Устав определяет все правила работы в команде, включая общение и поведение, а также сроки и продолжительность регулярных встреч. У команд разработчиков программного обеспечения также есть список инструментов разработки, которые они используют, и, возможно, ссылки на дальнейшую информацию. Устав – это отправная точка для новых членов команды. Документ должен быть живым и разрабатываться итеративно. Если кто-то из участников утверждает, что устав следует скорректировать, команда обсуждает его предложение и после согласования вносит изменения.

Если у вас еще нет правил сотрудничества, то сейчас самое время их определить. Но почему они так важны?

Допустим, коллега Джеймс приносит на каждую встречу свой ноутбук. Он использует время собрания, чтобы просматривать электронную почту или сидеть в интернете. Начиная ретроспективу без четко установленных правил, вы тем самым невольно поощрите его действия. Джеймс будет раздражать всех, но в отсутствие регламентации невозможно попросить его закрыть ноутбук. Однако если правила определены заранее, их можно применить в любой момент. Еще одно преимущество общих правил сотрудничества состоит в том, что все участники несут ответственность за их соблюдение. Это позволяет фасилитатору сосредоточиться на проведении ретроспективы.

ПРАКТИЧЕСКИЙ СОВЕТ

Если у команды нет устава, пригласите участников собраться сразу после ретроспективы, чтобы создать его.

К сожалению, этот этап чаще всего пропускают, потому что люди хотят сэкономить время и сразу начать работу. Но мой опыт подсказывает, что он никогда не был пустой затеей. Если члены команды давно работают вместе, то зачастую это занимает не более пяти минут, которые:

• минимизируют риск того, что кто-то станет упорно отмалчиваться;

• гарантируют, что каждый чувствует себя в безопасной рабочей атмосфере;

• объединяют участников и позволяют им выбросить из головы все лишнее ради этой важной встречи.

Иногда эти пять минут наполняются весельем. Например, вы можете спросить команду: «Если бы в результате последней итерации получился автомобиль, то что это за машина могла бы быть?» Достаточно пары ваших слов – и все вовлечены в работу.

РЕГИСТРАЦИЯ (CHECK-IN)

Эта техника описана в книге Дерби и Ларсен[9] и реализуется после того, как вы поприветствовали участников и объяснили цель ретроспективы. Фасилитатор задает краткий вопрос, на который все участники отвечают по очереди и как можно быстрее. Вот несколько примеров:

• Определите одним-двумя словами, на что вы надеетесь в этой ретроспективе?

• Если бы в результате последней итерации получилась страна, то какая?

• Какую метафору погоды (солнечная, облачная, дождливая, грозовая) вы бы использовали, чтобы описать ваше настроение?

Участник может сказать: «Пас». Даже этого достаточно, чтобы его голос был услышан.

Напомним, что в предновогодней ретроспективе мы создали условия, посмотрев фотографии и видео за прошлый год. Поверьте, это было очень весело!

ЭТАП 2: ПРОВЕРКА ГИПОТЕЗ

Цель этого этапа – обсуждение гипотез, сформулированных на последней ретроспективе. В идеале они создаются на основе выбранных экспериментов (см. раздел «Этап 5: определение экспериментов»). Но почему этот шаг так важен?

Допустим, в ходе последней ретроспективы вы обсуждали проблему плохой коммуникации с командой управления продуктом. Менеджера продукта трудно застать, и ответы на вопросы удалось получить только после серьезных задержек. В конце последней ретроспективы вы определили меру, которую необходимо реализовать: менеджер продукта теперь будет доступен ежедневно в строго определенное время. На этот раз можно обсудить текущие вопросы и получить ответы, сократив тем самым задержки до минимума. Гипотеза, которую вы подключили к этому эксперименту, может быть такой: «На текущие вопросы ответы будут поступать максимум в течение суток». Это реальное улучшение по сравнению с недавней ситуацией, когда команде приходилось ждать по несколько недель.

После того как условия ретроспективы установлены, команда проверяет гипотезы. Оказывается, эксперимент был неправильным. Хотя время отклика сокращается, оно все же не дотягивает до 24-часовой отметки. Значит, тема остается. В ходе дальнейшей ретроспективы команда попытается определить причины проблемы, а затем либо адаптировать текущий эксперимент, либо определить новый. Например, в ходе процесса может выясниться, что с менеджером продукта не проконсультировались по поводу изменения, а лишь потребовали внедрить его. И вместо желания теснее работать с командой человек просто разозлился. Использование гипотез позволяет команде работать над проблемой до тех пор, пока она не будет решена или не снизится ее острота.

ПРАКТИЧЕСКИЙ СОВЕТ

Если какая-либо из гипотез вопреки вашим ожиданиям не подтвердилась, используйте следующие этапы ретроспективы, чтобы выяснить почему.

Этот пример показывает, что гипотезы – важный инструмент. Некоторые команды просто проверяют, осуществлялись ли меры, выбранные в ходе предыдущей ретроспективы. И лишь немногие пытаются выяснить, имели ли они желаемый эффект. Хотя только в этом случае можно создать улучшение. Это, конечно, не панацея, но она эффективна в большинстве случаев. Гипотезы также помогают сделать ретроспективы значимыми и всерьез сосредоточиться на теме дискуссии.

ЭТАП 3: СБОР ДАННЫХ

Теперь мы переходим к сути слова «ретроспектива». Цель данного этапа – сбор данных за четко определенный период. Это может быть последняя итерация (или спринт в Scrum), весь проект или даже последний рабочий день. Время между рассматриваемым событием и ретроспективой должно быть максимально коротким. Главная цель этапа – сформировать общее понимание выбранного периода. Без целостной картины участники не всегда правильно понимают перспективу и друг друга, из-за чего склонны проецировать свои чувства на других. Чтобы создать общую картину, каждый получает возможность представить свой взгляд на вещи.

Вы начинаете со сбора реальных фактов. К ним относится все, что произошло за этот период: от встреч и решений до личного опыта. Важно и то, что считают для себя значительным члены команды. Числа (метрики) также можно указать на этом шаге, например количество выполненных требований или закрытых, открытых и новых ошибок. Чем больше моментов запомнится на этом этапе, тем лучше.

Конечно, можно просто поговорить об этом, но визуализация усилит впечатление. Она упрощает запись информации и незаменима при длительной ретроспективе. Один из примеров визуализации – это линия на стене, которая позволяет увидеть временные связи между событиями (рис. 1.2).

Рис. 1.2. Сбор данных при помощи линии времени

Хотя неопровержимые факты важны, они только часть истории. Не менее существенны мнения людей в данный момент времени, потому что они помогают выявить наиболее значительные события. Сбор фактов и мнений помогает сосредоточиться на проблемах, оказавших на команду максимальное влияние. В то же время эмоциональная окраска высказанных взглядов выявляет ситуации, когда люди чувствовали себя комфортно. А это дает вам возможность чаще воссоздавать подобную атмосферу. Еще одна причина обсуждения эмоциональных вопросов в том, что их часто упускают из виду. А ведь они могут стать источником энергии и мотивации в повседневной работе.

Только поговорив с командой, вы узнаете, что происходит, сумеете правильно подойти к решению проблем, устранить негативные ситуации и закрепить положительную динамику.

ОПРЕДЕЛЕНИЕ ТЕРМИНА «КОМАНДА»

Используя этот термин в своей книге, я имею в виду любую профессиональную команду. Это могут быть группы разработчиков, HR-специалистов и так далее. Не составляют исключение и спортивные команды. Другими словами, это группа людей, работающих вместе для достижения общей цели.

Прежде чем перейти к следующему шагу, не забудьте рассмотреть с командой общую картину периода, который вы оцениваете. Это можно сделать, предоставив каждому возможность высказаться или дав людям время поразмыслить над информацией, которую вы собрали (например, при помощи линии времени).

Напомним, что в новогодней ретроспективе мы собрали данные, отсортировав события по трем категориям:

• что мне понравилось в прошедшем году;

• что совсем не понравилось (или разозлило);

• за что я хочу сказать спасибо.

Затем каждый кратко представил выбранную тему. Используя эмоциональные вопросы, мы старались получить комбинацию фактов и чувств. Опыт подсказывает, что этот этап ретроспективы должен часто меняться. Я расскажу о возможных вариантах в этой книге. Но если вам не хочется ждать, загляните в раздел «Поиск мероприятий для каждого этапа».

ЭТАП 4: ГЕНЕРАЦИЯ ИДЕЙ

Этап генерации идей используется для понимания ситуации, а также возможных причин и связей. Вы анализируете события, собранные на предыдущем этапе, а затем спрашиваете: «Почему это произошло?» Вам необходимо установить основные причины произошедшего.

Этот этап тоже часто пропускают, как и первый. Многие команды сразу же пытаются определить будущие эксперименты без учета возможных причин сложившейся ситуации. Это поверхностный подход: он снимет симптомы, а не выявит корень проблемы. От этого пользы не больше, чем от приема обезболивающих при переломе ноги. Боль исчезнет на короткое время, но очень быстро вернется, поскольку первопричина не устранена. Вред данной идеи в том, что она только выглядит многообещающей, а на самом деле пускает нас по ложному пути. Кроме того, выполнение этого этапа обеспечивает прочную основу для следующего – определения экспериментов и их гипотез. Не пытайтесь решать все проблемы сразу. Выбирайте те, которые группа считает наиболее важными. Невозможно справиться со всеми трудностями за одну ретроспективу. Этот этап разработан, чтобы помочь команде остановиться, увидеть картину в целом и начать искать первопричины. Не имеет смысла разрабатывать более трех тем во время следующей итерации, так как они наверняка будут не единственным вашим заданием, верно? Для определения разумных и эффективных мер необходимы знания, полученные на этом этапе.