Для команды разработчиков важно регулярно проводить ретроспективы для постоянного совершенствования.
Но что это должно быть? В течение нескольких лет мы использовали лишь некоторые стандартные методы работы с нашими ретро-автомобилями.
Другие не видели смысла, потому что был положительный результат: процессы улучшились, проблемы были решены.
В любом случае все было хорошо.
Не совсем:
- мы потратили 2 часа на ретро и очень устали
- дискуссии периодически перерастали в затяжные бесполезные споры
- какие-то мелкие проблемы не успевали решить и постоянно переносились на следующее ретро
- Некоторым членам команды ретроспективы наскучили из-за однообразия
Прошлой весной я пошёл в Окадемию из ScrumTrek. Это комплексный курс, включающий много полезной информации для Скрам-мастера, но для меня самой полезной была часть о том, как более эффективно проводить ретроспективы.
Я хочу рассказать вам, как это нам помогло.
Определитесь с правилами
Изначально у нас не было формальных правил.Мы просто собирались вместе, выражали проблемы и свободно обсуждали их, пока не пришли к решению.
Именно поэтому ретроспективы отнимали так много времени.
Выслушав всякое разное о ретроспективах на Окадемии, первое, что я предложил команде — разработать правила проведения ретроспектив, которые бы сократили время ненужных споров.
Большинство правил были предложены не мной, а другими членами команды.
Среди предложенных правил были как стандартные, так и такие, которые мне бы в голову не пришли:
- Ограничение по времени для ретро — час.
- Каждое ретро-занятие также ограничено по времени.
- Правило поднятой руки (стандартное): если хочешь перебить и что-то сказать, подними руку.
- Правило поднятой руки (расширенное): если во время вашей речи несколько человек поднимают руки, вы отклонились от темы и должны остановиться.
- Определите проблему: во время любого обсуждения необходимо четко обозначить проблему, чтобы не отклоняться от нее.
- Используйте парковку: если во время обсуждения всплывает важный вопрос, не связанный с текущей темой, запишите его на стикере и приклейте в специально отведенное место (парковку), чтобы обсудить позже.
- Посторонние находятся за дверью: если человеку позвонят или кто-то зайдет по срочному делу, нужно просто уйти, чтобы не мешать остальным членам коллектива.
- Все показывают большим пальцем:
- на,
- вниз – против,
- горизонтально - неважно.
- Если есть голоса «за» и нет голосов «против», правило принимается.
- Если голосов «за» нет, правило не принимается.
- Если есть голоса и за, и против, обсуждаем до тех пор, пока не придем к консенсусу.
Более того, мы стали использовать правило поднятой руки и за пределами ретро.
Через некоторое время команды разработчиков были реорганизованы и в состав новой команды вошли три человека, не участвовавшие в обсуждении этих правил.
Чтобы гарантировать, что все приняли правила, мы организовали то же обсуждение заново.
Как бы ни нравились выработанные совместно правила старым членам команды, не все из них были приняты новыми участниками.
Правило «протянутая рука поднята» пришлось отбросить, а стандартное правило больше не действовало — оно просто было не нужно в новой команде.
Прежде чем проводить ретроспективы, согласуйте правила со своей командой.
Важно, чтобы команда сама придумала и приняла эти правила (хотя некоторые правила может предложить и сам Скрам-мастер).
Если просто прийти с готовыми правилами, то возникнет эффект «придумано не здесь» — команда не примет эти правила близко к сердцу.
Любой новый член команды должен принять правила.
Если он не принимает ни одно из них, обсудите эти правила еще раз.
Если состав команды сильно меняется, обсудите правила с нуля.
Структура ретроспективы
Ретроспективу обычно делят на следующие этапы:- Открытие
- Сбор данных
- Генерация идей
- Выбор решений
- Закрытие
Определите, какие из них лучше всего подходят для вашей команды.
Некоторые без вопросов принимают любой ретро-формат. Некоторым важно понимать, зачем нужно то или иное мероприятие.
Если у вас есть люди второго типа, лучше всего объяснить цель каждого шага и действия.
Чтобы повысить вовлеченность команды, может быть полезно периодически менять виды деятельности.
Они помогают в этом ретроспективные карты .
Дополнительную информацию о различных мероприятиях для каждого этапа см.
Здесь .
Открытие
Этот этап нужен для вовлечения команды в работу.Для зрелых команд его обычно опускают — все уже без проблем участвуют в обсуждениях.
Поскольку у нас большой опыт проведения ретро-мероприятий, особой пользы от открытия не было.
Но если вы видите, что некоторые люди не участвуют в обсуждениях, возможно, вы просто упускаете возможность.
Сбор данных и ранжирование проблем
На этапе сбора данных необходимо выяснить, что вредит команде.Раньше мы всегда использовали для этого активность «Рад, Грусть, Безумие»: каждый участник пишет на стикерах, что его порадовало, расстроило или разозлило во время последнего спринта.
Эта деятельность хороша тем, что она предполагает эмоции (в отличие от простого разделения на положительные и отрицательные) и поэтому выполняет еще и роль открытия: она вовлекает в работу всех.
Также подобные занятия заставляют вспомнить не только проблемы, но и все положительные моменты, произошедшие во время спринта.
Это важно для укрепления эффективных практик.
Кроме того, то, что одни люди оценивают положительно, другие могут оценить отрицательно.
Важно обсудить такие различия в оценках.
Дополнительно во время спринта мы собирали задачи на специальной доске.
Это помогает не забыть о них ко времени ретро.
Это также дает возможность людям вне команды поделиться своей болью (чтобы обсудить такие стикеры, нужно позвонить их авторам).
Но в итоге у нас накопилось большое количество проблем, разобраться в которых не успели.
Здесь на помощь приходит рейтинг.
Не обсуждайте каждую проблему, о которой люди могут подумать.
Расположите их в порядке важности и обсуждайте только наиболее приоритетные.
Предварительно сгруппируйте похожие проблемы в кластеры.
Точечное голосование полезно для ранжирования:
- Каждый участник может поставить n точек (обычно 2-3) рядом с кластером с важными для него проблемами.
- Вы можете объединить все точки в один кластер или распределить их по разным
- Чем больше точек вы поставите рядом с кластером, тем выше его приоритет.
Их даже не нужно переносить в очередное ретро.
Если это важный вопрос, то его все равно запомнят. Если не помнят, то не стоит тратить на это время.
Генерация идей и выбор решений
После выбора важных проблем необходимо найти решения для каждой из них.Если существует несколько взаимоисключающих решений одной проблемы, то нужно выбрать наиболее подходящее.
Здесь также поможет точечное голосование.
Важно, чтобы все принимаемые решения были SMART:
- S – Конкретный – точный и конкретный
- M – Measurable – измеримый (должна быть возможность ответить на вопрос, помогло решение или нет)
- А – Достижимый – достижимый
- R – Relevant – актуальный (в пылу обсуждения не забывайте, какую проблему вы решаете)
- Т – Ограниченные по времени/рамочные – с ограниченным периодом реализации (желательно, чтобы они были завершены до следующего ретроспективного обновления)
- Доска действий - SMART решения
- Совет по решениям – решения, не имеющие ограничения по времени (всевозможные правила и изменения в процессе)
И это при том, что мы старались свести большинство решений к SMART. Невозможно запомнить такую кучу мелких решений.
Не каждый может даже вспомнить, что означает каждая из этих карт. Невозможно проверить, приносят ли эти решения пользу.
Можно сказать, что если по итогам обсуждения вы повесите карточку на Доску Решений, то время на обсуждение было потрачено зря.
Придумать SMART-решение для любой обсуждаемой проблемы сложно.
Нам это пока не всегда удается.
Однако я могу предложить несколько идей по улучшению в этом отношении:
- Оставьте себе только два варианта — либо вы приходите к SMART-решению, либо у вас нет решения проблемы.
Пока вы даете себе возможность принимать не-SMART-решения, вы их будете принимать.
Если вы используете доску решений, не используйте ее.
Совсем.
Полумеры здесь не работают.
- Обязательно выясните, как проверить, принесло ли ваше решение пользу.
Если вы не можете придумать количественный показатель, хотя бы спросите людей, стало ли дела лучше.
- Если решением является изменение ваших процессов, то в рамках SMART-решения вам необходимо закрепить новое правило, чтобы его трудно было забыть:
- измените физическую билетную доску, чтобы она отражала это правило,
- добавить его в систему отслеживания ошибок
- или напишите бота, который будет напоминать вам, когда вы отклоняетесь от нового процесса.
Через месяц оценим, помогло ли это.
Если не поможет, напишем бота, который будет нас ругать, если мы не оформим тикет.
Закрытие
Закрытие необходимо, в том числе, чтобы оценить, насколько хорошо прошло ретро, и понять, где его можно улучшить.Раньше мы не закрывались.
При этом я был уверен, что наша команда довольна нашим стандартным ретро-форматом и будет негативно реагировать на любые игровые активности.
Если бы мы не начали закрываться, я бы никогда не узнал, что некоторым членам команды наскучило это однообразие и они совсем не прочь попробовать какие-то новые занятия.
С тех пор, как мы начали делать закрытия, я получал полезные отзывы почти на каждом ретроспективе.
Скрам-мастеру нужна ретроспективная обратная связь не только для того, чтобы стать лучше, но и для того, чтобы избежать выгорания.
Помните, что вы не железные и вам хотя бы иногда нужна похвала за ваш трудолюбие.
Теги: #agile #ретроспектива #agile
-
Дорогие Курсы: Стоит Ли Оно Того?
19 Oct, 24 -
Странный Смс-Спам От Хостинг-Провайдера
19 Oct, 24 -
Полугодовой Солнечный Цикл Завершился.
19 Oct, 24 -
Форма Входа На Хабр
19 Oct, 24 -
Apple Исправила Важную Уязвимость В Icloud
19 Oct, 24
