Ускорение Time to Market: Опыт «М.Видео»

Александр Садыков, заместитель руководителя отдела тестирования «Инфосистемы Джет»

В прошлый раз мы рассказывали о том, какие преимущества дает ускорение Time to Market и какие финансовые потери несут компании из-за архаичных процессов разработки. Сегодня мне хотелось бы подробнее раскрыть наш практический подход к оптимизации процессов, а также поделиться опытом одного из крупнейших российских ритейлеров – компании «М.Видео – Эльдорадо».

Три года назад наша команда совместно с «М.Видео» начала внедрять подход непрерывной интеграции в процесс разработки у ритейлера, и сегодня мы продолжаем его развивать. Он не ограничивается только применением современных технологий DevOps и автоматизации тестирования. Это скорее комплексное решение по систематизации всех процессов в разработке и изменению отношения к ним вовлеченных сотрудников.

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

Ускорение Time to Market помогает компании быстрее выпускать обновления и экономить на фонде оплаты труда (ФОТ). Например, простая автоматизация сборки и регрессионного тестирования может сократить смету проекта до 10%, а если вы решите автоматизировать подготовку тестовых данных, дополнительная экономия может достигать 12%. Но это еще не все. Критически важные изменения необходимо выпускать вовремя. Это необходимо для того, чтобы быть первыми на рынке с новыми идеями, быстрее других предлагать инновационные сервисы и, конечно же, максимально оперативно исправлять ошибки.

На практике ускорение Time to Market происходит за счет полной автоматизации процессов внутри компании. Я бы выделил четыре необходимых элемента, которые помогают нам ускорить Time to Market для клиентов:

• В компании должен быть четко выстроен процесс разработки и межкомандных коммуникаций. Решение этой задачи нередко становится отдельным проектом из сферы консалтинга.
• Необходимо внедрить и начать использовать полностью автоматизированный конвейер CI/CD по доработке кода (включая функциональное, автоматизированное и нагрузочное тестирование).
  
• Нужно обеспечить прозрачность получения результатов тестирования для заказчика. Для этого создаются ТМС, онлайн-дашборды, проводится регулярный репортинг.
  
• Наконец, требуется четко и неукоснительно поддерживать актуальность базы знаний о проекте и обеспечить необходимые инструменты и механизмы для ее актуализации.
  

«М.Видео» – крупный федеральный ритейлер с более чем 60 различными информационными системами: от решения для управления складом или цепочками поставок до ERP и корпоративной CRM. На примере интернет-магазина мы расскажем, как компания трансформировала разработку и тестирование нового функционала.

Что же сделали в «М.Видео» с разработкой? При участии внешних экспертов в компании была внедрена совершенно иная практика сборки релизов, регрессионного тестирования и выпуска обновлений. Так, например, разработка перешла со Scrum, то есть спринтовой модели, на Kanban, когда проверка на совместимость происходит по мере готовности каждого мелкого изменения (мердж по готовности) и никому не надо никого ждать. Благодаря этому удалось сократить процесс регрессионного тестирования на три дня.

Кроме этого были автоматизированы процессы тестирования – создано более 900 сценариев, по которым происходит проверка функциональности сайта после публикации каждого обновления. Благодаря приоритизации тестов команде удалось полностью исключить наличие в релизах блокирующих ошибок, которые мешают работе сайта, и критически важных ошибок (таких, как сбои в работе фильтров товаров), а также обеспечить автоматическую проверку корректности отображения всех элементов веб-страниц.

Следующим этапом стала унификация методологии тестирования. Цель была достигнута с переходом на Gherkin. Да, это стандартный BDD-подход, когда сложную работу по автоматизации выполняет малая часть высококвалифицированных сотрудников, а один скрипт во множество нужных сценариев превращают обычные ручные тестировщики. С этого момента стало намного проще создавать сценарии автоматизированной проверки, которых становится все больше. Появление новой критичной ошибки сразу влечет за собой ее занесение в регрессионный сет, исключающий возникновение подобного сбоя в будущем. Так получилось победить проблему багов-бумерангов, возникающую из-за множественности веток, когда разработчик, в спешке исправляя продуктивную проблему, забывает распространить это исправление на все актуальные ветки кода.

Разбивка функционала на блоки и постоянная проверка взаимосвязей между компонентами также дали свой эффект. Стало понятно, на каких наиболее проблемных блоках нужно сосредотачиваться и чему следует уделять особое внимание в условиях нехватки времени.

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

• Длительность регрессионных тестов сократилась до 4 дней (вместо прежних 10).
• На 50% уменьшилась команда ручного тестирования.
  
• С 30-35 до 25 дней сократилась продолжительность Time to Market – с момента поступления фичи в бэклог команды до ее выхода на пилот.
  

Опыт показывает, что невозможно сразу «стать ИТ-компанией», а сокращение Time to Market нужно реализовывать постепенно на каждом отдельно взятом участке. Если начать с самых «болезненных» процессов, а также четко расставить приоритеты, оценить сроки и риски, составить план реализации и привлечь экспертов, можно достичь впечатляющих результатов в короткие сроки.

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

На подобных проектах внедряются методологии ускорения разработки, в числе которых QA, CI/CD и DevOps. Они все ведут к сокращению затрат, но приводят к изменениям в работе специалистов. Поэтому для каждого сотрудника нужно предусмотреть свою мотивацию, которая будет стимулировать его работать в новых условиях лучше, а не саботировать внедрение новых подходов.

Есть еще один момент. Иногда компании просто не хватает специалистов, чтобы решить какую-то срочную задачу или исправить внезапно появившуюся ошибку – нужна почти мгновенная возможность быстро расшириться, а затем сократить команду. Понятно, что в таких условиях держать штат без работы никому не интересно. Например, никто не будет держать в штате дорогостоящего специалиста по Erlang, ModBus или Clojure. Гораздо удобнее привлечь такого эксперта из компании-партнера. А для этого необходимо выстроить полноценное сотрудничество и даже интегрировать команды разработчиков, обеспечив постоянный обмен опытом.

Чтобы читатель не подумал, что мы здесь шутки шутим, приведу в пример небольшое демо, записанное одним из DevOps-архитекторов нашей команды.

На видео происходит автоматическое тестирование нашего собственного продукта. Производится запуск UI и API автотестов в системе CI/CD Jenkins.

В консоли отображаются докер-контейнеры, которые стартуют внутри тестовой инфраструктуры.

В Web-интерфейсе Jenkins можно наблюдать логи сборки тестового проекта. С помощью Selenoid UI виден ход выполнения UI-тестов прямо в браузере с помощью технологии VNC. По результатам прогона UI и API-тестов формируется Allure-отчет, и экспортируются результаты прогона в тест-менеджмент систему TestRail.

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

• экономия времени;
• разработчик не пишет новый код в код с дефектами;
  
• не нужны ресурсы администратора для установки сборок на стенд;
  
• процессы сборки, установки и тестирования более предсказуемы и воспроизводимы;
  
• освобождаются человеческие ресурсы для выполнения более «творческих» задач;
  
• имеется прозрачная отчетность о результатах тестирования;
  
• разрабатываемая система становится пригодной для дальнейшего внедрения практик CI/CD и DevOps.
  

Повышение прозрачности работы новых направлений, а также прибыльности онлайн-бизнеса часто скрывается в оптимизации типовых узких мест, таких, например, как распространенная проблема объединения веток кода в релизную в последний день перед началом приемочного тестирования (это и было одним из краеугольных камней успеха оптимизаций в интернет-магазине «М.Видео»). Автоматизация проблемных процедур приводит к снижению количества ошибок и уменьшению трудозатрат. А аудит процессов разработки позволяет найти те этапы, на которых вы теряете больше всего времени и денег, и начать модернизацию именно с этих участков.

Первые 2-3 месяца вы не увидите радикального снижения расходов, потому что вам придется одновременно и поддерживать старый процесс внесения изменений, и внедрять новый. Сначала затраты будут даже расти, но за счет автоматизации самых неэффективных процессов через полгода обычно происходит окупаемость инвестиций – ускоренный Time to Market начнет приносить прибыль.

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

• Прежде чем запускать полномасштабные модернизации, начните с чего-то небольшого и самого критичного. Для этого полезно бывает собрать команду экспертов и оценить риски, ожидаемые результаты, сроки и стоимость проекта.
• Не пытайтесь все решить своими силами. Если сотрудники и так загружены рутинными процессами, на поддержку нововведений у них просто не будет времени – вам определенно нужны будут подрядчики, которые разбираются в вопросе ускорения Time to Market. Ведь первое время работы будет только больше.
  
• Следите за тем, чтобы команды были интегрированы между собой. В случае, когда на проекте работает несколько подрядчиков, нужно обеспечить их взаимодействие и координацию. Иначе вы можете получить новые проблемы, связанные с несогласованностью действий.
  
• Если применимо – планируйте переход от каскадных моделей разработки, привыкайте работать по схеме Agile-спринтов. Это поможет обеспечить эффективное взаимодействие всех команд – как собственных, так и приглашенных со стороны партнера.
  
• Следите за тем, чтобы команды могли отслеживать свой прогресс. Для этого необходимо предусмотреть прозрачные метрики, которые легко собирать и контролировать. Лучше всего, если статистика и основные индикаторы по проекту обновляются автоматически.
  
• Четко распределяйте роли. Никто не должен отвечать за чужую работу. Идея agile-разработки в том числе подразумевает отсутствие конфликта интересов, так что избегайте совмещения ответственности, например, в сфере разработки и тестирования.
  
• Предусмотрите мотивацию для всех участников процесса. Саботаж будет, поверьте нашему опыту. Важно сделать так, чтобы личная выгода перевешивала желание «послать все это к черту».
  
• При подготовке и во время работы следите за теми процессами, на которых возникают ошибки и простои. Анализируйте их и собирайте статистику. Ведь именно эти процессы нужно будет автоматизировать следующим шагом.