Если командная работа не слажена, будут постоянные столкновения между отдельными людьми и целыми командами, а продукты компании или микросервисы в рамках одного продукта будут мешать друг другу при использовании общих ресурсов и инфраструктуры.
Результатом будут постоянные срывы, конфликты и снижение темпа работы.
Быстрые и предсказуемые релизы в таких условиях будут недостижимы.
Меня зовут Виктория Дежкина, я занимаюсь тестированием в отделе разработки и поддержки продуктов больших данных X5 Retail Group. Расскажу, как мы изменили процесс тестирования в одной из наших продуктовых команд, чтобы ускорить подготовку релизов почти вдвое и избавить команду от стресса.
Сейчас мы реализуем такой подход к тестированию в других продуктах компании.
В дирекции больших данных X5 Retail Group сейчас разрабатывается 13 продуктов, 4 из которых находятся в отделе монетизации, где продукты ориентированы на внешний рынок, и любая ошибка, будь то дефект продукта или поздно выпущенная функция, имеет экономический эффект и приводит к потере клиентов.
По сути, это внутренние команды, которые зарабатывают деньги на внешнем рынке и играют по правилам малого бизнеса внутри крупной компании.
Все наши продукты существенно различаются по своим целям и поэтому требуют разных подходов к разработке и тестированию, но у них много общего: они используют одну и ту же инфраструктуру (Kubernetes, Greenplum, тестовые серверы), а разработчики из разных продуктовых команд иногда заменяют друг друга.
другие на время отпуска.
В такой ситуации резко возрастает роль соглашений: если одна часть команды не знает, что делает другая, и в каждой команде действуют свои правила, неизбежно возникнут проблемы.
Например, два продукта используют одну и ту же инфраструктуру нагрузочного тестирования, и обоим срочно необходимо запустить тесты.
Не уведомляя друг друга, они делают это одновременно и в итоге получают ложные результаты, потому что СУБД «спустилась», причем непонятно из-за кого.
Мы хотели сэкономить время на переговорах, но в итоге потратили кучу времени без каких-либо результатов.
Также возможна потеря данных.
Допустим, один из продуктов занимает бесплатный тестовый сервер, никого об этом не предупреждая.
Официально железо считается бесплатным, поэтому приходит другой продукт и случайно стирает все тестовые данные первого.
Это, конечно, не пользовательские данные, а всего лишь тестовые данные, но все равно довольно неприятный случай.
Работников может просто не хватить, если работы не планируются заранее.
Например, сейчас нагрузочное тестирование в нашей Дирекции работает в сервисном формате, то есть мы выделяем в команды соответствующего специалиста по запросу.
Если несколько команд без предварительного предупреждения придут требовать нагрузочное тестирование в один и тот же день, тестировщиков может не хватить на всех.
Думается, что самый простой выход в этой ситуации — установить единые правила взаимодействия для всех продуктов.
Но проблема в том, что все продукты разные.
Некоторые из них предназначены для внутренних пользователей, то есть специалистов других отделов компании, например, служб ценообразования или изучения спроса.
Другая часть разработана для внешних пользователей — например, для поставщиков.
У этих изделий совершенно другая логика архитектурных решений и критерии качества.
Продукты на разных стадиях готовности также не приемлют одинаковый подход: на раннем этапе, когда продукт тестирует идеи, приоритетом является понятность функционала для пользователя и отсутствие угроз корпоративной безопасности.
Когда продукт поступает в поддержку, на первое место выходят другие требования: удобство пользователя, стабильность существующего функционала, скорость реагирования на дефекты и полное соответствие корпоративной политике безопасности.
Эти два фактора – совместная работа на одной территории и уникальные особенности продукта – поставили нас перед задача: разработать правила, которые позволят командам не мешать друг другу, но в то же время не будут связывать тестировщиков и разработчиков по рукам и ногам и не будет сводить разработку разных продуктов к одному шаблону, отсекая все преимущества agile и продуктового подхода на корню.
Скажу несколько слов о том, почему тестировщики играют ведущую роль в создании стандартов взаимодействия в продуктовых командах.
Дело в том, что в силу специфики нашей работы мы видим продукт целиком, тогда как разработчики обычно сосредоточены на одном небольшом участке.
Мы первые замечаем проблемы и предлагаем варианты их устранения, но окончательное решение разрабатывается совместно с разработчиками.
Мы уже писали, Как происходит эта коллективная работа? : на начальном этапе нам буквально приходится составлять единый словарь, чтобы не путаться в терминах.
Но это только начало.
Дальше нам предстоит согласовать массу разных нюансов.
Расскажу, как это произошло, на примере одного из наших продуктов — системы автоматизации закупок для торговых сетей.
Его задача — обеспечить работу всех процессов с момента возникновения у магазина потребности в определенных товарах и до момента их получения.
Какие процессы изменились в нашем продукте?
Когда мы пришли к продукту, релизы должны были выходить каждые 2 недели, но они почти всегда задерживались на несколько дней, а день релиза всегда означал, что мы обязательно опоздаем на работу и будем стабилизировать существующую версию до последнего.минута.
Что-то нужно было изменить.
Важно отметить, что изменения являются общей причиной.
Кто бы их ни инициировал, тестировщик или сами разработчики, без согласия всей команды и сильных союзников им не обойтись.
Любые изменения должны обсуждаться всей командой, чтобы собрать как можно больше идей и не упустить возможные риски.
Менеджер по доставке и продукту нашего продукта до меня систематически работал над улучшением процессов как с технической, так и с продуктовой стороны.
Когда я присоединился к команде, я посмотрел на процесс с точки зрения тестирования, и вместе мы разработали согласованную «стратегию изменений».
Первым пунктом в нем было изменение вёрстки кода.
Порядок расположения кода
Порядок расположения — одна из главных «болей» разработки команды, и проблемы здесь могут быть самые разные.Например, у команды есть только одна ветка кода, и исправления ошибок продолжаются там.
Либо веток несколько, но тестовая среда может одновременно содержать задачи с перекрывающимся функционалом; в результате тестировщики не смогут локализовать дефект или протестировать часть новых функций, заблокированных дефектом в одной из задач.
А про отчаянных разработчиков, которые не считают чем-то плохим быстро редактировать мелочи в продакшене, не предупреждая других, я вообще ничего не скажу.
Чтобы всего этого избежать, нам нужно было определить количество веток и сред, а также договориться о порядке, в котором будет выкладываться код для тестирования.
Проще всего было бы разделить процесс на две ветки с «чистым» и «грязным» кодом.
Но нам нужно было выполнить множество условий:
- Избегайте исправления одного и того же дефекта в разных задачах.
- Запретить выпуск непроверенных задач в производство при развертывании уже проверенных
- Получите возможность проверять задачи как «по одному», так и всю «сборку релиза»
- Организовать параллельный процесс тестирования и разработки.
- Возможность в любой момент увидеть, какие задачи готовы к развертыванию и какие задачи находятся в разных тестовых средах.
- Предоставьте разработчикам серверной и внешней части доступ к совместной разработке.
«Основная версия» содержит текущую версию продукта, а «релиз» содержит функции, готовые к развертыванию.
Тестирование происходит в Dev, здесь находятся готовые к тестированию задачи, разработка происходит локально.
Развертывание в каждую ветку происходит по согласованию с тестировщиком.
Так: 
Что это дало нам с точки зрения тестирования:
- Время, необходимое для тестирования каждой задачи в отдельности, сократилось на 20%.
Отпала необходимость запускать тестирование заново, если новая задача была выкатана на тест без предупреждения, новые задачи не блокировали тестирование уже выполненных, ускорилось время локализации дефектов.
- К запланированному дню совершения релиза непроверенными остались 1-2 задачи вместо 4 (то есть время на их проверку сократилось вдвое).
- Время интеграционного тестирования и тестирования релиз-кандидатов сокращено с 6 часов до 2 (включая повторное тестирование).
- Уменьшилось количество дефектов, обнаруживаемых на стадии релиза.
Раньше в первой версии релиза мы находили их более 10, а теперь не более 4. Время повторного тестирования сократилось на 2 часа.
- Появилась возможность продолжать разработку параллельно с тестированием.
Всего 2 часа обсуждения новой схемы работы с командой — и нам удалось сэкономить целый рабочий день, который раньше приходилось тратить раз в две недели.
Неплохо? Но проблемы остались.
- Разработчики потратили время на уведомление тестировщика о готовности задачи, отвлеклись и потеряли контекст задачи, когда нужно было выкатить ее на тестирование.
- На релиз-кандидате продолжали появляться ошибки, связанные с неравным развертыванием для тестирования, релиза и так далее.
- При таком подходе исправления в рабочей среде были возможны только сразу после развертывания.
- Не было понимания, когда и где проводить нагрузочное тестирование.
Мы снова собрались.
Некоторые проблемы были решены за счет уточнения процесса разработки и добавления CI: 
Автоматический развертывание на все среды мы настраивали почти месяц, но это дало ускорение времени почти на 2 рабочих дня.
Команда к этому шла уже давно, менеджер по доставке и сами разработчики этим занимались, но им пока не удалось добиться двух вещей: чтобы развертывание на все среды было единым и чтобы одновременно время возможность контроля версий будет сохранена.
Автоматический развертывание либо нарушал главный принцип тестирования «в любой момент времени тестировщик должен знать, что есть в каждой среде», либо тормозил разработчиков, которые не могли завершить разработку задачи без разрешения на выкатку на тест. Это трудная дилемма.
Если проигнорировать первый принцип, и вместо ускорения вы получите резкое снижение предсказуемости релизов и ошибочно выкачиваемых задач.
Например, если дефект исправляется совместно с «чистой задачей», то при выкатке исправленной задачи она обязательно отловит дефектную.
Поэтому вам придется либо ждать исправления дефекта в сопутствующей задаче, отложив дату релиза, либо переисправлять уже исправленный дефект. Автоматический выкат – это не человек, с этим нельзя согласиться.
Поэтому проблему с оставшимися ошибками мы решили другим способом – особым подходом к планировке, а затем добавлением еще одного стенда.
Планирование разработки и тестирования
Изначально при планировании мы с командой обсуждали, поняли ли разработчики задачу, сколько времени она займет и уложимся ли в спринт. Тестировщик оценил, сколько времени займет тестирование.При этом мы вообще не обсуждали ошибки, которые могли возникнуть: не предусмотрели их заранее и не включили в список возможных задач.
В результате, когда эти случаи возникали в процессе тестирования, они добавлялись в отдельную задачу, требовали времени на проработку и увеличивали объём релиза, а иногда даже обнаруживались только в релиз-кандидате, на этапе совместное тестирование задач, перенос развертывания на неопределенный срок.
Мы собрали трёх человек — тестировщика, доставки и продукта — и придумали новую схему взаимодействия.
Теперь мы проговариваем все возможные ошибки до начала разработки.
Пришлось стать скучным отличником, который на этапе планирования спрашивает обо всем и вся: «Что будет, если отвалится сторонний сервисЭ», «А что, если вместо 0 мы получим nullЭ», «А что если мы не получаем все данные? «А вдруг печенеги нападутЭ» и так далее, но теперь мы были готовы ко всему.
Также мы начали обсуждать, как именно мы будем реализовывать ту или иную задачу и как будем ее тестировать.
Это позволило сократить самодеятельность (изобретение всяких велосипедов, например) и дало каждому участнику команды понимание того, чем занимаются его коллеги.
Это, кстати, позволило отказаться от критериев приемки (АК).
Чтобы дискуссии в новом формате не стали слишком громоздкими, мы стали делать это не за 2 недели, а за неделю.
Новый порядок размещения кода и планирования задач был лишь первыми шагами.
В следующей части статьи, которая выйдет завтра, я подробно расскажу о том, как мы изменили ряд других процессов в команде:
- Формат постановки и принятия задач и дефектов: Мы отошли от пользовательских историй к более удобному для нас гибриду «вариант использования + техническая проблема».
- Тестовый момент: Мы установили 5 точек в цикле релиза, на которых тестировщики активно контролируют процесс создания продукта.
- Правила взаимодействия связки «бэкенд — тестирование — фронтенд»: Мы разработали схему, которая позволяла проверять все данные, которые передаются между бэкендом и фронтендом.
- Ускорение работ по исправлению дефектов: установленные правила о том, как расставлять приоритеты задач отладки, чтобы не отвлекать разработчиков без надобности.
Теги: #Управление проектами #инфраструктура #продукты #разработка #Большие данные #Управление продуктом #тестирование #тестирование ИТ-систем #автоматизация #продуктовое мышление #монетизация #большие данные #закупки #продукты #заказ загрузки #торговая сеть
-
Как Зарабатывать Деньги На Своем Блоге
19 Oct, 24 -
Речные И Прибрежные Суда
19 Oct, 24 -
Мы Живы - Что Пишут
19 Oct, 24 -
Канобувости, 47 Выпуск
19 Oct, 24 -
Османд — Руководство Пользователя
19 Oct, 24
