Дедлайн… Это слово знакомо каждому в ИТ и не только. О его приближении «слагают легенды». Его пытаются отсрочить, отодвинуть и не видеть как можно дольше, если в команде есть сбои в процессах или другие неразрешенные проблемы. При этом пересмотреть сроки не так просто: релиз/демо/тестирование — всё расписано по дням, как и окончание стадии разработки.
Когда проблемы всплывают достаточно рано, еще можно успеть скорректировать процессы, ускорить разработку user stories и прочее. Но что делать, если времени практически нет? Остаётся быстро усилить команду. Этот способ возможен даже в том случае, если проект сложный и требует много времени на погружение. Но, безусловно, он несет в себе определенные риски.
На примере кейса фронтенд-разработчик SimbirSoft Антон рассказывает, как максимально снизить издержки при расширении команды. Задача – быстро усилить команду клиента на короткий период по конкретному направлению. Статья может быть полезна менеджерам проектов, тимлидам и владельцам продуктов.
«Освоение целины»
Увеличение штата разработчиков, на мой взгляд, сравнимо с освоением целины. Казалось бы, есть определенное количество задач/модулей/функционала и т.п. Всё четко расписано, а значит можно нанять 20 новых сотрудников и быстро закрыть все задачи.
Однако увеличение разработчиков может не принести должного эффекта: в «горящие» сроки придется уместить время на погружение новых сотрудников в проект. Каждый из них должен получить те или иные «проектные знания», пройдя через все стадии принятия неизбежного во время адаптации. Например, на проекте может быть legacy, неоптимальные решения, новый синтаксис, незнакомые технологии и библиотеки.
Команда уже какое-то время работает над проектом с определенной отдачей. Приходят новички. Производительность проседает в течение нескольких недель, потому что новичкам необходимо учиться, и они донимают расспросами тех, кто уже работает давно. © Мартин Р. - Чистый Agile. Основы гибкости
«Дядя Боб» пишет об этом в своей книге Чистый Agile. Спор об этом оставим за рамками статьи. Предположим, что другого выхода нет. Есть факт: команда расширяется! В этом случае задача владельца продукта или менеджера проекта – максимально снизить издержки. Именно об этом мы и поговорим. В качестве примера рассмотрим кейс одного из наших клиентов, оказавшегося в подобной ситуации – крупный проект федерального уровня для автоматизации процессов. Напомню, наша задача была усилить команду разработки на короткий период по конкретному направлению.
Как снизить нагрузку на управление внешней командой
Крупный проект, множество связанных между собой модулей, виджетов, компонентов и всего остального, что только можно представить, на Vue 3 и других фреймворках. Добавим 20 «старичков»-разработчиков и «присыпем» сверху документацией на 500+ страниц в confluence и большим backlog с горящими сроками.
Настает тот день, когда нужно подключить ещё 10 новых разработчиков. Каждый имеет тот или иной опыт, своё видение идеальных gitflow/workflow/архитектуры и лучше всех знает, как должно быть. Сложно представить возросшую нагрузку (даже с учетом делегирования части обязанностей) на тимлида. Теперь он должен проводить code-review, декомпозировать и распределять задачи, отвечать на вопросы по проекту уже для 30 человек.
Перед нами стояла задача не только максимально «разгрузить» клиента по задачам/модулям/функциональности, но и снизить нагрузку на управление нашими специалистами. Другими словами, надо было сделать так, чтобы наша выделенная команда была максимально автономна и самоорганизована. Что ж, задача была поставлена, и, забегая вперед, скажу, что мы ее всё-таки выполнили. Далее расскажем подробнее.
Реорганизация ежедневных митингов и распределения задач
Начали мы с реорганизации ежедневных встреч команды с клиентом.
Проводить митинги общим сбором (30 человек) в нашем случае было бы неэффективно. На проекте были модули, которые нужно разрабатывать независимо от других. Конечно, на длинной дистанции такое разделение разработчиков может негативно сказываться на скорости разработки, увеличивать риск bus factor и прочее. Но напомню, что перед нами стояла совершенно другая задача. Наша «пожарная команда» прибыла на короткий период (1-3 месяца), получив в «распоряжение» определенные модули. Поэтому разделение на команды было допустимо.
В целях оптимизации мы проводили собственные митинги без участия клиента. После внутренних совещаний проводили встречу одного-двух человек из команды с клиентом для отчета по статусам наших задач и разбора вопросов. Так у нас получился некий «интерфейс» между клиентом и разработчиками. В результате нам удалось снизить нагрузку клиента, ограничив типовые вопросы внутри команды.
Любая задача представляла собой большую user story, которую было необходимо декомпозировать, создать подзадачи и распределить их между десятью разработчиками. Такие задачи могут иметь описание на несколько страниц, а иногда и десятков. Чтобы оптимизировать процесс и перенаправить поток вопросов по задачам, мы сосредоточили декомпозицию внутри нашей команды. Клиент отдавал нам одну большую задачу, а дальнейшее изучение постановки и декомпозиция были уже на нашей стороне.
Такой подход позволил сократить время общего митинга. Если бы встреча проводилась вместе с клиентом в составе «10+1», каждый разработчик был вынужден давать более полное описание той задачи, которую он выполняет. В случае обсуждения внутри команды таких подробностей не требовалось, мы знали, кто чем занимается.
На митинге с заказчиком в формате «2+1» обсуждали список вопросов по общей задаче (модулю), на которые не получилось найти ответ внутри подкоманды. Изменения и ошибки в постановке выносились на уровень клиента, а все технические вопросы по реализации задачи, code style и прочему оставались внутри команды.
Code review
О ценности проведения code review написана не одна статья, и мы тоже уже не раз об этом говорили. Мы не откроем Америку, если в тысячный раз повторим, что code review проводить просто необходимо.
Давайте на секунду представим себе проект, где очень подробно описаны правила eslint, подключен prettier и вообще всё везде имеет README.md. Все это не отменяет того, что мы имеем много разработчиков разного уровня со своими взглядами, как надо писать «чистый код». Без code review мы рискуем получить «зоопарк» подходов в реализации того или иного функционала.
В случае экстренного расширения команды эффект был бы еще более заметным. Представьте, что к проекту подключились десять новых разработчиков, каждый из которых имеет свое видение «чистого кода». Однако, так как проект не новый, то, если нет цели провести аудит и рефакторинг, нужно придерживаться стиля существующего кода. Вот здесь и получаем рекурсию в чистом виде, когда разработчики писали код по-разному, а вновь прибывшие будут писать новый код, опираясь на старый.
С такой ситуацией мы и столкнулись. Code review на проекте не проводили. Причина такого решения – нехватка времени.
Обсудив текущее положение дел внутри нашей команды, мы решили, что code review все же будет. Без code review на короткой дистанции мы можем сократить время разработки, а на длинной – можем потом потерять много времени на исправлении багов. В конечном счете доходило до 10 открытых Merge Requests (MR) в день, которые просматривались 1-3 членами команды. Состав часто менялся, что позволяло приводить code style разных разработчиков к одному знаменателю.
Тестирование и дефекты
В этом проекте тестирование было выделено в отдельный этап, который следовал за этапом активной разработки. По мере выполнения задач потребность в большом количестве разработчиков пропала, происходило постепенное сокращение команды. Отключение специалистов стало возможным благодаря планированию тестирования.
Количество и сложность дефектов на пике были настолько мелкими, что выливались в изменения 1-2 строчек кода и не позволяли загружать разработчиков на полную. Конечно, без нескольких крупных дефектов, которые повлекли за собой изменения в постановке задач, мы не обошлись. Но небольшой запас времени и «рук» позволил реализовать функционал в срок.
Резюмирую
На примере одного из наших проектов мы показали, как можно улучшить и оптимизировать процессы разработки и управления внешней командой. Конечно, наш опыт – не единственно возможный вариант, к каждому проекту нужен особый подход. Однако описанный кейс доказывает, что внедрение команды на усиление при правильном подходе не всегда приводит к нарушению устоявшихся процессов и не тормозит разработку. Часто «свежая кровь» и дополнительная сила помогает не только выпустить продукт в релиз, но и дает ему новый виток для развития.
Даже если кажется, что аутсорс или аутстаф вам не подойдет, всегда можно обратиться за консультацией, получить оценку и варианты решения проблем. Поскольку сервисные компании имеют широкий опыт работы, они смогут посоветовать, как эффективно закрыть потребности вашего бизнеса.
Больше кейсов и полезных материалов в наших каналах: