Привет! Меня зовут Костя Карусев, я тимлид в одной из команд направления 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 разработчики постепенно погружаются в технические особенности приложения и предметную область.
В завершение хочу подчеркнуть, что не люди служат для реализации процессов, а наоборот, процессы нужны для удобства организации работы людей в конкретной ситуации. Без людей, которые любят и умеют делать свою работу ни один, даже идеально выстроенный процесс, не будет функционировать.
onets
Не очень понятно — он что бизнес-аналитик? Или ему спускают готовое ТЗ (описание) и он анализирует именно это описание, чтобы разбросать по технической части?
А можно тут подробней рассказать? В саппорт прилетают различные вещи и для начала их надо идентифицировать (это бага, это надо инструкцию обновить, это мелкая доработка, это похоже на эпик, это пользователь тупой). И ведь кто-то этим должен заниматься. Таким образом, разработчикам будет уходить только часть этих тикетов. Мало того, порой непонятно бага это или фича и требуется время разработчика, чтобы глубже копнуть. А такие задачи кому уходят? Дежурным? Да и еще — бывают такие тикеты, что без поллитра не обойдешься, нужно еще привлечь бизнес-аналитиков и созвониться с пользователем.
И еще не понятен жизненный цикл feature команды в рамках проектов. Они что сделали проект и свалили (распались)? А кто поддерживать будет?
mrmagnus Автор
Тут слово «бизнес» использовано в довольно широком смысле: на стороне нашего заказчика (склада) есть отдельное организационная структура, которая отвечает за развитие технических процессов. Они являются «мостиком» между стейкхолдерами и командами разработки. На фазе анализа нового проекта или отдельной user-story они выясняют формальные требования, разрабатывают и описывают подход к решению на уровне бизнес-процессов. Кстати говоря, их функции не сводятся только к бизнес-аналитике: например помимо прочего они занимаются сопровождением внедрения.
Именно с этой командой в первую очередь взаимодействует техлид проекта — вместе они уточняют подход и прорабатывают детали с учетом понимания технической стороны вопроса, которе есть у техлида.
После этого техлид формирует пулл задач и начинается разработка.
Дежурные разработчики, разумеется, не выполняют роль первой линии поддержки. Проблемные ситуации сначала проходят через системных администраторов склада и/или через команду, отвечающую за развитие технических процессов, о которой я написал выше. На этом этапе отсекаются такие не относящиеся непосредственно к софту вещи как незнание должностных инструкций, проблемы с оборудованием и т.п.
Если первой линии решить проблему не удалось, задача попадает к нам: дежурный разработчик анализирует ситуацию с помощью логов, SQL запросов и кодовой базы.
В случае если проблема идентифицирована и имеет малый масштаб, ее правит сам дежурный либо в коде, либо отдав на выполнение соответствующий SQL скрипт, либо просто передав что надо сделать в рамках бизнес-процесса.
Если и у дежурного разобраться не получилось, либо речь идет о крупной проблеме, задачу как правило посмотрит тимлид, при необходимости привлекая техлида направления, менеджера и команду склада. В этом случае как только становится ясно, что именно нужно сделать, задача передается обратно дежурному разработчику.
Речь не идет о некоем абстрактом пуле, из которого под проект выделяются разработчики и в который они попадают обратно после завершения.
В нашем случае этот пул — как правило команда, тимлид которой является техлидом проекта.
Завершив разработку, ее члены участвуют в сопровождении внедрения и параллельно начинают смотреть текущие задачи, либо сразу приступают к новому проекту.
Эта команда существует постоянно, проводит стендапы, ретро и прочие активности.
Если позже будет найден специфический для этого проекта баг, с которым не сможет справиться дежурный разработчик при сапорте, то задача попадет к техлиду(тимлиду), который доопишет ее и передаст одному из участников проекта.
onets
Есть интересные моменты, благодарю.