Любой, кто слышал о Scrum, скорее всего, слышал о его основных видах деятельности: планировании, пятиминутном стендапе, обзоре спринта и ретроспективе.
Многие слышали, что существует множество инструментов для проведения ретроспектив, и еще больше «обучающих» материалов, но как-то всё не получается.
Или вроде бы получается, но команда почему-то не хочет в этом участвовать.
В этой статье я представлю свой рецепт проведения ретроспективы, не только представив конкретные и подробные шаги, но и попытавшись объяснить, почему эти шаги именно такие и как они сформулированы.
Кто присутствует
Ретроспектива — это прежде всего внутреннее командное мероприятие.Его решения — это решения для самой команды, и они должны разрабатываться внутри компании.
Вполне допустимо привести на ретроспективу такие же две птицы , нецензурно выражаться (но не друг в друге!), приносить куклу большого начальника и/или покупателя.
Важно, чтобы каждый член команды чувствовал, что может высказать свое мнение, и это не только не приведет к какому-либо негативу, а как раз наоборот – оно будет использовано на благо коллектива.
Поэтому в ретроспективе должны присутствовать, с одной стороны, все члены команды, а с другой — никаких больших начальников, секретарей, представителей заказчика или соседних команд. Ретроспектива – это не отчет! Это не презентация! Это не представление, которое команда разыгрывает для клиента (в отличие от обзора спринта).
Это внутрикомандное мероприятие, которое, в принципе, иногда можно даже заменить тимбилдингом.
И возможно это будет даже полезнее ретро.
Очень желательно, чтобы на первых двух-трех ретро присутствовал профессиональный Скрам-мастер.
Причем не сертифицированный, а профессиональный, который не только прошел аттестацию и обучение, но и применил свои навыки проведения ретроспектив на практике не менее года.
Несмотря на кажущуюся простоту, событие очень легко скатывается «не в ту сторону», и по его результатам даже непонятно, почему и как это исправить.
В дальнейшем проведение (фасилитацию) ретро можно поручить члену команды, а через некоторое время для каждого нового ретро можно выбрать нового ведущего.
Когда
Ретроспективы следует проводить регулярно.В общем, все в Scrum нужно делать регулярно.
И планирование, и обзор, и ретро.
«Сила» методики именно в том, чтобы превратить непредсказуемый процесс творческого развития в предсказуемый и плановый.
Ретро следует делать после обзора спринта.
Чтобы на ретро команда могла обсудить в том числе и то, как результаты команды были представлены (успешно или нет) клиентам.
Ретро следует выполнить до планирования следующего спринта.
Во-первых, потому что планирование следующего спринта — это уже следующий спринт, а во-вторых, потому что результаты могут включать в себя какие-то задачи, которые команда поставит перед собой.
И им придется участвовать в следующем спринте.
Что нужно для ретро?
Если ретро проводится в «реальном мире», вам потребуются наклейки/листовки (6-10 штук на человека), ручки и доска с маркером.В «виртуальном» мире достаточно обойтись общим экраном с двумя/тремя блокнотами или одним экраном Confluence/MS Word с тремя полями.
Условно их теперь можно назвать «плюсы», «минусы» и «действия».
В целях геймификации можно использовать онлайн-инструменты типа веселого ретро/легкого ретро, но пока ни один из этих инструментов не подходит под тот рецепт, который будет описан ниже.
Будучи хорошим начальником (или планируя им стать) - принесите в ретро орехи, конфеты, печенье (*узнаваемое закадровое дыхание*), запланируйте общий обед с пиццей, не отрываясь от «производства».
Начало ретро
Вначале всем членам команды дается задание.Вам необходимо придумать и записать (пока в секрете от других членов команды — это важно): (+) Не менее N вещей, которые им понравились в текущем спринте и которые они не хотели бы потерять в процессе изменений, предложенных в рамках ретро.
(-) Больше не надо Есть N вещей, которые мне не нравятся и которые я хотел бы изменить.
Не нужно пытаться «оптимизировать» процесс и просить членов команды заранее записать эти пункты в качестве домашнего задания.
Им все равно придется потратить на это время, верно? Пусть потратят все сразу в одном месте, не терзаясь угрызениями совести за невыполненное домашнее задание и без смущающих взглядов коллег, которые так замечательно сделали это заранее (читай — за 5 минут до встречи, отвлекшись от какой-то скучной еженедельной работы).
встреча ).
Сначала о «плюсах».
Этот момент важен хотя бы для того, чтобы закрепить то, что команда сделала хорошо.
Хвалить себя тоже важно.
Наверное, это подтвердит любой психолог.
Нижняя граница здесь нужна для того, чтобы каждый член команды заставил себя, во-первых, вспомнить прошлый спринт, а, во-вторых, заняться ретроспективой.
«Мы не хотим проигрывать» — важный намек.
Например, она сразу набухает такие вещи, которые от команды не зависят. Нет смысла обсуждать возможность удаленной работы, если команда не решит этот вопрос.
Или имеет смысл упомянуть, насколько мне нравится текущий CI и быстрое прохождение обзора, потому что это (обычно) зависит от команды.
Еще одним важным назначением «+» очков является возможность позже, когда будут предложены точки действия для решения проблем, выбрать те, которые минимально повлияют на то, что команда не хочет потерять.
Важно, чтобы плюсы и минусы были записаны на листочках независимо друг от друга.
Таким образом, мы избавляемся от «проблемы +1», когда люди вместо того, чтобы думать о проблеме, просто присоединяются к чужому ответу (похожая ситуация возникает, например, при планировании, от чего защищает «слепое» покерное планирование).
Минусы.
В идеале вы хотите, чтобы участники сразу записали Что Мне тоже нравится.
Не точка действия, не то, что они предлагают сделать, а то, что напрямую мешает их работе.
Но в принципе для первых 4-6 ретроспектив участникам достаточно хоть что-то записать.
И тогда ведущий вытянет из них всю правду (*дьявольский смех за кадром*).
Здесь вполне можно и приемлемо написать что-то, что на первый взгляд кажется «внешним» для команды.
Потому что потом, при детальном анализе, может оказаться, что по внешней причине мы можем что-то подкорректировать в процессе внутри команды.
Анализ
Начнем с положительных моментов.Здесь их можно просто записать в первую колонку (наклеить стикерами), по возможности сгруппировав их для удобства наблюдения и красивого представления вышестоящим инстанциям.
Просто запомните пока, что эти преимущества — это то, что ваша команда хочет сохранить хотя бы на следующий спринт и не потерять при выполнении точек действий.
Минусы.
Самый сложный этап.
Игра в доктора наоборот. Берём каждую наклейку (товар, присланный нам в личных предложениях) и.
не записываем.
Давайте проверим, что описывает этот абзац симптом, а не болезнь .
Почему? Потому что тогда нам придется предложить решение, которое будет наиболее эффективным способом избавиться от симптома.
А «лечение» самой болезни может быть одним из, но не самым эффективным (по затратам и времени) способом.
Кроме того, у одного и того же симптома может быть несколько причин, и, возможно, потребуется устранить только одну из них, и это не та, которую первоначально определил член команды.
Снова.
Каждый пункт следует записать как симптом, а не болезнь (и уж точно не как пункт действия).
Например.
Член команды пишет на стикере " У нас неоптимальный CI-скрипт «Если оставить все как есть, то единственным возможным способом решения этой проблемы, очевидно, будет переписать CI-скрипт. Но нужно ли это? Давайте спросим члена команды: «[Олег], на что в вашей работе влияет тот факт, что CI-скрипт неоптимален»? Внезапно оказывается, что:
- сценарий медленный
- медленная работа приводит к медленным пул-реквестам
- невозможность распараллелить работу приводит к простоям
- это заставляет члена команды работать медленно
- невозможность распараллелить работу приводит к простоям
- медленная работа приводит к медленным пул-реквестам
- скрипт работает недетерминировано, иногда дает сбои из-за фазы Луны и положения Сатурна в созвездии Козерога
- это приводит к необходимости вручную перезапустить CI
- это заставляет члена команды работать медленно
- это приводит к необходимости вручную перезапустить CI
Но в любом случае каждый следующий шаг описывает более общую проблему.
В общем, все пункты так или иначе сводятся к одному конкретному — «замедлению работы команды».
Поэтому важно остановиться где-то на 1-2 пункта раньше.
Но для каждого следующего более общего уровня можно предлагать самые разные варианты решения задач:
- установить больше CI-агентов для сборки и распараллелить ее работу/построить/разрешить параллельную работу нескольких сборок одновременно
- создать более мощную машину для CI
- удалить некоторые действия из CI-скрипта, не переписывая его радикально
- полностью переписать сценарий CI
- научите пользователя переключаться между ветками в git, что позволит ему распараллеливать работу и не ждать CI
- создайте простой скрипт для перезапуска неудачных скриптов 2-3 раза
Но мы должны (по нашему опыту) как-то понимать, что именно та формулировка, которая будет записана, может, по крайней мере теоретически, быть решена несколькими разными способами.
И именно эту формулировку следует записать в «минусы».
Кроме того, более общая написанная формулировка имеет больше шансов пересечься с «минусом» другого участника.
И это хорошо — значит, у нас не 30 разных задач, а, скажем, 7-10 (сгруппированы).
Это то, к чему нам следует стремиться.
Очень важно, пытаясь вытянуть из члена команды более общую проблему, не перегружать его авторитетом и не ставить свою проблему на его место.
Все мы люди, все мы субъективны, и можем увидеть в чужой проблеме не то, что волнует члена команды, а то, что волнует нас самих.
Возможность оставить свои проблемы в стороне и выслушать (и услышать) другого человека — это, пожалуй, самое важное для того, кто собирается работать с людьми в ИТ.
Но это очень и очень сложно.
Ничего страшного, если сначала вас поправят и скажут: «нет, меня беспокоит не это, меня беспокоит что-то другое».
Замечательно, если они вам это скажут. Гораздо хуже, если с вами молча согласятся, чтобы не спорить и быстро закончить.
Голосование
Изначально мы считаем, что по каждому пункту было подано столько голосов, сколько изначально сгруппированных в него «минусов».Далее я предлагаю членам команды дополнительно проголосовать за 1 или 2 пункта (из сгруппированных 7-10), но только за те, которые не содержат пунктов, которые они сформулировали сами (или в которых были переформулированы их «минусы»).
В результате формируется список задач, отсортированный «по голосам».
Блиц-этап
На этом этапе включаем секундомер и предлагаем 60 секунд на решение каждой задачи, кроме Топ3 (в любом порядке).За эти 60 секунд вы сможете предложить «быстрое» решение проблемы.
Не важно, насколько это решает проблему, главное, что оно ее как-то решает. Если никто членов команды не против предложенного решения, это фиксируется в пунктах действия.
Если против, то решение немедленно отклоняется без обсуждения (время на обсуждение не тратится).
60 секунд — это скорее ориентир.
В том, что не нужно тратить много времени на блиц-задачи, которые не являются самыми болезненными участками процесса.
Перерыв на кофе
Перед кофе-брейком мы наконец формулируем топ-3 проблемы, которые необходимо обсудить, и приглашаем членов команды пойти покурить/выпить/выпить/сходить проверить почту.
Обсуждение.
Очки действия Итак, у нас есть топ-3 проблем.
Самый больной, самый серьезный, самый разрушительный для команды.
На каждую проблему есть минимум час обсуждения (поэтому ретро занимает от 3 часа).
Я не знаю, как придумать возможные решения.
Однако я знаю, что делать с возможными решениями.
Во-первых, не отбрасывайте решения, которые не решают проблему полностью.
Нас вполне устраивают решения, которые решают проблему хотя бы частично.
Хоть 20%, но они облегчают жизнь команде.
Кто знает, может быть, именно этих 20% будет достаточно, чтобы в следующий раз проблема не попала в топ-3? Во-вторых, решения должны быть проверены теми, чьи проблемы изначально были сгруппированы в один «пункт симптомов болезни».
Хотя бы один из них должен подтвердить, что предлагаемое решение действительно облегчит ему жизнь.
В-третьих, формулировка.
Формулировка должна быть такой, чтобы у команды был минимальный шанс не выполнить пункт.
| Плохой вариант | Лучший вариант |
| Нам нужно договориться о встрече и обсудить розовых единорогов.
| [Олег] организует встречу во вторник в 15:00, чтобы обсудить проблему кормления розовых единорогов.
|
| Относитесь к пул-реквестам ответственно.
| - (или) если запрос на включение отклонен, оставьте комментарий - (или) настроить бота, который назначает пиар на отзывы членам команды - (или) добавить в CI-скрипт автоматический линтер, и все проблемы проектирования, не охваченные им, не считаются проблемами |
| формулируйте билеты в jira заранее, прежде чем планировать | [Олег] начнет еженедельную очистку бэклога в Outlook перед планированием с участием владельца бэклога, представителя аналитиков и архитекторов решений смежных систем.
|
Почему ретро может не помочь
Может случиться так, что сделали все по рецепту, но свет в глазах команды становится все тускнеет, а продуктивность команды падает. Потому что автор этого текста ни черта не знает. Ретроспектива в данном случае позволяет найти некоторые из этих причин и задуматься, почему эти причины до сих пор не устранены.Признаками проблем являются:
- Ретроспектива состоится через полчаса.
Это не ретроспектива, это отчет коллектива «как все у нас хорошо, как мы живем здорово и дружно, дорогой дедушка Ленин».
Явный признак того, что мероприятие проводится для галочки, без той пользы, которую могло бы принести полноценное ретро.
- Подобные описания проблем повторялись в двух-трех ретроспективах.
Команда предполагает, что теоретически эти проблемы можно решить некоторыми действиями внутри команды.
Возможно, даже предлагает очки действия.
Но в какой-то момент эти проблемы просто исчезают из анализа, потому что команда уже привыкла к тому, что выражать их бесполезно.
Но сами проблемы никуда не делись!
- Если таких проблем много, то в какой-то момент появляются фразы «слишком много времени тратится на ретроспективы».
Это прямой сигнал, что задним числом все плохо.
И да, без изменения ретро-формата продолжать дальше нет смысла.
- Невыполненные пункты действий (хотя проблема не ушла).
Возможно, они были очень плохо сформулированы.
Или, возможно, тот, кто должен был их сделать, забыл/забыл/не захотел их делать.
Вы можете спокойно просмотреть красивые ретроспективные отчеты в слиянии, показать их начальству, но члены команды почему-то не хотят на них присутствовать.
Я рекомендую каждые полгода приглашать кого-нибудь со стороны на ретро-мероприятие.
Не начальник, а методист, коллега из параллельного (или дальнего) коллектива.
Можно даже пригласить его сразу в качестве ведущего — попробовать формат ретроспективы от другой команды.
Пусть его проводит тот, кто не привык к вашему формату.
Теги: #Управление проектами #Управление продуктами #agile #управление проектами и командой #scrum #ретроспектива
-
Скрытый Тигр:
19 Oct, 24 -
13-Й Подкаст Петербургской Группы Alt.net
19 Oct, 24 -
Случаи Неправильного Использования
19 Oct, 24 -
Факторы Социальной Реализации Пользователей
19 Oct, 24
