В последнее время я достаточно часто использую 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/ Это, наверное, и разговоры с самим Беном, были огромным подспорьем, чтобы написать этот пост.

Проблематика

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

Какие есть варианты?

Сравнивая различные инструменты и таскменеджеры, выбор пал на одного из популярных игроков рынка - Trello. Однако, сразу после выбора программы, возникло новое препятствие. В бесплатной версии этого приложения отсутствовала возможность синхронизации досок нескольких сотрудников воедино без сторонних сервисов, типа Zapier, где для большого проекта тоже нужна лицензия.

В чем смысл объединения?

1. Заходить в 5 досок и просматривать отдельно каждого, просто не хватит времени и сил.

2. Если не синхронизировать доски на одном экране, будет крайне сложно сравнить одного сотрудника с другим по уровню текущей нагрузки.

3. Сотрудники хотят понимать нагрузку каждого из членов команды, а для этого нужно опять же как то сводить все воедино.

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

Как синхронизировать доски 5 сотрудников в одной доске "дашборде" и при этом не оплачивать лицензию в Трелло или передаточных сервисах типа Zapier?

Решение задачи:

К счастью для работы с досками trello уже создан полноценный пакет на языке R, который позволяет подключаться к API таскменеджера, и именно им я и решил воспользоваться для решения всех задач.

Ход решения:

Сначала получим ключи и секретный код для работы с API https://trello.com/app-key (предварительно необходимо авторизоваться под своей учеткой в Trello и открыть себе доски сотрудников с правами администратора)

Сохраняем ключ и токен, который можно найти внизу этой же страницы

Далее установим сам язык R. Для его подключения нужноскачатьи установить инсталляторы. Также для комфортной работы с R рекомендуюиспользоватьбесплатную среду разработки RStudio.

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

• работы с API Trello trelloR

• работы со временем и временными периодами lubridate

• работы с таблицами и агрегации данных dplyr

Чтобы установить пакеты из основного репозитория CRAN примените базовую функцию install.packages, а для загрузки пакетов с github функцию install_github:

remotes::install_github("jchrom/trelloR")install.packages("lubridate", dependencies = TRUE)install.packages("dplyr ", dependencies = TRUE)

Подключаемся к API и получаем токен:

# Указываем путь к папке куда будет сохранен полученный tokensetwd("C:\\*********\\R_script\\trello")# Получаем tokenmy_token = get_token("my_app", key = "", secret = "",                     expiration = c( "never"))

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

trelloadd <- function(delcard = NULL,                      addcard = NULL,                      nlista = NULL){  # Находим исходный лист сотрудника в Трелло откуда будем брать карточки  для записи в дашборд  ishod_tab <- get_list_cards(addcard)    # Определяем доску куда пишем новые карточки  bid = get_id_board(delcard)    # Получаем все списки с листами на доске дашборда  lid <- get_board_lists(bid)$id[nlista]    # Получаем все карточки в необходимом листе куда пишем  cid<-get_list_cards(lid)    # Удаляем карточки, которые уже есть в листе сотрудника на дашборде  if (length(cid$id)>0) {    for (i in 1:length(cid$id)) {      delete_resource(resource = "card", id = cid$id[i])    }  }else{    print("no-del")  }    # Находим дату создания карточки в исходном листе  dateList<- data.frame(dateadd = NA)  for (i in 1:length(ishod_tab$id)) {    cardID <- ishod_tab$id[i]    dateList[i,1] <- strtoi(strtrim(cardID, 8), 16L)  }  dateList$dateadd <-as.POSIXct(dateList$dateadd, origin = "1970-01-01")    # Циклом собираем лист записи и создаем карточку для переноса в дашборд  if (length(ishod_tab$name)>0) {    for (i in 1:length(ishod_tab$name)) {        payload = list(        idList = lid,        name = ishod_tab$name[i],        desc = paste0(ishod_tab$desc[i],"Date Add: " ,dateList$dateadd[i], "                     В работе уже ", floor(as.vector(difftime(today(),dateList$dateadd[i], units='days'))), " день"),        start = ishod_tab$start [i],        due = ishod_tab$due [i],        pos = "bottom"      )      r <- create_resource("card", body = payload)    }  }else{    print("Ok")  }  if (nrow(bind_rows(ishod_tab$labels[]))>0) {      # Добавляем лейблы (метки)    bid = get_id_board(delcard)    lid <- get_board_lists(bid)$id[nlista]    cid <-get_list_cards(lid)        # Находим карточки без меток    nlab <- which( lapply(ishod_tab$labels, length)!=0 %in% T)    for (i in nlab) {      labl <- ishod_tab$labels[[i]]      for (xi in 1:nrow(labl)) {        r <-  add_label(cid$id[i], color = ishod_tab$labels[[i]][xi,4],                        name = ishod_tab$labels[[i]][xi,3] )        }    }   }else{    print("no_lable")  }}

В функции необходимо будет только заполнять переменные:

• delcard - Это id дашборда в который будет записываться информация из досок сотрудников

• addcard - Это id листа из которого будут браться карточки для переноса в дашборд

• nlista - номер листа в дашборде в который будут заноситься карточки

Получаем delcard

Для получения id дашборда куда будем писать общие карточки, сначала необходимо создать эту доску в самом Трелло, а затем из поисковой строки браузера скопировать необходимый нам id

Получаем addcard

Для того чтобы получить лист откуда будут браться исходные данные, мы точно также как с delcard копируем ссылку на доску, только теперь забираем всю ссылку целиком и используя готовую функцию извлекаем все листы на исходной доске:

get_board_lists("https://trello.com/b/*****/сотрудник1", query = list(customFieldItems = "true"))

В результате выполнения функции, прямо в консоли R мы получим перечень всех листов на доске и по названию листа можем выбрать необходимый нам id для получения карточек

Данную процедуру мы проделываем для досок всех наших сотрудников из досок которых мы планируем забирать карточки для переноса на дашборд.

Далее проходим доски всех сотрудников и перезаписываем их на общий дашборд используя функцию созданную выше:

# Сотрудник1 ####trelloadd(delcard = "od*****W",           addcard = "600**********04",          nlista = 2)# Сотрудник2 ####trelloadd(delcard = "od*****W",           addcard = "5fc4********24",          nlista = 3)# Сотрудник3 ####trelloadd(delcard = "od*****W",           addcard = "5e94*********8ce",          nlista = 4)# Сотрудник4 ####trelloadd(delcard = "od*****W",          addcard = "5faa*********c522",          nlista = 5)# Сотрудник5 ####trelloadd(delcard = "od*****W",          addcard = "60744*******3394",          nlista = 6)# Сотрудник6 ####trelloadd(delcard = "od*****W",          addcard = "5e73******b07",          nlista = 7)

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

В итоге:

1. Мы получили полноценную синхронизацию всех досок любого числа сотрудников в trello

2. Решили проблему с тем, чтобы наглядно иметь доступ к дате создания каждой задачи

3. Имеем фундамент для анализа продуктивности сотрудников в любых разрезах, благодаря возможности добавлять в код новые различные улучшения расширяя код на основе Api от Trello, на основе бизнес логики вашей компании и возможностей языка R.