Сложности перехода на эфемерную среду тестирования или к чему готовиться проектному менеджеру?
Для контекста: я проектный менеджер в IT аутсорсе, и наша доска (Kanban board) и процессы сильно зависят от процессов клиента. Кроме нас у клиента есть и своя внутренняя команда разработчиков. Мы работаем над финансовым приложением по стандартам бухгалтерского учета.
Совсем недавно мы перешли на работу с эфемерной тестингововой средой. Коротко — Эфемерал (от «Ephemeral», пример uffizzi.com, release.com).
Для тех, кто пока не сталкивался с Эфемерными средами: такая среда создается на короткий период и удаляется после тестирования. Эта среда более чистая (в ней код от develop и ветка задачи на проверку, больше ничего).
До Эфемерал у нас была обычная тестинговая среда, куда задачи заливались после прохождения ревью кода. Здесь тоже могут быть разногласия, что сначала курица или яйцо qa тестирование или проверка кода, но у нас сначала проверка кода, затем тестирование.
В нашей команде ~25 разработчиков по всему миру, говорящие не только на русском и английском, поэтому первое переживание — изменение флоу, чтобы поняли все.
Обсуждение любого изменения нужно провести во всех командах. Нужно запланировать на это время. Коммуницирование изменений частая проблема. Если понятно тебе, не значит, что понятно всем!
Лучше иметь пару недель на ошибки, потому что во время любого созвона разработчики сидят в своих задачах, могут не услышать. Любой отсутствующий на митинге обязательно будет делать ошибки, даже если ты видос записала и задокументировала. Одно дело новые колонки, а вот если движение задач по доске будет требовать дополнительных лейблов (кроме колоночных), то бригаду придется высылать не раз.
Второе переживание — работа с «паровозами». Так мы внутри команды называем связанные друг с другом задачи, которые логично толкать вместе или в определенной последовательности.
Наша команды работают с большими фичами (самыми сложными на проекте). Отдельно это здесь отмечаю, потому что при изменении флоу клиент опирался на нужды своих внутренних команд, которые не работают, к примеру, с вычислениями. Сложные фичи переходят нам. Наши эпики могут содержать 50 и более задач. Таким образом, для какой-то части функционала в develop по доске двигается не одна задача, а к примеру 5–6–7.
Сложность при работе с Эфемерал в том, что каждая задача несет в себе лишь часть изменений. Для простоты моего рассказа — к примеру, в одной задаче сама таблица, а в другой возможность дополнительной загрузки данных из эксель.
Таким образом, и ты, и qa специалист, и клиент должны четко понимать, что в каждой задаче. Это не просто.
Все должны знать — в какой задаче ты тестируешь таблицу, в какой загрузку темплейта, в какой то, как темплейт считает этот конкретный корнер кейс и так далее. Обсуждений с клиентом о том, что это будет сделано «вон там», а оно «еще не доехало» будет много и долго. А эпиков — не один. Нужно много держать в голове.
В обычном тестовом окружении, если задача в колонке, то функциональность будет работать не важно из какой задачи смотреть.
Третье переживание — Эфемерал создается от develop, который постоянно меняется. Таким образом, Эфемерал — динамичная среда. И фича, которая работала вчера в Эфемерал, сегодня, если разработчик отребейзится от develop может уже не работать. А если не настроены сервисы логгирования и отлеживания ошибок из Эфемерал, придется втроем с qa специалистом и разработчиком перебирать варианты причин. И это выбесит.
И последнее и самое важное — никто не любит изменений, что бы они не говорили. И не важно какой у них change agility. Поэтому такое большое изменений как переход на Эфемерал обязательно повлечет за собой стресс для твоей команды. Нужно быть готовым отвечать на вопросы, типа «нафига сломали нормальный процесс» и «почему нельзя все оставить как было».
Но использование Эфемерал ведет к снижению показателя cycle-time, что для нашего проекта очень важно. Мы в начале нашего пути, а «как будут развиваться события, вновь покажет время…». Я поделюсь.
