Всем привет! Меня зовут Ксюша, и я backend QA-лид нескольких команд в EXANTE.

В начале этой истории я была обычным QA в команде, которая отвечает за ядро нашего backoffice. 

Думаю, многие из вас знакомы со Scrum и его ивентами, но если нет — дальше речь пойдет о ретроспективе, одной из ключевых встреч этого фреймворка.

Вначале пути, вскоре после agile-трансформации, мы проводили ретроспективы, которые, в теории, должны были приносить пользу, а на практике ощущались бесполезными. В течение часа мы жаловались и выпускали пар, а через один спринт возвращались к тем же проблемам.

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

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

Что было не так с ретроспективами

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

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

2. После того как участник команды озвучивал проблему, часто с ней никто ничего не делал — плана по ее ликвидации не было.

В результате мы использовали ретроспективу как комнату ярости, в которой можно пожаловаться и эмоционально разрядиться.

Но при этом у нас были не оптимальные процессы в команде, которые оставались не обсужденными. Например, с распределением нагрузки:

• Разделение ответственности за результаты команды – только тестировщик организует процесс релиза.

• Мало общедоступных данных — много информации хранится в головах конкретных коллег.

Как мы организовали инфраструктуру для нытья

Чтобы ретроспектива работала, мы внедрили несколько инструментов:

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

• Разработали сценарий решения. Каждая жалоба стала заканчиваться Action Item с ответственным.

• Медиация вместо обвинений: Мы перестали искать виноватых и начали искать «узкое горлышко» в процессе.

Кейсы: о пользе эффективной коммуникации

Вот четыре реальных примера, как «достойное нытье» изменило нашу жизнь.

Кейс №1: бот для распределения дежурств

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

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

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

А с рандомом не поспоришь!

Кейс №2: балансировка нагрузки

У нас есть релизная процедура, которая состоит из бюрократических действий и приемки качества релиза на stage-окружении — в ней больше 10 обязательных пунктов, выполнение которых занимает суммарно до 3-4 часов за релиз. Исторически в нашей команде эта процедура была обязанностью только QA. Так всем было удобно, но тестировщикам было тяжело.

Поэтому мы пошагово расписали процедуру и начали делить ответственность за релизы с разработкой так же через бота для дежурств. QA стали счастливее, а команда получила баланс нагрузки. И если раньше мы релизились каждый спринт (=2 недели), то теперь мы релизимся чаще – каждую неделю.

Кейс №3: прокачка груминга

Когда-то мы из раза в раз срывали спринты из-за плохой проработки требований и того, что приходилось переосмысливать задачи внутри спринта. Но после ряда обсуждений (в рамках ретро, конечно), мы внедрили в груминги (это тоже ивенты по Scrum) глубокую проработку задач, в том числе — обязательное описание acceptance criteria. И параллельно вводили shift-left в аналитике и тестировании, что помогло сделать наши спринты более предсказуемыми, так как продуманные и хорошо описанные задачи вызывают минимум вопросов при реализации.

Кейс №4: трибуна для любых вопросов

Один из разработчиков всегда приходил к QA за токеном для авторизации, который был нужен для разработки и тестирования сервисов компании. Это отвлекало обе стороны.

Когда наконец атмосфера в команде позволила ему поныть на ретро и сказать, что это неудобно, коллеги посоветовали простые способы для самостоятельного получения токена. Итог — плюс автономность, минус лишнее переключение для двоих участников команды.

Как нытье улучшило нашу жизнь

Во-первых, нам стало комфортнее работать. 

Во-вторых, мы стали эффективнее. Вот цифры из трех отчетных периодов:

Расшифровка сокращений: 

Наша приоритизация прод инцидентов: от SEV-1 (самый высокий) к SEV-4 (самый низкий).

• Период 2022-2023: 87 инцидентов. Это была точка старта: много мелкого мусора (55 штук SEV-4*) и приличное количество SEV-3 (32 штуки).

• Период 2023-2024: 45 инцидентов. Первые плоды реформ: общее количество багов упало почти в два раза. Мы начали лучше фильтровать требования на входе. Сокращение почти вдвое!

• Период 2024-2025: 21 инцидент. Текущий результат: еще одно сокращение более чем в два раза (на 53%). Количество критичных багов (SEV-1/2) исчисляется единицами.

За два года активной работы над процессами мы снизили количество инцидентов на проде с 87 до 21 — при том, что сложность системы и частота релизов только росли.

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

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

1. Говорите о сложностях. Как и в обычной жизни — все нужно проговорить и желательно спокойно и тогда это скорее всего решится.

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

3. Автоматизируйте всё, что бесит. Если процесс можно отдать боту — отдайте.

И помните: не нойте слабо, нойте достойно — так, чтобы после вашего нытья мир (или хотя бы спринт) стал чуточку лучше!

Если хочется чего-то более серьёзного, рекомендую книгу от богинь ретроспективы Эстер Дерби и Дианы Ларсен «Agile-ретроспектива. Как превратить хорошую команду в великую».

Спасибо за внимание!