Русский
Русский
English
Статистика
Реклама

Retrospective

Игровая механика для скрам-команды, которая любит настолки

03.07.2020 14:20:11 | Автор: admin
Мы в команде обожаем настолки. И чем сложнее их механика, тем интереснее.

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

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



Привет! Меня зовут Павел, я занимаюсь фронтендом и скрамом в команде Wrike. Мы работаем по Scrum, сейчас у нас около 30 команд, в одной из которых я скрам-мастер. Я им стал уже больше года назад и хочу поделиться своим опытом, как мы пытались геймифицировать наши процессы.

Что для нас означают командные бест-практики


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

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

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


Команда, когда я прошу ее помнить про договоренности с ретро

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

Набор карт и правила


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

Проклятие: Соплежуй
Разыграй эту карту на больного человека. Немедленно отправь его домой.

Проклятие: Покорми QA
Отдай тому, кто не прогнал автотесты по своей ветке перед передачей в тестирование.

и еще одна про то же самое:
Ассенизатор
Разыграй эту карту на того, кто передал ветку QA, не запустив автотесты. Несчастный сам разбирает упавшие автотесты.

как в самом Манчкине:
Гадкая парочка
Отдай эту карту QA, если хочешь, чтобы твою ветку заранее потестировали параллельно с ревью.

Проклятие: Фиксик
Сыграй эту карту на игрока, чья ветка развалилась на спринт ревью. Выбранный игрок проводит следующее спринт ревью вне очереди.

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

Проклятие: Скорострел
Отдай тому, кто перевёл таску в тестирование до окончания ревью. Игрок должен выполнить сокровенное желание QA.

Проклятие: Невероятно грязное ругательство
Разыграй во время любого митинга. Тот, кто залипает в ноут, закрывает его и кладет на свой стол.

Гонг
Разыграй эту карту после дейли. Вся команда встает и идет на обед.

Шмотка: Арбалет поражения ложных тепловых целей
Используй, когда кто-то меняет план спринта. Игрок с арбалетом должен актуализировать цели спринта.

Броник: Худи-неведимка
Можешь заливать технические итерации в мастер в скрытом виде, если они не будут доступны пользователям.

Бросить перчатку
Немедленно призови скрам-мастера и лида, если чувствуешь, что занимаешься чужой работой (например, другой команды).

Обкашлять вопросики
Играй при возникновении критического блокера. Выбранные игроки должны разобраться с проблемой в течение суток.

Проклятие: Эксгибиционизм
Выбранный игрок должен отдать макеты по новым фичам на ревью стейкхолдерам.

Черная дыра
Играй, если PO передал dev-команде не готовую к проработке историю. Команду засосет черная дыра, а история вернется к PO или UX.

Грязевой ком
Играй для растянувшейся задачи, если никто заранее об этом не подсветил это на дейли. Провинившийся игрок проводит следующее дейли.

Проклятие: Полиамория
Играй в пару FE и BE, чтобы они начинали интегрироваться (можно безопасно на заглушках).

Подкупи стейкхолдеров
Можешь не рассказывать о фейлах на спринт-ревью.

Темная материя
Играй, когда в спринт попала непроработанная задача. Замени ее другой задачей того же типа из беклога.

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

Правила игры

  1. Участвует вся команда (как минимум 1 экспериментальный спринт).
  2. Карта может быть разыграна в любой момент, то, что на ней написано обязательно к выполнению.
  3. Чтобы разыграть карту, нужно публично выложить ее на стол во время митинга, объявить об этом во время дейли или отдать другому игроку.
  4. Карты раздаются рандомно.

Раздаем карты


Мы договорились попробовать эту идею в течение одного спринта и потом решить, стоит ли продолжать. На утро после ретро я напечатал и нарезал колоду. Каждый, кто приходил в офис, тянул по 7 карт игра началась.



Первое, что мы заметили она началась достаточно вяло. Самые интересные карты были связаны с активной фазой спринта, когда задачи растягиваются, переходят от разработчиков к QA или деплоятся. В первый день ребята только создавали ветки и вникали в требования. Никаких триггеров еще не произошло, поэтому сыграли только технические карты: например, Гонг, чтобы всем вместе пойти на обед.

Карты игрались во время дейли: когда до кого-то доходила очередь, их выкладывали на общий стол. По ходу спринта начали прилетать триггеры.

Мы сыграли Гадкую парочку, когда дело дошло до ревью одной из задач. Логика оказалась достаточно сложной, был смысл проверить ее заранее параллельно с ревью, тем более у QA было свободное время. Кое-кто забыл прогнать автотесты перед тем, как отдавать задачу в тестирование пришлось покормить QA обедом. Ближе к концу спринта я разыграл на себя Соплежуя и поехал домой, чтобы не сидеть и не кашлять в общей комнате.

При этом большую часть карт разыграть не удалось. Первая проблема была в том, что мы раздавали их рандомно. Кажется, по аналогии с Манчкином стоило добавить классы Фронтендер, Бэкендер, QA. Если бы на Ассенизаторе было написано Только для QA, он бы попал к ребятам, которые в нем заинтересованы. К тому же все случаи с не запущенными автотестами точно пройдут через них, а разработчики с такой картой на руках могли про них даже и не знать.

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

Какой вывод мы сделали


Как минимум, это весело! Было интересно всем вместе придумывать механику, особенно в таком стебном стиле. И оказалось интересно попробовать, как она работает.

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

Идея с геймификацией команде зашла, но ее нужно тюнить. Стоит отказаться от случайной раздачи карт, ввести классы и классовые ограничения для карт (Только для QA), подумать над механизмом обмена и обновить список триггеров (чтобы там оставались только актуальные проблемы).

Какую карту вы бы разыграли сейчас? Что добавила бы ваша команда?
Подробнее..

Проводим ретроспективы для распределенных команд (и как Trello в этом помогает)

19.04.2021 10:09:21 | Автор: admin

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

Почему Trello

Я пользовался большим количеством инструментов, из которых можно выделить основные: Miro - как интерактивный флипчарт, с которым может взаимодействовать вся командa; Google Docs с секциями помапанными на стадии ретроспектив; Confluence (так как все мои проекты пронзены Atlassian-стеком); а также, порой, Jira (вау, это была достаточно плохая идея)!

Я думаю что все пытались нащупать тот самый инструмент, который можно применить фактически в любой области!

И вот я бы выделил основными критериями для проведения Ретро и собирания фидбека о Демо в подобных инструментах:

1. Насколько хорошо оно работает на уровне объектов (во время обсуждений). -> в идеале тут хотелось бы видеть карточки (все таки мы в физическом мире работаем со стикерами) :)

2. Быстрая и эффективная работа с карточками / объектами

3. Подсветка / теги для карточек / объектив (чтоб все могли), не важно как (цвет, тег, еще какая-то штука позволяющая дифференцировать карточки)

4. Перетасовка / изменение порядка карточек / объектов / айтемов

5. Как можно меньшее время, затраченное на следующую последовательность действий: создание секции (списка) -> добавление в него объектов / карточек -> тегирование / подсветка айтемов (членами команды) -> добавление комментария к айтему.

Miro

Я безумно люблю Miro, и постоянно использую его для воркшопов. Но. использовать в ретроспективе и без подготовки этот сервис не настолько просто, насколько хотелось бы (сам сервис функционала предоставляет ого-го, однако ж формат ретроспектив сильно завязан на карточках, работа с которыми в Miro - не самая сильная его сторона). В самой основе, скелете, так сказать, не заложена поддержка карточек как дефолтного варианта, поэтому эту структуру приходится содержать самостоятельно: создавать колоночку, двигать айтемы аккуратно, чтоб оно все относительно ровно стояло. Это тратит время, это не так просто и быстро работает в браузере. Ну и тегирование - тоже не сказать что сильная сторона Miro.

Google Docs

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

В этом плане, знаете, даже google sheets казалось бы удобно использовать, как инструмент более подходящий для нашей аналогии двухмерной-классической-ретро-доски (ну как двухмерной, скорее именно с точки зрения того, что у нас есть некие секции с контентом для хорошо/не оч/ улучшить). Но и тут нас поджидает неудобство - drag-n-drop для айтемов, и их линкование друг с другом работает ужасно. Я еще пробовал в свое время google slides, с подходом слайд-для-секции (например перечислить все те великие свершения, в которые мы шмогли с прошлого спринта) - но в итоге менеджить это было сложно, ввиду тяжеловесности решения, ну и на одном таком канвасе могло одновременно ну человека два работать может, не больше. Ну и подсвечивать айтемы там конечно можно, но оно для того не очень приспособлено.

Confluence

Ну вот же confluence, там же целый шаблон для ретро есть! Скажете вы. И будете правы!

Но хорош этот шаблон для документирования/стенографирования, для журнала принятия решений. А нам это в ретро не нужно! Нам нужна живая дискуссия где народ таскает карточки по колонкам, клонирует, обсуждает, помечает!

Более того, Atlassian обычно старается сделать confluence неким легковестным решением, если вас кормят всем их стеком. Но по простоте коллаборации там до gDocs как до луны. Возвращаясь к нашему подходу (ищем блочную структуру для карточек) - confluence неудобен. А еще - нестабилен: с потерей контента и его перезатиранием в режиме коллаборации, отвалом соединения и последующими невозможностями сохранить.

Trello

Ну вот а когда мы подходим к Trello - оно просто поддерживает карточки. И голосовалку для этих карточек с помощью power-up'ов (очень просто). Или через тегирование этого дела цветами (что работает просто и быстро).

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

Короче говоря: trello это самый простой в использовании аналог флипчарта со стикерами :)

Подготовка к самой ретроспективе, и ее начало

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

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

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

- Соединение должно быть отличное! Мы не хотим страдать из-за непонимания (особенно в мультиязычных командах :), и нам не нужны лаги

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

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

В зависимости от зрелости и атмосферы в команде можно использовать Ice Breakers (чтобы настроить на легкое взаимодействие и убрать ощущение обязаловки). Ну и не забудьте проверить как команда чувствует себя после спринта (проверка температуры) - не ждите высокой оценки как данности.

Запланированные улучшения с прошлого спринта

Обычно я начинаю ретроспективу с перечисления улучшений и достижений, которые мы с командой запланировали в прошлый раз.

Так что мы помечаем получившиеся вещи зеленым (и, в идеале, у нас есть список улучшенных со временем вещей с прошлого, к которому мы можем обращаться). Или же оранжевым (критичные улучшения, которые мы не достигли, но запланировали). Ну или красный (что планировали, но не смогли улучшить за последние два спринта). Позже мы приоретизируем красное (если оно все еще актуально, по прошествии аж двух спринтов) выше всего остального. В целом - пользуйтесь таким цветовым кодированием, которое вам как команде нравится больше.

Это позволяет команде добавить прозрачности в её процессах, а также задать тон саморефлексии для самого события ретроспективы.

Иногда эта стадия может затянуться (планировали улучшение - не смогли достичь - начинаем погружаться слишком сильно в детали почему). Как фасилитатор, ваша задача помочь команде найти продуктивный путь для выявления настоящей причины в достаточно короткий срок (у нас ведь есть таймбокс). Поэтому мы с вами планируем один обязательный пункт улучшения, два уже имеют риск затянуть начало ретроспективы. Также старайтесь просто запарковать это обсуждение на полее поздние части ретроспективы - если нужно действительно разобраться. А возможно это даже не относится к ретроспективе как к событию, а надо проводить RCA / Post-Mortem?

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

Цели спринта и метрики

Цели Спринта

Цели спринта это ваш индикатор прозрачности. Достигли ли вы их или нет. При правильном использовании, команда постоянно ориентируется на цели спринта во время каждого события, и поэтому сама должна отлично понимать как она с этой целью справилась. Я считаю что даже если цель обсуждена на Sprint Review, все равно хорошо бы еще раз подсветить причины удачи или неудачи достижения (а это уже непосредственно относится к процессу работы, а значит и к ретроспективе).

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

Метрики

Метрики спринта важны и как внутренний-SLA для команды, и как общий индикатор, который в комплексе помогает команде понять динамику.

Обычно команда навскидку придумает с десяток факторов, которые для неё препятствия чтоб быть более эффективной. Если поддерживать ведение такой дискуссии в правильном русле (читай, фасилитировать), и помогать команде наводящими вопросами (читай, коучить), ребята сами соорудят путь к улучшению и как его измерять. Главное чтобы был запрос на улучшение, и была понята сама проблема (нафига оно нам вообще). Еще нюансик: не рассматривайте метрики отдельно друг от друга, и стройте связи между опережающими индикаторами (гипотезами) и запаздывающими индикаторами (результатом). Например, действительно ли увеличение покрытия кода тестами увеличивает уверенность в том, что на проде качество улучшается?

Стандарные метрики, которые я стараюсь использовать:

- Lead Time (время от запроса клиента до поставки)

- Cycle Time (время от начала работы над задачей до поставки). Когда объяснишь на примере донесения ценности до пользователя - как устроен весь пайплайн и где затыки, ребята сами будут мотивированы следить за этими метриками (если, конечно, они у вас общаются с клиентами постоянно),

- Время в Code Review (атож, сколько задача висит и сколько ее проверяют),

- Количество раз тикет был переоткрыт (помогает вместе с определением Definition of Ready),

- Mean Time to Recovery (инцидент-метрика для понимания среднего времени на устранение),

- Bug Escape Rate (сколько багов мы не поймали на тестовых стендах, но поймали после релиза на прод).

В целом все зависит от ситуации, но я считаю Cycle Time и Lead Time тем самым минимумом для всех. Cycle Time в целом дает вам понимание прозрачности и предсказуемости.

Активность на выявление дельты улучшения ~ 'Хорошо-Плохо-Улучшения

Единственное, что как и в локализованных командах, люди в распределенных командах должны "вешать стикеры" с рефлексией заранее, чтоб у всех был контекст. Если таких "стикеров" много - можно организовать голосование, дабы сузить круг обсуждаемого. Не нужно ждать начала самого ретро для сбора обратной связи. Опять же, роль фасилитатора заключается в подсветке конфликтов и проблем когда команда непосредственно с проблемами этими сталкивается. Можно и нужно помогать команде корректно и ёмко отражать саму суть проблемы. Подсвечивать можно по-разному, например отражая что слышишь от команды (я правильно понимаю, что ты имеешь ввиду ....), или беря на себя роль человека, не знакомого с контекстом задачи/проблемы, как-то еще. Самое главное, чтобы команда была вовлечена в процесс инспекции во время самого спринта или каденции, а не только во время ретро.

Собираем фидбек с команды о том, как прошла ретроспектива

Ну а что, нужно же нам знать, насколько плохо мы справились! Я просто прошу оценить ретро по 10-бальной шкале, и назвать одно улучшение, чтобы увидеть дельту.

Референсы и полезности

У Бена Линдерса (Ben Linders) есть хорошая трелло-доска, в которой люди краудсорсят ретроспективные техники для распределенных команд в трелло.

  • https://www.benlinders.com/news/trello-board-retrospective-techniques/ Это, наверное, и разговоры с самим Беном, были огромным подспорьем, чтобы написать этот пост.


Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru