Всем привет! Меня зовут Ксюша, и я backend QA-лид нескольких команд в EXANTE.
В начале этой истории я была обычным QA в команде, которая отвечает за ядро нашего backoffice.
Думаю, многие из вас знакомы со Scrum и его ивентами, но если нет — дальше речь пойдет о ретроспективе, одной из ключевых встреч этого фреймворка.
Вначале пути, вскоре после agile-трансформации, мы проводили ретроспективы, которые, в теории, должны были приносить пользу, а на практике ощущались бесполезными. В течение часа мы жаловались и выпускали пар, а через один спринт возвращались к тем же проблемам.
Например, мы обсуждали качество вопросов, с которыми к нам приходят извне, отсутствие необходимых данных для их анализа и что работа над ответом отнимает слишком много времени у команды. Обсуждали, кто виноват в том, что не все запланированные задачи дошли до релиза в спринте и, порой, находили.
Со временем мы осознали: раз уж мы тратим время на нытье, нужно делать это конструктивно. И сейчас я расскажу, что нам помогло.
Что было не так с ретроспективами
Несколько лет назад, наши ретро выглядели как вечер худших воспоминаний. За час мы пытались вспомнить, что бесило в течение этих двух недель. Это было непросто по нескольким причинам:
Нужно было вспомнить проблемы, которые встречались за время спринта, потому что единого пространства для этого не было.
После того как участник команды озвучивал проблему, часто с ней никто ничего не делал — плана по ее ликвидации не было.
В результате мы использовали ретроспективу как комнату ярости, в которой можно пожаловаться и эмоционально разрядиться.
Но при этом у нас были не оптимальные процессы в команде, которые оставались не обсужденными. Например, с распределением нагрузки:
Разделение ответственности за результаты команды – только тестировщик организует процесс релиза.
Мало общедоступных данных — много информации хранится в головах конкретных коллег.
Как мы организовали инфраструктуру для нытья
Чтобы ретроспектива работала, мы внедрили несколько инструментов:
Создали доску вопросов в 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 — при том, что сложность системы и частота релизов только росли.
Вообще, не всё было так гладко. Команду приходилось мотивировать и повторять мантры про эффективность встреч и нежелание тратить время впустую. Многим хотелось бросить всё и вернуться к старому доброму хаосу. Но мы не откатились назад, и новый процесс стал привычкой.
Советы для тех, кто ждет изменений в своих ретроспективах или пока только на пути осознания, что они нужны:
Говорите о сложностях. Как и в обычной жизни — все нужно проговорить и желательно спокойно и тогда это скорее всего решится.
Не копите. Записывайте проблемы сразу. А лучше — заведите общее место для всей команды, чтобы их собирать в моменте и хранить до следующего ретро.
Автоматизируйте всё, что бесит. Если процесс можно отдать боту — отдайте.
И помните: не нойте слабо, нойте достойно — так, чтобы после вашего нытья мир (или хотя бы спринт) стал чуточку лучше!
Если хочется чего-то более серьёзного, рекомендую книгу от богинь ретроспективы Эстер Дерби и Дианы Ларсен «Agile-ретроспектива. Как превратить хорошую команду в великую».
Спасибо за внимание!