Для чего нужна ретроспектива
Ретроспектива: что это значит и когда употребляется
Здравствуйте, уважаемые читатели блога KtoNaNovenkogo.ru. Маркетинг нередко заставляет человека жить моментом, задуматься о качестве жизни или о дальнейших перспективах. Однако существенную роль в построении будущего играет изучение прошлого.
Именно поэтому так важна ретроспектива, часто используемая в различных отраслях – от искусства до науки.
Что такое ретроспектива и как она работает
Термин сформировался в рамках латинского языка и дошел до современности практически в неизменном виде. Слово образовалось путем соединения двух понятийных маркеров:
Когда к полученной форме добавился суффикс «-tivo», используемый для указания на активные/пассивные отношения, появилось понятие retrospectivus, что буквально означает «смотрящий назад». Эта непосредственная коннотация сохранилась и в русском языке, поэтому в большинстве наших толковых словарей этому слову дается довольно простое определение:
ретроспектива – это своеобразный анализ, обзор прошлых достижений, обращенность к прошлому (ретроспекция) с целью извлечь уроки, обнаружить логическую цепочку, связывающую те или иные события.
Википедия при этом уточняет, что ретроспектива в искусстве означает демонстрацию произведений какой-либо творческой личности (художника, режиссера и т.п.) по принципу хронологической последовательности их создания.
Говоря упрощенно, любая ретроспекция – это своего рода исследование, последовательный разбор ранее имевших место явлений и/или событий.
Ну и нельзя забывать про рефлексию, ключевую черту достойного и самокритичного человека – успешного ученого, талантливого художника, неординарного писателя.
Умение анализировать ошибки, компилировать и воспроизводить достижения ценилось в любые времена, поэтому ретроспектива находит себе применение практически повсюду:
Целые жанры выстраиваются вокруг попыток изучить пройденный путь! Это не всегда интересно, зато помогает отточить навыки, раскрывает ранее не очевидные связи.
Ретроспективный анализ
Человечество не способно увидеть будущее в хрустальном шаре, но предсказать его с помощью учебника истории – по силам даже дилетанту. В зависимости от поставленных задач и научной дисциплины специалисты применяют особый ретроспективный метод исследования данных:
Благодаря ретроспективному методу, ученые на основе текущей ситуации постепенно разматывают клубок истории. Обладая знаниями о последующих событиях, историк может указать перечень событий, ставших причиной конкретной ситуации.
В данном контексте можно сформировать и сопутствующее определение к этому понятию:
ретроспективный – это учитывающий аспекты прошлого, аспекты, повлиявшие на развитие, работы либо проекты, осуществляемые в настоящем. То есть, «взгляд, обращенный к прошлому».
При возникновении идентичных или похожих факторов это позволяет избежать неприятностей, или наоборот – «запланировать» успех, воспроизводя удачные примеры предшественников.
Идеологии действуют по схожему принципу, стараясь взять у предков лучшее, одновременно избавляясь от факторов риска. Новые комбинации то и дело сбоят, сталкиваясь с реальностью, но это позволяет в будущем пополнить базу данных и в очередной раз немного углубить знания и улучшить представления людей о себе и о мире.
Ретроспективный подход особенно актуален для психологии, социологии, экономики – дисциплин, переживающих бурный рост на фоне постоянно изменяющейся действительности: на наших глазах информация о социальных взаимодействиях становится все более структурированной.
Несколько иной контекст наблюдается в творческой сфере. Художественная ретроспектива проявляется в трех ипостасях:
Так, живописцы прошлого не гнушались на основании словесных и прижизненных портретов создавать картины с участием умершего человека. Это также называлось ретроспективой, помогая «оживить» воспоминания об усопшем и пополнить семейную коллекцию дорогими сердцу моментами.
С развитием цивилизации эволюционировало и искусство. Если раньше можно было заглянуть на персонализированную выставку, сегодня ценители предпочитают создавать ретроспективы (особенно актуальные для кинематографа).
Обычно это подборки произведений того или иного автора, с участием определенного актера или конкретного жанра в хронологическом порядке, которые помогают лучше увидеть развитие мастерства с течением времени.
Таким же образом в литературе и кино используется так называемый флешбэк. «Вспышка прошлого» тоже является ретроспективой, но только внутри книги или сценария. Подобные «проблески» помогают проникнуться историей персонажей, объясняют мотивацию или раскрывают ранее неизвестные факты.
Особенно полюбились флешбэки авторам ужасов и детективов, когда вновь открывшиеся обстоятельства помогают глубже зацепить аудиторию.
Рабочая технология
Для программистов есть особая ретроспектива, когда в уже работающем коде они пытаются выявить неточности.
С этой методикой можно не только устранять ошибки, но и улучшать производительность, повышая конкурентоспособность продукта. Впрочем, необязательно работать за компьютером, чтобы извлечь из концепции выгоду!
Художники не стесняются удалять и добавлять штрихи к уже завершенному изображению. Писатели выбрасывают целые главы, вымарывают черновики, переписывают самиздатовские тексты перед публикацией в издательстве.
Сакраментальный «Снайдеркат» или же «Лига Справедливости Зака Снайдера» – наиболее яркий пример ретроспективы последних лет. Режиссер настолько переделал ранее показанный фильм, что вместе с картинкой поменялись целые сюжетные линии.
Вместо заключения
В XXI веке постоянно рассказывают о возможностях и перспективах, даже детей пытаются заставить думать о будущем как можно раньше. Но без ретроспекции, без анализа ошибок и исследования достижений прошлого достичь успеха просто невозможно.
Ретроспектива по шагам. Рецепт
Все, кто слышал про Scrum, скорее всего слышали про его основные мероприятия: планирование, пятиминутка (stand-up), обзор спринта и ретроспектива. Многие слышали, инструментов для проведения ретроспектив много, «обучающих» материалов ещё больше, но всё как-то не выходит. Или вроде как выходит, но почему-то команда не хочет в этом участвовать. В этой статье я представлю свой рецепт проведения ретроспектив, не только представив конкретные и детальные шаги, но и попробовав объяснить, почему шаги именно такие и в такой формулировке.
Кто присутствует
Очень желательно на первых двух-трёх ретро присутствие профессионального скрам-мастера. Причём не сертифицированного, а именно профессионального, который не просто прошёл сертификацию и обучение, а применял свои навыки проведения ретроспектив на практике хотя бы год. При кажущейся простоте мероприятие очень просто сваливается в «не туда», и по его итогам даже не понятно, а почему и как это исправить.
В будущем проведение (фасилитацию) ретро можно передать члену команды, а через некоторое время выбирать нового фасилитатора для каждого нового ретро.
Когда
Ретроспектива должна проводиться регулярно. Вообще всё в Scrum должно делаться регулярно. И планирование, и обзор, и ретро. «Сила» методологии именно в том, чтобы превратить непредсказуемый творческий процесс разработки в предсказуемый и планируемый.
Ретро должно проводиться после обзора спринта. Чтобы на ретро команда могла обсудить в том числе и то, как результаты команды были представлены (успешно или нет) заказчикам. Ретро должно проводиться до планирования следующего спринта. Во-первых потому, что планирование следующего спринта, это уже следующий спринт, а во-вторых, потому что в числе результатов могут быть какие-то задачи, которые команда поставит самой себе. И они должны будут войти в следующий спринт.
Что нужно для ретро?
Если ретро проводится в «реальном мире», потребуются стикеры/листочки (по 6-10 штук на человека), ручки и доска с маркером.
В «виртуальном» мире достаточно обойтись расшаренным экраном с двумя/тремя блокнотами, либо одним экраном Confluence / MS Word с тремя полями. Условно их пока можно назвать «плюсы», «минусы» и «действия».
Для целей геймификации можно использовать онлайн-инструменты типа fun retro / easy retro, но пока что ни один из этих инструментов не вписался в тот рецепт, который будет описан ниже.
Начало ретро
(+) Не менее N таких вещей, которые им понравились в текущем спринте, и которые они не хотели бы терять в процессе предлагаемых в рамках ретро изменений.
(-) Не более N таких вещей, которые не нравятся, и хотелось бы поменять.
Другое важное назначение «+»-пунктов, это возможность позже, когда будут предлагаться действия по решению проблем (action point’ы), выбирать те из них, которые минимальным образом будут влиять на то, что команда не хочет потерять.
Важно, чтобы плюсы и минусы записывались на листочках независимо друг от друга. Тем самым мы избавляемся от «проблемы +1», когда люди вместо раздумывания над проблемой просто присоединяются к чужому ответу (аналогичная ситуация происходит, например, при планировании, от чёго защищает «слепое» покер-планирование).
Минусы. В идеале нужно, чтобы участники сразу записали что им не нравится. Не action point, не то, что они предлагают сделать, а то, что им непосредственно мешает в работе. Но в принципе на первые 4-6 ретроспектив достаточно, чтобы участники хоть что-нибудь записали. А далее ведущий уже вытянет из них всю правду (*дьявольский смех за кадром*).
Вполне можно и допустимо сюда писать что-то, что на первый взгляд кажется «внешним» по отношению к команде. Потому что потом на детальном разборе может оказаться, что при внешней причине мы можем что-то поправить в процессе внутри команды.
Анализ
Минусы. Самый сложный этап. Игра в доктора «наоборот».
Берём каждый стикер (присланный нам в персональные предложения пункт) и. не записываем его. А проверяем, что данный пункт описывает симптом, а не болезнь. Почему? Потому что потом мы должны будем предложить такое решение, которое будет наиболее эффективным способом избавиться от симптома. И «лечение» самой болезни может быть одним из, но не самым эффективным (с точки зрения усилий и времени) способом. Кроме того, данный симптом может быть вызван несколькими причинами, и возможно только одну из них нужно будет убрать, и это вовсе не та, которую изначально назвал член команды.
Ещё раз. Каждый пункт надо записать в виде симптома, а не болезни (и точно не в виде action point’а). Например. Член команды записывает на стикере «у нас неоптимальный CI-скрипт«. Если оставить как есть, единственным возможными способом решения данной проблемы будет, очевидно, переписать CI-скрипт. Но нужно ли?
Уточняем у члена команды, «[Олег], на что в твоей работе влияет то, что CI-скрипт не оптимален»? Внезапно оказывается, что:
скрипт медленно работает
медленная работа приводит к медленному прохождению pull request’ов
невозможность распарраллелить работу приводит к простою
это приводит к медленной работе члена команды
скрипт работает недетерминированно, иногда проваливаясь из-за фазы луны и положения Сатурна в созвездии козерога
это приводит к необходимости ручного перезапуска CI
это приводит к медленной работе члена команды
Но зато для каждого следующего более общего уровня можно предложить самые разные варианты решения проблем:
поставить больше CI-агентов для сборки и распараллелить его работу / сборку / разрешить параллельную работу нескольких сборок одновременно
поставить посильнее машину для CI
выкинуть часть действий из CI-скрипта, не переписывая его кардинально
полностью переписать CI-скрипт
научить пользователя переключаться между ветками в git, позволив ему распараллелить работу и не ждать CI
сделать простой скрипт для перезапуска failed-сценариев 2-3 раза
Но пока что возможный список даже не озвучиваем. Но мы должны (из своего опыта) как-то понять, что именно та формулировка, которая будет записана, может, хотя бы в теории, быть решена несколькими разными способами. И вот именно эту формулировку и надо записать в «минусы».
Очень важно при попытке вытащить из члена команды более общую проблему не задавить его авторитетом и не подложить свою проблему вместо его. Все мы люди, все мы субъективны, и можем увидеть в чужой проблеме вовсе не то, что беспокоит члена команды, а что беспокоит нас самих. Уметь оставлять свои проблемы в стороне и слушать (и слышать) другого человека, наверное, самое важное для того, кто собирается в IT работать с людьми. Но это очень и очень сложно. Ничего страшного, если Вас по началу будут поправлять и говорить, «нет, это вовсе не то, что меня беспокоит, меня беспокоит другое». Замечательно, если Вам будут это говорить. Гораздо хуже, если с Вами молча согласятся, чтобы не спорить и побыстрее закончить.
Голосование
Изначально считаем, что за каждый пункт подано столько голосов, сколько изначальных «минусов» было сгруппировано в него. Далее я предлагаю членам команды проголосовать дополнительно за 1 или 2 пункта (из сгруппированных 7-10), Но только за те, в которых нет пунктов, которые они формулировали сами (или в которые были переформулированы их «минусы»).
В результате формируется отсортированный «по голосам» список проблем.
Блиц-этап
60 секунд это скорее ориентир. На то, что не нужно тратить много времени на блиц-проблемы, которые не являются самыми больными местами в процессе.
Перерыв на кофе
Перед перерывом на кофе окончательно формулируем top3 проблем, которые нужно обсудить, и предлагаем членам команды пойти покурить/попить/выпить/отойти проверить почту.
Обсуждение. Action Points
Во-первых, не надо отбрасывать решения, которые не решают проблему целиком. Нас вполне устроят решения, которые решают проблему хотя бы частично. Хоть на 20%, но облегчают жизнь команды. Кто знает, может именно этих 20% хватит, чтобы в следующий раз проблему не включили в top3?
Во-вторых, решения должны проходить валидацию у тех, чьи проблемы были изначально сгруппированы в единый «пункт симптомов болезни». Хотя бы один из них должен подтвердить, что предложенное решение действительно сделает его жизнь проще.
В-третьих, формулировка. Формулировка должна быть такой, чтобы у команды был минимальный шанс не выполнить пункт.
Плохой вариант
Вариант получше
Нужно устроить встречу и обсудить розовых единорогов
[Олег] устраивает встречу во-вторник в 15 часов по обсуждению проблемы питания розовых единорогов
Ответственно подходить к ревью pull request’ов
— (или) при отклонении pull request’а оставлять комментарий
— (или) настроить бота, назначающего PR на ревью на членов команды
— (или) добавить в CI-скрипт автоматический линтер, а все проблемы в оформлении, которые им не покрываются не считать проблемами
заранее формулировать тикеты в jira до планирования
[Олег] заведёт в outlook еженедельный backlog grooming до планирования с участием владельца backlog’а, представителя аналитиков и solution-архитекторов смежных систем
Полученные шаги записываются в action point’ы.
Почему ретро может не помочь
Может так случиться, что сделали всё по рецепту, а огонёк в глазах команды всё тусклее и тусклее, а производительность команды падает. Потому что автор этого текста ни хрена не знает. Ретроспектива в этом случае позволяет найти часть этих причин, и задуматься, почему эти причины до сих пор не исправлены.
Признаками проблем являются:
Ретроспектива проводится за полчаса. Это не ретроспектива, это отчёт-доклад команды «как у нас всё хорошо, как здорово и дружно мы живём, дорогой дедушка Ленин«. Явный признак того, что мероприятие проводится для галочки, без той пользы, которую могло бы принести полноценное ретро.
Повторяющиеся в две-три ретроспективы похожие описания проблем. Команда предполагает, что теоретически эти проблемы можно было бы попытаться решить какими-то действиями внутри команды. Может быть даже предлагает action point’ы.Но в какой-то момент эти проблемы просто исчезают из анализа, потому что команда уже привыкла к тому, что высказывать их бесполезно. Но сами проблемы-то никуда не делись!
Если таких проблем много, то в какой-то момент появляются фразы «слишком много времени тратится на ретроспективы». Это прямо-таки прямой сигнал о том, что с ретроспективой всё плохо. И да, без изменения формата ретро далее проводить бессмысленно.
Невыполненные action point’ы (при том, что проблема не ушла). Возможно они были очень неудачно сформулированы. А возможно тот, кто должен был их выполнить, забыл/забил/не захотел их делать.
Немного о ретроспективе
Для команды разработки важно регулярно проводить ретроспективу, чтобы постоянно совершенствоваться. Но какой она должна быть?
Несколько лет на своих ретро мы использовали только некоторые из стандартных практик. В других не видели смысла, ведь положительный результат был: процессы улучшались, проблемы решались. Все и так было хорошо. На самом деле нет:
Прошлой весной я сходил на Okademy от ScrumTrek. Это обширный курс, включающий в себя много полезного для скрам-мастера, но для меня самым полезным оказалась часть о том, как эффективнее проводить ретроспективы. Хочу рассказать, как это нам помогло.
Определитесь с правилами
Изначально у нас не было установлено формальных правил. Мы просто собирались, высказывали проблемы и обсуждали в свободной форме, пока не приходили к решению. Поэтому ретроспективы и занимали так много времени.
Послушав на Okademy всякое разное о ретроспективах, я первым делом предложил команде выработать правила проведения ретро, которые бы позволили бы сократить время не бесполезные споры. Большинство правил предложил не я, а другие члены команды. Среди предложенных правил были как стандартные, так и те, которые мне бы не пришли в голову:
По каждому из предложенных правил мы провели голосование большим пальцем:
Через некоторое время команды разработки переформировали и в новой команде оказалось три человека, которые не участвовали в обсуждении этих правил. Чтобы все приняли правила, мы заново устроили такое же обсуждение. Как бы старым членам команды не нравились выработанные совместно правила, не все они были приняты новыми участниками. Расширенное правило поднятой руки пришлось отбросить, да и стандартное правило перестало применяться — в новой команде оно просто оказалось не нужно.
Прежде чем проводить ретроспективы, договоритесь с командой о правилах. Важно, чтобы команда сама придумала и приняла эти правила (хотя некоторые правила может предлагать и сам скрам-мастер). Если просто прийти с готовыми правилами, то возникнет эффект “not invented here” — команда не будет принимать эти правил близко к сердцу. Любой новый участник команды должен принять правила. Если какие-то из них он не примет, обсудите эти правила снова. Если состав команды сильно меняется, проведите обсуждение правил с нуля.
Структура ретроспективы
Ретроспективу принято делить на следующие этапы:
Чтобы увеличить вовлеченность команды бывает полезно периодически менять активности. В этом помогают карты ретроспектив.
Подробнее про разные активности для каждого из этапов, вы можете посмотреть здесь.
Открытие
Этот этап нужен, чтобы вовлечь команду в работу. Для зрелых команд его обычно опускают — все и так без проблем втягивается в обсуждения. Так как у нас большой опыт проведения ретро, то и от открытия не было особой пользы. Но если вы видите, что часть людей не принимают участия в обсуждениях, возможно вам как раз не хватает открытия.
Сбор данных и ранжирование проблем
На этапе сбора данных надо выяснить, что у команды болит.
Раньше для этого мы всегда применяли активность Glad, Sad, Mad: каждый участник пишет на стикерах, что за последний спринт его порадовало, расстроило или разозлило. Эта активность хороша тем, что включает эмоции (в отличие от простого деления на положительное и отрицательное) и поэтому выполняет также роль открытия: вовлекает всех в работу. Также подобные активности заставляют вспоминать не только о проблемах, но и о всех положительных моментах, произошедших за спринт. Это важно, чтобы закрепить эффективные практики. Кроме того то, что одни оценивает положительно, другие могут оценивать отрицательно. Важно обсуждать такие различия в оценке.
Дополнительно мы в течении спринта собирали проблемы на специальной доске баттхертов. Это помогает не забыть о них к моменту ретро. Также это даёт людям, не входящим в команду, возможность поделиться своей болью (для обсуждения таких стикеров нужно звать на ретро их авторов). Но в итоге у нас скопилось большое количество проблем, которые мы не успевали разобрать.
Здесь на помощь приходит ранжирование. Не обсуждайте все проблемы, о которых люди могут вспомнить. Ранжируйте их по степени важности и обсуждайте только наиболее приоритетные. Предварительно объедините похожие проблемы в кластеры. Для ранжирования хорошо подходит dot voting:
Генерация идей и выбор решений
После отбора важных проблем по каждой из них нужно сгенерировать решения. Если по одной проблеме есть несколько взаимоисключающих решений, то надо из них выбрать наиболее подходящее. Тут также поможет dot voting.
Важно, чтобы все принимаемые решения были SMART:
И это при том, что мы пытались большинство решений свести к SMART.
Помнить о такой куче мелких решений невозможно. Даже запомнить, что значит каждая из этих карточек, удается не всем. Проверить, есть ли польза от этих решений, нельзя. Можно сказать, что если вы в результате обсуждения повесили карточку на Decisions Board, то время на обсуждение потрачено зря.
Выработать SMART-решение для любой обсуждаемой проблемы сложно. Нам до сих пор это удается далеко не всегда. Тем не менее я могу предложить несколько идей для улучшения в этом плане:
Через месяц оценим, помогло ли это. Если не поможет — напишем бота, который будет нас ругать, если мы незапулили тикет.
Закрытие
Закрытие необходимо в том числе для того, чтобы оценить, насколько хорошо прошло ретро и понять, в чем его можно улучшить.
Раньше мы не проводили закрытие. При этом я был уверен, что у нас в команде довольны нашим стандартным форматом ретро и негативно воспримут любые игровые активности. Если б мы не начали проводить закрытие, я бы так и не узнал, что некоторым членам команды это однообразие наскучило и они вовсе не прочь попробовать любые новые активности. С тех пор как мы стали проводить закрытие, я получаю полезную обратную связь почти на каждом ретро.
Обратная связь по ретроспективе нужна скрам-мастеру не только, чтобы улучшаться, но и чтобы не перегореть. Помните, что вы не железный, и вам хотя бы иногда нужна похвала за вашу тяжелую работу.
Ретроспективы в проектных командах: что это, зачем нужно и как эффективно провести
Наша команда разрабатывает большое количество обучающих проектов и собственных продуктов. Мы постоянно анализируем и улучшаем процессы разработки, обмениваемся обратной связью друг с другом и внедряем изменения. Поэтому после каждого завершённого проекта мы проводим ретроспективу с командой, а иногда и отдельно с заказчиками.
Ретроспектива — встреча команды после завершения проекта для того, чтобы подвести итоги, поделиться полученным опытом и составить план возможных улучшений на будущее.
Зачем нужны ретроспективы
Мы шли к ответу на этот вопрос какое-то время и сформулировали для себя следующие пункты:
Проведение ретроспектив с модератором
Изначально мы собирались с командой проекта и руководителем отдела разработки и в свободном режиме обсуждали проект, делали выводы и фиксировали важные инсайты для разработки. Но со временем мы обновили формат ретроспектив и вот уже больше года проводим их вместе модератором. Также с марта 2020 в связи с изменением формата работы мы стали проводить ретроспективы онлайн в Skype, GoogleMeets или Zoom.
Модераторы — это сотрудники нашей компании LEVEL с бэкграундом психолога, тренера или преподавателя. Также модератором может стать любой сотрудник, у которого есть желание и интерес развиваться в этой роли.
На данный момент у нас сформировалась команда модераторов, которая улучшает форматы и ищет новые инструменты проведения ретроспектив.
Так, в апреле мы с модераторами находили различные решения для совместной работы в онлайн-формате. Для этого мы изучали интерактивные и виртуальные доски и остановились на Miro, подготовили в нём шаблон доски для проведения ретроспективы.
Сейчас мы пришли к тому, что не хватает единого бланка для заполнения по итогам ретроспектив и решили создать его.
По завершении почти каждого проекта мы проводим ретроспективу. Если проект длительный и объёмный, мы рекомендуем менеджерам проводить дополнительные встречи по окончании его отдельных этапов и подводить мини-итоги.
Также со временем мы пришли к выводу, что проведение ретроспективы в типовых для нас проектах оставляем на усмотрение менеджера. Как правило, в данных случаях в разработке не возникает новых вопросов, всё проходит стандартно по процессам.
Внедрение изменений по итогам ретроспектив
Системное проведение ретроспектив позволило нам накапливать данные о разработке проектов. Чтобы ценная информация после ретроспектив не терялась, менеджер проекта заполняет форму по итогам встречи, куда заносит все выводы команды. Далее с этими данными работают руководители отделов и менеджер внутренних проектов.
Например, на этапе сборки мы постоянно сталкивались с одними и теми же вопросами по реализации упражнений в электронном курсе, интерактивов или вёрстки. Поэтому, после анализа одного из проектов мы усовершенствовали технические пояснения в сценарии курса и стали прописывать подробную работу механик для сборщика.
Также мы включили в процесс разработки обязательную проверку методолога и дизайнера на этапе сборки, так как выявили, что этого не хватает.
Выводы и анализ ретроспектив помогают не только найти пробелы в разработке, но и подтвердить, что всё идет хорошо. Например, во время обсуждения одного из проектов мы сделали вывод, что подключение разработчика на этапе написания сценария электронного курса — это успешный опыт, который позволяет уменьшать технические риски реализации проекта.
Процесс ретроспектив в LEVEL отлажен, информация и выводы дают поле для инсайтов и изменений, а это значит, с большей вероятностью мы не допустим пробелы в разработке, сделаем выводы и завтра точно станем лучше, чем были вчера.