Всем привет! Меня зовут Мария Абросимова, я куратор продуктовых команд в SM Lab и отвечаю за развитие и поддержку компетенций системных аналитиков, а также внедряю новые рабочие инструменты, подходы и технологии.
Сегодня я расскажу вам о том, что такое параллельная разработка, поделюсь опытом её внедрения в нашей компании и дам несколько практических советов.
Звучит страшно. А что на самом деле?
Впервые о параллельной разработке мы заговорили, когда столкнулись с необходимостью быстро адаптировать продукт под внешние изменения. В основном это происходило в следующих случаях:
при изменениях в законодательстве, когда нужно срочно перестраивать систему, чтобы соответствовать новым требованиям;
при необходимости не отставать от рынка или обгонять конкурентов: например, внедрив новую систему оплаты раньше других и получив бизнес-выгоду.
Чтобы обеспечить нужную скорость изменений, мы стали искать новый подход к разработке и, изучив процессы международных технологических компаний, нашли подходящий вариант — параллельную разработку. Перед нами встала серьёзная задача: взять её основу и адаптировать под специфику нашей компании.
Стандартный процесс разработки происходил следующим образом: первым брал задачу в анализ Бекенд (Бек), потом передавал её на разработку. Далее контракт переходил к Мидлваре (Мидл), который совершал те же самые действия, после — к двум Фронтам (сайту и мобильному приложению). Такой последовательный подход, при котором каждая команда ждет завершения задачи предыдущим участником, не только растягивает сроки, но и создаёт риски.
Несмотря на наличие ADR и других артефактов, формализующих требования, на практике всё равно возникали частные случаи: например, когда в процессе реализации у Фронта появляются уточнения или изменяются макеты, которые влекут за собой изменения контракта с Мидл Офис, а иногда и Мидл Офиса с Беком. В результате ошибки могли всплыть уже на этапе комплексного тестирования, когда вносить изменения особенно затратно.
Нам хотелось изменить этот процесс.
Мы по-прежнему работаем с теми же системами — Бек, Мидл, Сайт и Мобильное приложение, — но теперь стремимся к тому, чтобы анализ, разработка, согласование контрактов и тестирование шли параллельно. Когда контракт согласовывается таким образом изначально, все команды сразу знают, чего ожидать от этой фичи, поэтому неожиданные сюрпризы в конце комплексного тестирования не появляются, а также увеличивается качество работы.
Так мы пришли к трём ключевым причинам для перехода на параллельную разработку:
работаем одновременно — минимизируем простои и ускоряем цикл;
ясные договорённости – единое понимание требований с самого начала;
раннее тестирование и снижение рисков – проблемы выявляются до этапа комплексного теста.
Чтобы реализовать параллельную разработку и снизить риски, мы внедрили два главных инструмента:
подход Contract First («контракт сначала») – это когда команды договариваются между собой, на каком контракте они будут работать, и только после этого каждая отдает в разработку свою часть. Согласовывает контракт как поставщик контракта, так и потребитель – без этого он считается недействительным. Такой порядок исключает недопонимание и позволяет всем двигаться параллельно, опираясь на четко зафиксированные ожидания;
заглушки WireMock, которые позволяют разработчикам и тестировщикам начинать работу даже при отсутствии готовых интеграций. Это особенно ценно, когда одна из сторон ещё не завершила свою реализацию: остальные могут продолжать работу, используя эмуляцию поведения контракта.
Внедрение Contract First и WireMock стало для нас основой перехода к параллельной разработке, но сами по себе инструменты – это ещё не процесс. Чтобы действительно встроить этот подход в повседневную работу команд, мы выделили пять ключевых шагов, которые помогают нам работать синхронно и эффективно:
разбить фичи на независимые логические блоки, чтобы было понятно, какие части можно реализовывать автономно;
определить параллельные задачи и посмотреть, насколько они действительно могут запараллелиться;
назначить ответственного за каждый выделенный кусочек;
согласовать формат взаимодействия (чаты, статусные созвоны и т.д.);
организовать тестирование на WireMock, иначе не получится запараллелить разработку. Если в процессе тестов выявляются несовпадения, WireMock помогает увидеть это на раннем этапе. Разработчики или аналитики могут быстро внести правки, и команда не теряет время в конце спринта. Более того, это позволяет гибко тестировать различные сценарии и делать комбинаторику: менять входные параметры, последовательности шагов и сразу видеть результат.
Внедрение процесса
Внедрить новый подход в компанию было достаточно сложно в связи со следующими особенностями рабочих процессов:
планирование на три месяца. У нас инкрементальное планирование, в котором участвуют не только бизнес от «Спортмастера», но и O′STIN, Funday и наши монобренды. Для разработки общего плана приходится учитывать множество факторов, и, если мы будем внедрять параллельную разработку, не получится так в моменте взять и сказать «Вот эту фичу я буду реализовывать быстро» – нам нужно тоже суметь запланироваться на три месяца;
приоритетность других задач. В рамках одной фичи задачи распределяются между Бекендом, Мидлваре и Фронтендом. При этом у разных команд может быть разная степень важности этой задачи: для Бекенда она может быть приоритетной и выполняться быстро, а для Фронтенда – менее важной и отложенной. Без согласования и выравнивания приоритетов между командами параллельная разработка не сможет работать эффективно, т.к. одновременное выполнение всех частей будет затруднено;
несколько фронтов с разным функционалом. Например, функционал «Корзина» внедрен на сайте «Спортмастера», O′STIN, Funday и в наших мобильных приложениях, однако в каждой версии имеются свои отличия по логике и возможностям. Команды Мидл-офиса, которые работают с этими фронтами, должны согласовывать общий контракт, учитывая различия в логике и функционале каждого из них, чтобы изменения работали корректно у всех;
разные инструменты и подходы. Из-за различий в инструментах и методологиях согласование часто затягивается.
Процесс с учетом особенностей
Итак, у нас есть фича и ADR (Architecture Decision Record – архитектурные решения). Бек, Мидл, сайт и МП должны запараллелиться, для чего в ADR и в Jira на задачи мы ставим метку «Параллельная разработка». Также устанавливаем высокий приоритет: мы договорились с руководителями и согласовали процесс, по которому задача параллельной разработки идет с наивысшим приоритетом, благодаря чему команда может запланироваться параллельно. Обычно это происходит в начале вышеупомянутых трех месяцев. Далее каждая система разрабатывается по своему продукту.
Согласование контрактов разными командами
С нашей особенностью согласования несколькими командами мы придумали такую вещь, как соглашение о контракте – некий документ, закрепляющий следование контракту, его неизменяемости в течение разработки, единую дату согласования (что особенно важно для аналитиков) и дату окончания (EndDate).Это избавляет нас от бесконечного круга переделывания контрактов до тех пор, пока все не скажут свое «ок».
Соглашение состоит из четырех частей, основная из которых – таблица согласования. В первой строке у нас идет поставщик контракта, далее идет ссылка на контракт (контракт предоставляется в любом виде о котором договорились), контактное лицо, к которому можно обращаться по этому контракту для того, чтобы что-то там изменить или спросить, и кто согласует этот контракт. В результате у одного контракта зачастую могут быть несколько согласовывающих и все они должны поставить метку Approved. При успешном согласовании ставится общий Approved в последнем столбце. Только после этого все аналитики участвующие в согласовании могут передавать свои контракты разработке – до этого нельзя.
Три другие части, из которых состоит соглашение:
сценарий возможного использования;
календарные работы по контрактам для удобства;
договоренности и открытые вопросы, которые тоже фиксируются в этом соглашении (что-то вроде протокола встреч и переписок).
Соглашение о контракте фиксируется в Confluence и лежит рядом с ADR.
Проработав аналитику, нужно было подумать, что делать с разработкой: она тоже должна идти параллельно. Тут уже работаем с WireMock.
В результате у нас появилась схема процесса, на которой хорошо видно параллельность разработчиков, аналитиков и тестировщиков.
Этапы процесса
Обсудим подробнее каждый этап процесса.
Первый этап: отбор фичи. Приходит бизнес и говорит: «Мне нужно срочно вывести фичу – у нас есть идея на миллион!» Далее рабочая группа, ответственная за планирование, отбирает фичу, присваивает ей высокую приоритетность, ставит в Jira метку «Параллельная разработка», обязательно проверяет состав работ, архитектурное решение по этой фиче. Архитектор ещё раз валидирует решение и, если есть недочеты, снимает метку «Параллельная разработка».
Критерии снятия следующие:
нельзя запараллелить работу;
слишком сложная фича.
Далее дорабатывается ADR под разработку на контракт, выделяется отдельный чат для согласования, добавляются PL-и продуктов и аналитики. Метка «Параллельная разработка» сохраняется.
Второй этап: создание задач на контракт. Каждая команда создает отдельные задачи на контракт, сохраняя метку «Параллельная разработка». Также мы придумали лично для себя сделать префикс [Contract], чтобы через поиск Jira, JQL-запросы можно было легко отследить эти задачи.
Далее согласовываем EndDate; если договориться не получается, то это, как правило, решается тем, что мы поднимаем приоритет эпикам у команд.
Третий этап: проектирование и согласование контракта. Аналитик команды поставщика прорабатывает контракт, оповещает об этом команды через чат, заводит и заполняет соглашение о контракте, и аналитики потребителей проводят анализ контракта. Если его что-то не устраивает, он говорит об этом в чате либо пишет замечания в соглашение о контракте и, соответственно, меняется контракт аналитика поставщика. Он ещё раз запускает согласование контракта со всеми командами потребителя контракта. И так по кругу несколько раз, пока контракт не будет согласован.
Как только контракт будет согласован со стороны одного аналитика потребителя, переходим чуть дальше и указываем Approved в последнем столбце. После того, как приходит согласование от всех команд, задача закрывается прежде всего потребителем контракта, и только после этого поставщиком контракта. Такой порядок установлен потому, что если поставщик поспешит и закроет свою задачу, а потребитель скажет «Ой, мне тут нужно что-то где-то исправить», у поставщика уже не будет аналитика на правку контракта, т.к. он будет занят другой задачей. Именно поэтому важно соблюдать данное правило.
Четвертый и пятый этапы: реализация и подготовка и контрольный тест (КТ). После того, как аналитик провел свою огромную работу по согласованию контракта, он договаривается с другими командами будет ли ставиться feature toggle. Затем разработка и тестирование реализуют функционал, а после этого проводят предварительную встречу по комплексному тестированию, где договариваются, в какое единое время снимается фича тоггл. После ее снятия можно приступать к комплексному тестированию.
Результаты
Итоги параллельной разработки показали хорошие результаты. Мы оценивали их по следующим параметрам:
lead time (время выполнения) снизился в среднем на 30 рабочих дней (обращаю ваше внимание на то, что это именно рабочие дни, без учета выходных) – это достаточно много для нашей компании и
очень хороший результат;
количество дефектов во время комплексного тестирования сократилось практически до нуля;
неожиданный бонус: скорость принятия решений между командами выросла даже после того, как мы вернулись к последовательной разработке.
Рекомендации
Чтобы провести предварительную подготовку и убедиться, что у нас может сработать параллельная разработка, мы потратили около полугода и выяснили, что для успешного старта нужно:
оценить текущие процессы в компании и понять, насколько параллельная разработка подходит именно вам;
согласовать формат взаимодействия между командами – у нас, например, это соглашение о контрактах;
запускать пилот всегда, причем начать с одной фичи и далее масштабироваться. Мы действовали в два этапа: сначала тестировали на самых простых ADR, собирали обратную связь, а потом корректировали процесс, чтобы получить наиболее эффективный результат. Результат, кстати, нужно обязательно оценивать: плохой результат – это тоже результат. Он либо говорит о том, что параллельная разработка вам не подходит, либо выявляет узкие места, которые надо улучшать;
работать прежде всего с людьми, а не просто командами: наглядно покажите выгоды, которые они получат, обсудите роли и зоны ответственности, будьте всегда на связи. Контролируйте, как идет работа по пилоту, и поддержите команды в моменте, стандартизируйте артефакты (таблицы, контракты, документации). При необходимости привлекайте экспертов и организуйте обучение для успешного внедрения: например, в некоторых случаях мы обучали разработчиков работать с WireMock.
Параллельная разработка точно не подойдет вам, если:
ADR и макеты плохо проработаны или вовсе отсутствуют на момент, когда команды начинают работу над задачами;
недостаточно данных по задачам от бизнеса;
ваши команды не работают по единому процессу и стандартам планирования.
Даже если параллельная разработка не сработает идеально с первого раза, она позволит выявить проблемные места в процессе и своевременно их устранить, чего не получится в ходе последовательной разработки.
Типичные проблемы, которые параллельная разработка помогает выявить и решить:
несогласованность требований: разные команды по-разному понимают задачи, что становится очевидно уже при согласовании контрактов, а не только на финальном тестировании;
изменения макетов и требований в ходе разработки: например, Фронт меняет дизайн, а Бек не успевает подстроиться, или наоборот;
разные приоритеты у команд: задачи одной фичи движутся с разной скоростью из-за несогласованных приоритетов;
отсутствие единого стандарта взаимодействия: использование разных инструментов и подходов замедляет коммуникацию и согласование;
проблемы в коммуникации между командами: затягивание согласований, недопонимание ролей и зон ответственности;
технические ограничения и ошибки в контрактах: они выявляются быстрее при использовании заглушек и контрактного подхода.
Если у вас много команд, вы часто сталкиваетесь с ожиданиями и простоями — попробуйте. Начните с одного пилота, с простой фичи, понятного контракта. Попробуйте администрировать эту параллельную разработку и посмотрите, что у вас из этого получится — это рабочий инструмент, которым можно пользоваться в разных случаях.