Pull to refresh
0
Фонд развития интернет-инициатив
Экспертиза и инвестиции для стартапов

Управление ретроспективой или взгляд в прошлое: Руководство Gov.uk

Reading time 9 min
Views 5.9K
Original author: Gov UK

Анализ работы команды и того, как она была проделана




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

Ретроспектива


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

Ретроспектива состоит из следующих этапов:

  1. сбор информации;
  2. генерация инсайтов;
  3. принятие решений о том, что делать дальше.

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

Ведущий (фасилитатор)

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



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

Ведущему необходимо:

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

Рабочие договоренности

Ретроспектива подразумевает некоторые рабочие договоренности. При необходимости они могут быть зафиксированы, например, в ходе первой ретроспективы вашей команды.

Суть рабочих договоренностей состоит в том что:

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

Результаты ретроспективы

Во время обсуждения вы сможете обсудить и свои успехи, и проблемы, которые вы можете устранить, а также то, что вы можете усовершенствовать.



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

Действия должны:

  • быть конкретными и соизмеримыми (например: «Написать еще 10 юнит-тестов для редиректора», или «Обсудить с Джейми вопрос организации ретроспективы всего проекта»; а не «Написать больше тестов» или «Осознать уроки, полученные на этом проекте»);
  • заканчиваться к определенному времени;
  • назначаться конкретному человеку (а не всей команде);
  • быть адресованы тем, кто присутствует на собрании.

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

Шаблон


Вы можете использовать шаблон для проведения ретроспективы. Этот шаблон подходит команде из 8-10 человек, работающей в рамках 2-х недельных спринтов.

Подходящая длительность собрания для такого количества участников и объема работ – 90 минут. Каждое из действий продолжается в течение установленного времени, следить за этим – работа вашего ведущего.

Выделите около 10% времени на то, чтобы переключаться с одного действия на другое и держать под контролем лимит времени.

Подготовка: от 00:00 до 00:05 (5 минут)

Объясните объем задач, и если это необходимо, цель собрания. Если участники команды не знакомы друг с другом, и/или смущаются, кратко представьте их.

Работа, выполненная по результатам предыдущей ретроспективы: от 00:05 до 00:10 (5 минут)

Убедитесь, что она завершена. Если нет, спросите:

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

Достижения: от 00:10 до 00:20 (10 минут)

Дайте вашей команде около 10 минут, чтобы записать все то хорошее, что было сделано за предыдущие 2 недели на клейких листках.

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

Не позволяйте дискуссии развиться на этом этапе – сейчас вы просто собираете информацию.

Обсуждение: от 00:20 до 00:30 (10 минут)

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

Обсудите каждую из выбранных тем по следующим направлениям:

  • Над чем мы продолжаем работать?
  • Почему эти задачи нам удались, и чему мы можем научиться?
  • Можем ли мы исходя из этого сделать что-то еще?

Провалы: от 00:30 до 00:45 (15 минут)

Дайте команде 15 минут, чтобы написать все то, что пошло не так.

Обсуждение: от 00:45 до 01:05 (20 минут)

Снова сгруппируйте стикеры, расположите их по приоритетам, если необходимо, и обсудите основные направления:

  • Можем ли мы понять, почему эти дела шли плохо?
  • Можем ли мы разобраться в том, что нам нужно сделать, чтобы улучшить ситуацию или предотвратить ее повторение?
  • Может ли кто-либо предложить конкретные действия, которые смогут помочь?



Действия: от 01:05 до 01:20 (15 минут)

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

Всего: 80 минут + 10% на переключение между задачами.

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

Почему это необходимо


Регулярные ретроспективы означают, что вы можете:

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

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

Дополнительное чтение


Эти ресурсы могут быть вам полезны:

  • «The Agile Retrospective Wiki» – содержит несколько очень полезных ресурсов, в том числе планы для различных типов ретроспектив.
  • Книга «Agile Retrospectives: Making Good Teams Great» Эстер Дерби (Esther Derby) и Дианы Ларсен (Diana Larsen)
  • «Getting Value out of Agile Retrospectives» – бесплатная электронная книга с множеством упражнений для проведения ретроспектив, отвечающая на вопросы «что это такое?» и «зачем это нужно?», описывающая бизнес-ценность и выгоды, которые они приносят, и включающая рекомендации по внедрению и совершенствованию проведения таких собраний.

Мы обсудили данный материал с рядом стартапов 4-го и 5-го наборов Акселератора ФРИИ и сотрудниками Акселератора:

Слава Архаров, трекер Акселератора ФРИИ:

Во время ретроспективной сессии всегда будет балаган, и зафасилитировать его почти невозможно. Поэтому не надо думать, что если вы жестко выделите 5 минут на сессию ретроспективы и 5 минут на обратную связь – то команда за 5 минут расскажет про свои проблемы, а потом слушатели по очереди и не перебивая выскажут свое мнение. Так не будет.

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

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

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

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

1. Используете ли вы методику обсуждения проделанной работы в формате ретроспективы или это излишняя трата времени?

Константин Масленников, CEO проекта takebus.ru
Есть вопросы (например, разработка особо важных функций на сайте или в приложении), которые мы обсуждаем в формате ретроспективы. Мы анализируем, чего хотели добиться и к чему пришли. Мы используем это при встрече с нашим ментором, и в ходе подготовки отчетных писем стейкхолдерам. Но используем этот подход применительно к ограниченному кругу вопросов, не более 3х (чаще 1) – поскольку анализ всех гипотез в ретроспективе занимает ужасно много времени.

Андрей Валиев, основатель и CTO проекта Моймеханик.рф
Да, мы проводим встречи в формате ретроспективы. По сути, это наши ежедневные планерки в ядре команды и еженедельные «расширенные встречи» с участием тех, кто вовлечен в проект менее интенсивно. Ядро команды – небольшая слаженная команда из 3-х человек, которая может позволить себе менее формально придерживаться регламента. Мы обсуждаем что сделано за день/неделю, делаем выводы о том, что было хорошо/плохо, формулируем план на неделю/следующий день. Выделенного фасилитатора нет, эту роль просто играет один из членов команды.

Андрей Шевелев, основатель проекта Турбазар.рф
Да, мы делаем тим митинг каждую неделю, анализируем метрики по результатам сделанного, планируем следующие действия.

Георгий Кожин, со-основатель и арт-директор проекта Kartadoma.ru
В своей работе мы стараемся использовать agile. Мы поняли, что для нас оптимальна недельная итерация, по итогам которой мы проводим ретроспективу. В недельный спринт мы укладываем как программерские задачи, так и продуктовые.

Анатолий Шарифулин, CEO проекта AppFollow.ru
Несмотря на то, что наша команда маленькая (3 человека), все равно происходит рассинхронизация, и без ретроспектив мы быстро бы пришли к хаосу. Каждую неделю обсуждаем, кто что сделал за неделю, какие результаты, если провалили сроки или не справились с задачей, то почему. Очень важно разбираться в фейлах и ошибках планирования, чтобы далее их не допускать.

2. Если вы используете такой подход: сколько времени традиционно занимает обсуждение? Ведете ли вы жесткий тайминг таких встреч? Может быть, у вас есть собственные приемы и «фишки» при организации ретроспективы?

Константин Масленников, CEO проекта takebus.ru
Жесткого тайминга именно ретроспективы нет, но есть тайминг встречи с ментором, большой частью которой является ретроспектива. Мы используем «стартовую колоду» где по листам расписаны все наши изначальные желания к продукту в разных разрезах (даже рисунки есть), мы потратили на ее составление пару дней, и иногда с улыбкой, иногда всерьез воспринимаем, что мы там понаписали, удивительно, что некоторые функции, которые мы там выдумывали (например, аналитика для перевозчиков), выглядели легко – но мы не реализовали этого до сих пор, а некоторые казались нам фантастикой (например, регистрация через социальные сети), а мы их уже реализовали.

Андрей Валиев, основатель и CTO проекта Моймеханик.рф
Это, наверное, не «фишки», но есть некоторые правила, которым мы стараемся следовать: разговор не по заданной теме – в конец обсуждения, если останется время; результат встречи должен звучать как перечень исполнимых задача (что/кто/когда); не брать на себя то, что можешь не успеть сделать. Лучше сделать то, что не обещал, дополнительно к тому, что обещал.

Андрей Шевелев, основатель проекта Турбазар.рф
Каждый член нашей команды имеет право высказать и отстаивать свое мнение по любому вопросу. Принято в команде формировать единогласное мнение по принимаемым решениям, но последнее слово всегда остается за CEO.

Георгий Кожин, со-основатель и арт-директор проекта Kartadoma.ru
Раньше у нас было 6 программистов и ретроспективы были особенно полезны, но занимали иногда по полдня, что очень расточительно. После такой длинной ретроспективы команда уже «наговорилась», общий тонус падает, и обсуждение проходит уже не так активно.

Потом количество программистов уменьшилось, и ретроспективы занимали всё меньше времени и сводились к короткому обсуждению некоторых проблем, с которыми команде пришлось столкнуться во время спринта. Такие обсуждения отнимали минут 15-20. В продуктовых же спринтах ретроспектива не утратила своей актуальности. Она помогает увеличивать эффективность и позволяет «бежать быстрее».

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

Анатолий Шарифулин, CEO проекта AppFollow.ru
Обычно каждому отводится 5-10 минут. Жесткого тайминга нет, сейчас он нам и не нужен. По опыту могу сказать, что в больших командах без жесткого тайминга никуда. Если митинг занимает больше часа, то это фейл и антипродуктивно.

Не могу сказать, что это моя собственная «фишка», но каждый день и/или каждые 2-4 часа я уточняю статус хода работ по задачам. Это занимает 1-2 минуты, но позволяет быстро реагировать на «вылетания» и корректировать ход выполнения задач. К счастью, мы работаем в неопределенности и не можем себе позволить слишком долго исследовать эту неопределенность. Нужно быстро двигаться, ошибаться, придумывать новые решения и идти дальше, иначе мы обречены на провал.

Наши публикации на основе материалов Gov.uk:

Tags:
Hubs:
+10
Comments 0
Comments Leave a comment

Articles

Information

Website
iidf.ru
Registered
Founded
2013
Employees
31–50 employees
Location
Россия