Как мы позволяем разработчикам разрабатывать, а не перерабатывать
Привет! Меня зовут Костя Карусев, я тимлид в одной из команд направления WMS (Warehouse Management System). В статье я расскажу, как выглядит наш процесс разработки, и как он помогает разработчикам заниматься своим делом и с чистой совестью отдыхать на выходных.
Отвечу на такие вопросы:
- почему мы не используем полноценный SCRUM;
- что такое feature-team и как эта концепция сосуществует с привычными командами;
- как отстроенные процессы помогают разработке двигаться предсказуемыми темпами, а разработчикам — не перерабатывать.
Над кодовой базой WMS работают три команды разработки — в общей сложности это 17 человек. Также у нас есть отдельная команда из пяти QA. За последние полгода мы завершили 8 крупных проектов, еще 8 находятся на стадии разработки либо активного внедрения. Кроме того, над мелкими изменениями с нами постоянно работают аналитики склада.
Команда большая, проектов много, но при этом я ни разу не слышал или не произносил фразу, что надо поработать на выходных или ночью, чтобы уложиться в очередной майлстоун.
Не SCRUM
Команда WMS не работает по полноценному скраму. В чем-то намеренно, а в чем-то стихийно мы пришли к той методологии разработки, которая хорошо подходит под наши текущие нужды.
У нас нет характерных для применения SCRUM быстро меняющихся требований, как и нет необходимости предварять проекты выпуском MVP. С другой стороны, мы ведем in-house разработку, а наши проекты расписаны и согласованы на несколько месяцев вперед. Поэтому мы работаем в относительно предсказуемом темпе и находимся в доверительных отношениях с бизнесом. Как следствие, во главу угла при разработке ставится не столько скорость, адаптивность или прозрачность ведения проектов, а глубина понимания системы, качество ревью и тестирования.
Разумеется, без накладок не обходится. Иногда отдельные разработчики горят проектом и работают больше, чем нужно. Но мы не приветствуем такого подхода, потому что у него есть минусы в долгосрочной перспективе: со временем от разработчика будут постоянно ожидать такого ритма работы и исходя из этого рассчитывать сроки проекта.
Концепция feature-team
Feature-team — это команда, которая выделяется под разработку конкретного проекта. Она состоит из техлида, нескольких разработчиков, QA и проджект-менеджера.
Как правило, роль техлида берет на себя один из тимлидов, который параллельно ведет несколько проектов. Им может стать и обычный разработчик, у которого есть необходимые хард- и софт-скиллы. Техлид отвечает за успешное техническое исполнение нового проекта. Его задачи: аналитика требований бизнеса, составление технического скопа и его разведение на отдельные задачи, а также контроль за выполнением и общим качеством написанного кода. Помимо проектных задач, тимлид отвечает за внепроектную разработку, помогает решать проблемы технического и околотехнического характера, отвечает за развитие членов команды и следит за общим настроением.
В большинстве случаев разработчики во feature-team набираются как раз из команды тимлида. Но у нас есть проекты, для которых feature-team формируется из участников нескольких команд. В такой ситуации сложнее организовывать встречи, потому что они не попадают в общий флоу командных активностей, но это решаемая проблема.
Еще одни важные участники feature-team — проджект-менеджеры. Они налаживают взаимодействие и синхронизацию между всеми участниками процесса, управляют потоком скоповых задач и зачастую выступают в роли второй линии поддержки. Еще они вычисляют копасити и прочие метрики и используют их для формирования спринтов.
С точки зрения разработчика, проджект-менеджер и техлид — это те люди, которые освобождают его от личных встреч по проектам и формируют четкое понимание того, что и когда нужно бизнесу. Их работа дает возможность посвятить максимальное количество времени написанию кода.
Распределение процессов
Наш скоуп задач состоит из технических и бизнес-задач, а также саппорта. При этом соотношение бизнесовой и технической части со временем растет. Сейчас на них уходит от 40–50% копасити, а на саппорт — всего около 10%. Остальное время мы распределяем на создание нового вэлью.
Внепроектные задачи и активности оцениваются на общей встрече и с учетом копасити разбиваются на двухнедельные спринты. За это время нужно выполнить то, что не входит ни в одну из feature-team.
Как правило, релизы привязаны к завершению фаз проекта. Однако не обходится и без внеочередных релизов, которые связаны с техническими исправлениями. Они обязательно проходят через все стадии ревью, а также автоматического и ручного тестирования. Основные релизы мы стараемся проводить по утрам с понедельника по четверг.
За релиз отвечает релиз-менеджер. Обычно это один из тимлидов — они меняются по очереди. Релиз-менеджер должен подготовить ветку к релизу, убедиться, что изменения соответствуют заявленному скопу, и провести сам процесс релиза.
Отдельно скажу о саппорте: его флоу управляют менеджеры, которые взаимодействуют со складом, а выполняют дежурные разработчики. Последние меняются раз в неделю. Также есть отдельная группа более опытных членов команды, обычно из сеньоров со стажем, которые готовы прийти на помощь во внерабочее время. Но обычно такие ситуации возникают максимум пару раз за смену, и именно такие задачи бывают самыми интересными.
Устроенный таким образом процесс разработки и доставки, с одной стороны, избавляет разработчика от внезапных саппортовых задач и снимает обязанности, связанные с управлением релизами. С другой стороны, в процессе ротации проектов между feature-team разработчики постепенно погружаются в технические особенности приложения и предметную область.
В завершение хочу подчеркнуть, что не люди служат для реализации процессов, а наоборот, процессы нужны для удобства организации работы людей в конкретной ситуации. Без людей, которые любят и умеют делать свою работу ни один, даже идеально выстроенный процесс, не будет функционировать.
