Как провести онбординг нового разработчика в Scrum команду
Узнайте, как организовать онбординг нового разработчика в Scrum команду с помощью парного программирования, Definition of Done и самоорганизации вместо устаревших вики страниц.
В большинстве случаев онбординг инженеров проваливается, потому что к людям относятся как к компьютерам, ожидающим начальной загрузки данных. Новичку дают двадцать ссылок на устаревшую документацию, днями настраивают доступы и ждут чистый код уже на второй неделе. В Scrum команде такой подход особенно неэффективен. Scrum опирается на самоорганизацию, общую ответственность и быстрые циклы обратной связи. Если вы хотите, чтобы новый разработчик быстро начал приносить пользу, погружайте его через активное сотрудничество, а не через изолированное чтение.
Сфокусируйтесь на Sprint Goal, а не на вики
К моменту, когда новичок открывает документацию, она обычно уже устаревает. Вместо того чтобы заставлять нового разработчика изучать сухие архитектурные спецификации, сразу познакомьте его с текущей Sprint Goal. Sprint Goal объясняет, зачем команда создает Increment прямо сейчас. Она дает живой бизнес контекст, который не заменит ни одна статичная схема архитектуры.
Попросите Product Owner уделить двадцать минут рассказу об общем видении продукта и текущей Product Goal. Затем пусть Developers покажут, как текущий Sprint Backlog помогает достичь этой ближайшей цели. Это поможет новичку понять смысл своей работы еще до того, как он напишет первую строчку кода.
Парная работа с первого же дня
Настройка локального окружения часто превращается в мучение. Отсутствующие переменные среды, устаревшие скрипты и скрытые ограничения прав в репозитории отнимают дни, если новичок разбирается с этим в одиночку. Парное программирование решает эту проблему на корню. Посадите нового разработчика в пару с опытным коллегой в первый же день.
Первая цель проста. Написать небольшое изменение, протестировать его и развернуть на тестовом стенде в течение сорока восьми часов. Быстрый выход в прод или на стейджинг развеивает страхи перед пайплайном доставки и снимает тревожность. Вот как парная работа ускоряет онбординг разработчиков в Scrum:
- Показывает негласные правила команды, о которых никогда не пишут в документации.
- Снимает страх сломать сборку или выкатить ошибочный код.
- Укрепляет понимание того, что Developers несут коллективную ответственность за Increment.
- Дает новичку естественную возможность задавать вопросы, не чувствуя себя помехой.
Используйте Definition of Done как компас
Согласно Scrum Guide, Definition of Done дает формальное описание состояния Increment, когда тот отвечает требуемым критериям качества продукта. Для новичка эта договоренность гораздо полезнее корпоративного справочника, потому что она четко определяет, что значит готовая работа.
Разберите Definition of Done вместе. Объясните назначение каждого критерия. Если обязательны автоматические регрессионные тесты, код ревью или проверки безопасности, покажите, как они работают на практике. Понятные стандарты избавляют новых разработчиков от необходимости гадать, какой объем тестирования или документации от них ожидают.
Включайте в события Scrum с первых дней
События Scrum могут показаться непривычными тем, кто привык к статус митингам. Scrum Master стоит объяснить цель каждого события до его начала. На Daily Scrum важно донести, что это встреча для инспекции и планирования, где Developers синхронизируют движение к Sprint Goal, а не отчет о статусе перед руководителем.
Побуждайте нового разработчика участвовать в Sprint Retrospective с первой же недели. Свежий взгляд замечает шероховатости, к которым старожилы команды уже привыкли. Вопрос новичка о том, почему сборка идет сорок минут или почему деплой выполняется вручную, часто запускает ценные командные улучшения.
Инспектируйте и адаптируйте процесс онбординга
Поскольку Scrum команда самоуправляема, именно Developers отвечают за процесс онбординга. Центральные службы выдают технику, но команда сама решает, как ввести коллегу в работу. Относитесь к онбордингу как к развивающемуся процессу, а не как к статичному чек листу.
В конце первого Sprint нового сотрудника выделите десять минут на Retrospective, чтобы обсудить, как прошел онбординг. Спросите, что его тормозило, что вызвало путаницу, а что оказалось полезным. Используйте эти выводы, чтобы улучшить процесс для следующего новичка.