Как разрабатывали решение для фарм-лидера
По словам Виталия Янчика, для него, как тимлида, самым большим вызовом на проекте был его впечатляющий масштаб, необходимость управлять одновременно несколькими потоками разработки и очень сжатые сроки.
Одним из основных вызовов проекта все участники команды называют коммуникацию с клиентом: ведь офисы Allergan расположены в разных странах, в разных часовых поясах.
Рассказывают
Виталий Янчик, тимлид веб-разработчиков,
Остап Спильчук, senior веб-разработчик
Денис Данчук, frontend-разработчик и лид направления на проекте,
Константин Черняхович, QA-лид и Михаил Мади, QA-инженер
Часть команды Astound Commerce в офисе Allergan, Калифорния
Затрудняло ситуацию и то, что со стороны заказчика не было единого product owner и по некоторым вопросам сразу пятеро человек из разных отделов принимали решения. Из-за чего иногда случались недопонимания и искажения в передаче информации.
«У нас была очень сложная логика с поставками. Бизнес-аналитики красиво ее расписали в документации, зафиксировали все черным по белому, клиент все одобрил. Правда, уже через четыре месяца после того, как мы эту фичу отдали и даже запустили с ней один сайт, клиент сказал, что мы все неправильно поняли и надо переделывать», — рассказывает Остап Спильчук.
Еще одной сложностью было то, что сначала проект обсуждали как lift and shift: есть уже устаревший существующий сервис, нужно просто поменять платформу и добавить ему пару фич. В процессе работы оказалось, что нужно переделывать полностью все.
До этого проекта компания разрабатывала в основном b2c-решения на платформе Salesforce Commerce Cloud, а в этом случае проект должен был быть фактически написанным заново кастомным решением и у платформы не было готовых решений из коробки.
По оценкам тимлида и фронтенд-разработчиков, порядка 80-90% проекта пришлось писать с нуля, что требовало дополнительных усилий по разработке подходов и архитектуры реализации.
И это приходилось делать быстро: «Очень стрессовые таймлайны: все нужно было делать на вчера, архитектура проекта должна была позволять разработку во многих тредах одновременно. Важно было, чтобы код масштабировался. Плюс, постоянный поток change requests, которые нужно вносить на ходу, — вспоминает Остап. — Гибкость разработки для бизнеса — это, может, и круто, но с точки зрения разработчика, — это постоянный поток новых требований, когда все меняется на ходу и нужно быстро переключаться».
В целом, на разработку проекта ушло порядка 55 000 часов работы команды.
«Лично для меня процесс реализации Allergan Direct был очень интересным как в целом, так и с точки зрения QA-процессов и управления QA-командой. Не было такой части проекта, где бы не пришлось сделать хоть какую-то адаптацию под его особенности, — комментирует Константин Черняхович, QA-лид.
Чтобы обеспечить должное качество, команде нужно было справиться со многими сложными вызовами. Основные из них — это зависимости и изменения.
Одним из таких вызовов для QA-команды стало тестирование незавершенных компонентов. С целью непрерывности процесса разработки и одновременно возникших зависимостей (незавершенная разработка API со стороны клиента или уточнение требований с клиентом), команда контроля качества начинала тестирование компонентов до завершения их разработки.
Решение о таком подходе принималось после согласования возможных рисков выполнения или невыполнения такого тестирования. При этом, важно было понять:
Что именно не завершено в компоненте;
Какие зависимости это порождает для процесса тестирования;
Как можно выполнить тестирование, связанных элементов/саб-компонентов, исходя из зависимостей между ними;
Учесть все и донести в команде так, чтобы не тратилось время на тестирование того, что не было завершено на этапе разработки.
В свою очередь, это все оказывало влияние на сроки и трудозатраты в виде дополнительных коммуникаций QA-команды с веб-разработчиками и усилий со стороны QA-инженеров, которые выполняли такое тестирование.
На самом деле, изменения в проектах по разработке — больше норма, чем особенность, если только их можно организовать в управляемый процесс. В случае с Allergan Direct этот процесс не работал. Объем проекта диктовал свои сложности, связанные с изменениями.
При количестве тест-кейсов на уровне 5000, изменение в системе на 1% потенциально приводило к изменению примерно 50 тест-кейсов, что требовало частичного или полного переписывания и повторного выполнения этих тест-кейсов. Важно было оценить потенциальное влияние изменений на другие части системы, оценить, какие тест-кейсы стоит отобрать для регрессионного тестирования, чтобы это не привело к ухудшению качества на уровне части системы.
Особое место занимали «поздние изменения» в системе. «Когда изменения вносились в проект фактически на этапе перед самым запуском в продакшн, тестировать приходилось на лету с учетом возможных рисков влияния на качество системы», — рассказывает Михаил Мади.
Иногда, изменения происходили без участия QA-команды в системе клиента, с которой выполнялась интеграция. «Мы отсылали результаты тестирования клиенту после каждой итерации. Но на стороне Allergan параллельно длилась разработка их внутренних сервисов. Из-за изменений в их интеграциях часто некоторые функции приходилось перетестировать по новой», — дополняет QA-инженер.
Бывало так, что в процессе работы над изменением, приходило еще одно на те же функции и все тестирование приходилось начинать заново.
Зависимости и изменения на проекте привели к необходимости адаптации лучших практик по обеспечению качества и их интеграции в существующий процесс на разных уровнях. В результате, качество выпущенного продукта оказалось на достаточно высоком уровне.
Активный отдых во время командировки в Калифорнию
Несмотря на то, что команде пришлось справляться со многими вызовами в процессе, она оценивает его как очень удачный. «Мы практически вписались в таймлайн и запустились вовремя: для проекта такого масштаба — это большой успех», — отмечает Виталий Янчик.
«У нас — поздний вечер, у них — еще раннее утро. Нужно было перекраивать личный график и работать по вечерам: с утра работаем с командой, в течение дня согласовывали огромное количество артефактов и планы действия, вечером — передавали их клиенту. Но не в виде сухой документации, а проводя видеоколлы по часу, по два. Мы обсуждали каждую мелочь», — вспоминают разработчики.
Не обошлось и без овертаймов, так, во время поездки в офис заказчика или перед запуском сайта работали по 10-12 часов в сутки.
«Это был проект для тех, кто не любит рутину, любит челленджи и каждый день покорять новые вершины. Тебе прилетает задача и нагуглить ее решение ты не можешь, ведь до тебя этого никто не делал. Необходимо придумывать решения и это все — в жесткие сроки», — подытоживает Остап Спильчук.