Ретроспективы agile

Описание: ретроспектива — это взгляд в прошлое, чтобы сделать лучше в будущем. В технических и нетехнических командах можно ретроспектировать практически что угодно!

Agile-ретроспектива была изобретена в 2001 году одним росчерком пера. Последний из двенадцати принципов agile-разработки гласит:

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

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

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

Причина, по которой ретроспектива вызывает столько интереса, заключается в том, что именно сейчас начинается реальное активное испытание методологии agile. Многие ключевые концепции манифеста гибкой разработки укрепляются благодаря этим ретроспективным встречам. Обдумайте следующие ценности.

• Люди и взаимодействие важнее процессов и инструментов.

• Готовность к изменениям важнее следования плану.

Суть ретроспективы заключается именно в работе с реальными людьми для внесения изменений и улучшений. Мало что может лучше подкрепить принципы agile-разработки. Теперь, когда мы разобрались, почему ретроспектива так важна, ознакомьтесь с информацией о том, как самим организовать такое совещание.

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

Цель ретроспективного совещания заключается в следующем.

• Оценить, как прошел последний спринт, итерация или иная рабочая единица (это особенно важно в контексте динамики, процессов и инструментов команды).
• Сформулировать удачные и неудачные моменты и определить их приоритет.

• Составить и осуществить план по улучшению работы команды.

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

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

Хотя бывает полезно изменять формат ретроспективы (подробнее об этом ниже), некоторые аспекты, такие как хронометраж, участники и общая форма, должны по возможности оставаться неизменными.

Для agile-команд, работающих по традиционному двухнедельному спринту, ретроспектива должна проводиться в конце каждого спринта. Для команд, где рабочий процесс находится ближе к методу Kanban, более целесообразной может оказаться ежемесячная или ежеквартальная ретроспектива. После развертывания крупных инициатив полезно также привлекать к участию представителей вышестоящего руководства; старайтесь обсуждать не конечный продукт, а совместную работу команды над ним.

Выделите на это от тридцати минут до часа в зависимости от того, сколько длился спринт и какой объем работы нужно охватить в обсуждении.

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

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

1. Составьте короткий список того, что работало хорошо, и того, что можно улучшить. Этот список можно создать на магнитной доске, на странице Atlassian Confluence или даже на стене с помощью стикеров. Как бы вы ни зафиксировали этот первичный отзыв, обязательно сохраните его после собрания, чтобы на него можно было ссылаться в будущем.
2. Всей командой расставьте элементы этого списка по важности. Вы можете обнаружить общие темы, которые удобнее сгруппировать.
3. Обсудите способы и тактики для улучшения двух верхних элементов списка «Области для улучшения». Сосредоточьтесь на конечных результатах, а не на действиях, людях или прошлом.
4. Составьте план действий. К концу сеанса команда должна подготовить несколько практических идей по улучшению выбранных областей, для которых будут четко определены владельцы и сроки выполнения.
5. Будьте дисциплинированы в отношении выполнения пункта 4. Ничто так не разочаровывает, как постоянное обсуждение одних и тех же трудностей в каждой ретроспективе. Чтобы избежать бездействия (и разочарований!), убедитесь, что все участники возвращаются к работе, имея четкое представление о дальнейших действиях. Для каждой задачи плана, составленного во время ретроспективы, нужно назначить конкретного владельца, который доведет ее выполнение до конца.

Стандартизация ретроспективы — хорошая идея для постепенного укрепления стабильности и доверия в команде. Однако организаторы могут попробовать несколько приемов, чтобы сделать совещания информативнее, вовлечь новых участников команды или просто поддержать интерес.

Привлеките организатора со стороны. Обычно ретроспективу проводит Scrum-мастер или руководитель проекта, но вы можете пригласить гостя, который поможет провести следующую ретроспективу. Динамика может показать положительные изменения, если у человека, ведущего дискуссию, не будет личной заинтересованности. Более того, эта стратегия позволяет сотрудникам в организации понаблюдать за тем, как работают другие agile-команды, и позаимствовать полезный опыт для использования в своей команде.

Измените список подсказок. В конце концов, ретроспектива призвана выявить, что работает, а что нет. Можете использовать для подсказки следующие варианты.

• Начать/прекратить/продолжить: какие действия команде нужно начать выполнять, а какие — прекратить или продолжить. Сосредоточьтесь на том, как перестать выполнять элементы из столбца «Прекратить».
• Больше/меньше: что команда должна делать больше, а что — меньше. Создайте план по блокировке главных элементов из списка «Делать меньше».

• Радость/грусть/гнев: что заставляет участников команды радоваться, грустить или испытывать гнев. Как вы уже догадались, нужно сосредоточиться на списках «Грусть» и «Гнев» и том, как улучшить ситуацию, чтобы в следующий раз был заполнен только список «Радость».

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

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