Как повысить уровень команды разработчиков

Перевод статьи «How to Level up Dev Teams».

Как повысить уровень команды разработчиков

Наши клиенты часто нас спрашивают: «Как вам удается эффективно повышать уровень команд разработчиков? Как у вас получается взять группу инженеров, никогда не писавших на Python, и сделать из них эффективных Python-разработчиков? Или сделать так, чтобы группа людей, никогда не занимавшихся распределенными системами, создавала надежные, отказоустойчивые микросервисы? Как насчет команд, которые раньше ничего не строили в облаке, а теперь справляются с задачами по созданию облачного ПО?»

Обучение на курсах

Кто-то скажет, что уровень команд повышают за счет обучения. Привлеките специалиста, который научит нас эффективно писать на Python или создавать облачное ПО. Отправьте разработчиков на курсы. Поместите на вход неограненный алмаз талант и получите на выходе подготовленного и продуктивного инженера.

Тем, кто разделяет такую точку зрения, я хотел бы задать один вопрос: как вы определите, что вы уже готовы? Как только окончите курсы? Двухдневных курсов хватит или стоит обратить внимание на трехдневные? Или нужен шестимесячный курс парного программирования?

После всего этого вы, конечно, можете стать более готовым, чем были прежде. Однако вы потратите на эти учебные программы кучу денег, не говоря уже о стоимости «простоя» ценных специалистов, которые ушли на курсы.

Стоит ли оно того? Возможно. Однако трудно сказать заранее. И что случится, когда в сфере технологий выйдет очередная новинка? Нам придется начинать весь процесс сначала.

Инструментарий

Другие считают, что повысить уровень команды можно за счет правильных инструментов.

Конвейеры непрерывной интеграции и непрерывной доставки сделают разработчиков более эффективными. Они смогут быстрее поставлять программы более высокого качества. Продукты машинного обучения сделают имеющийся у нас опыт более управляемым. Благодаря бессерверным технологиям инженеры станут более продуктивными. Автоматизация улучшит медленные и бюрократические процедуры нашей компании.

На самом деле все очень просто. Инструментарий часто выступает в роли лейкопластыря для разваленных или неэффективных подходов, а сами эти подходы представляют собой рубцовую ткань в теле организации.

Инструменты могут быть полезны, однако они не исправят вашу дефектную культуру и уж точно не повысят уровень ваших команд. В лучшем случае они могут стать дополнительной поддержкой.

Процедуры

Также есть мнение, что уровень команд можно повысить за счет подходов к разработке. Имеется в виду, что команды, практикующие разработку через тестирование или парное программирование (scrum, agile, вставьте-нужное), повысят свой уровень быстрее и станут более эффективными. А команды, НЕ практикующие эти подходы, просто еще не готовы, и на приведение в состояние готовности им потребуется больше времени.

Все эти вещи могут помочь, но их значение не является определяющим. Если вам это кажется богохульством, остановитесь и задумайтесь.

Видал я команды, использовавшие scrum, парное программирование и TDD, и при этом писавшие отвратительные программы. Также мне встречались команды, где не писали модульных тестов, однако ПО у них было просто потрясающим.

Все это лишь инструменты. Команда может извлечь из них пользу, но они не могут волшебным образом сделать ее готовой к какой-то деятельности или более эффективной. За единственным исключением – ревью кода, которое проводится не авторами этого кода.

Ревью кода

Ревью кода это один из лучших методов повышения уровня команды разработчиков

Это единственная практика, которая может помочь улучшить качество кода, и в пользу этого утверждения есть эмпирические данные.

Парное программирование может быть отличным способом обучения джуниоров и проверки того, понятен ли ваш код кому-нибудь еще. Но оно не является заменой ревью.

Работая в паре, выдвинуть плохую идею так же просто, как и работая в одиночестве. Но когда вы привлекаете кого-то со стороны, кого-то, кто не участвовал в написании этого кода, он скорее заметит, что идея плоха.

Ревью кода это эффективный способ быстро повышать уровень команд, если, конечно, у вас есть в запасе несколько знающих ревьюеров, которые могут поддержать этот процесс. (А это приводит нас к мысли, что временами нужно разбивать даже высокопроизводительные команды, чтобы рассеивать таких инженеров по всей организации).

Эти ревьюеры могут давать быстрый фидбэк другим разработчикам, которые в конечном итоге впитают их опыт и будут применять его в собственных ревью кода. Благодаря этому опыт распространяется быстро, а повышение уровня становится заразным.

Из личного опыта

Я впервые столкнулся с этим, когда работал в Workiva. До этого я никогда не писал на Python и не пользовался Google App Engine. И вот я попал в компанию, чей продукт был написан главным образом именно на Python, а запускался на Google App Engine.

За несколько месяцев я стал довольно эффективным разработчиком на Python и начал разбираться в App Engine и распределенных системах.

При этом я не ходил на курсы. Не читал никаких специальных книг. Сессии парного программирования были редкими. Мой уровень повысился только благодаря ревью кода (и, в частности, групповым ревью).

Именно поэтому наши ревью кода были совершенно безжалостными (новых сотрудников порой это заставало врасплох). Благодаря этому подходу Workiva, взяв команду инженеров практически без опыта работы с Python или облаками, сумела эффективно поставлять облачный SaaS-продукт, написанный на Python, и через несколько лет выйти на IPO.

Почему ревью кода лучше учебных программ

Ревью кода продвигает культуру, отделяющую эго от кода. Совершенно естественно, что люди не любят, когда их критикуют. Но в ходе ревью кода мы критикуем код, а не людей. Это также хороший метод делиться контекстом внутри команды. Другие люди, просматривая ваш код, получают представление о том, чем вы заняты и на каком вы этапе. Это также помогает в ситуациях, когда вашему коллеге приходится переключиться на что-то, над чем работали вы.

Вот почему мы в Real Kinetic, консультируя компании, подчеркиваем важность наставничества и создания культуры постоянного совершенствования. К нам обращаются компании, которые хотят начать внедрять новые подходы и технологии, но чувствуют, что их команды недостаточно готовы к этому. Однако реальность такова, что вы никогда не будете чувствовать себя полностью готовыми, потому что никогда и не будете полностью готовы.

Ничто не заменит опыт. Вы не станете профессиональным спортсменом, смотря спортивные соревнования по телевизору. И вы не создадите надежное облачное ПО, прочитав о нем в книгах или сходив на курсы.

Не поймите неверно: все это может помочь, но ничто из этого не является подходящей стратегией. Аналогично, определенные подходы к разработке тоже могут помочь, но они не являются необходимыми предпосылками успеха. Кроме того, они чаще становятся предметом эмоциональных и философских споров, чем объективных рассуждений.

Для наработки опыта командам нужно давать свободу экспериментов и совершения ошибок. Им нужно начать действовать.

Единственное исключение – ревью кода. Это простой, но самый эффективный способ повысить общий уровень команды. Благодаря строгим ревью кода, быстрым итерациям и действиям, ваши команды будут развиваться быстрее, чем на любых курсах.

Вы можете инвестировать средства в тренинги или другие методы обучения, если уверены в их полезности, но сделайте ревью кода обязательным этапом перед слиянием кода в master.

Наряду с регулярными ретроспективами, это фундаментальный компонент создания культуры непрерывного совершенствования. Благодаря ему опыт начнет распространяться по вашей организации подобно лесному пожару.

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх