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

Основной принцип 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. Используете ли вы методику обсуждения проделанной работы в формате ретроспективы или это излишняя трата времени?

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

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

• Работаем с User stories: Руководство Gov.uk
• Gov.uk: базовые аспекты методологии agile
• Проектирование продукта с ориентацией на пользователя

Автор: frii_fond

Источник