От разработчика до руководителя

В главе 5 я отмечала, что в наше время распространенным недостатком в работе команд программистов является невыпуск кода и что прямой инструмент измерения этого состояния — частота релизов. Я сочувствую вам, если ваша компания не понимает важность частых релизов кода. В современном мире частота изменений кода — один из важнейших индикаторов трудоспособности команды разработчиков. Хорошие менеджеры-инженеры в командах, сосредоточенных на создании продукта, знают, как формировать условия, благоприятные для быстрого продвижения работы вперед. Одна из мер — умение правильно разбить работу на небольшие куски. Даже если в вашей компании не понимают ценности релизов, вы должны помогать команде достигать как можно более высокой частотности для конкретного продукта. Даже если вы считаете, что это не относится к вам, потому что вы заняты разработкой продукта (например, базы данных), не предполагающего частых релизов, я уверена: имеет смысл продвигать почти готовую версию продукта в бета-тестирование. Оно может стать важным инструментом измерения с точки зрения соотношения частотности релизов и стабильности программы.

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

Готова биться об заклад: если вы бросите честный взгляд на команду, нечасто выпускающую релизы, то сразу же увидите проблемы. Процесс подготовки релиза занимает много времени. Инженеры-программисты обычно не чувствуют себя ответственными за окончательное качество кода и оставляют эту работу на команду по контролю качества, что обычно создает много задержек в двусторонней связи между ними. Если в процессе релиза возникают проблемы, это приводит к сбоям в производстве (или вообще в разработке продукта). Неспособность команды часто осуществлять релизы приводит к целому ряду болезненных последствий.

Здесь вы можете сказать: «Спасибо за совет, но у меня нет времени для работы над этим с учетом нашего напряженного плана» или «Наши системы не предназначены для частых релизов». Или, наконец: «В конце концов, не так уж важно, что мы вносим в наши продукты много изменений».

И все же задайте себе еще вопросы. Работает ли ваша команда в полную силу? Ваши инженеры не боятся новых вызовов и растут над собой? Довольно ли вашим прогрессом подразделение по продукции? Есть у ваших людей время, чтобы писать новый код и разрабатывать новые системы? Если ответы положительные, то замечательно. Забудьте о моих предостережениях. Вы полностью контролируете ситуацию. Если ответы отрицательные, то у вас проблемы и вы не уделяете им внимания на свой страх и риск.

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

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

Частота проверок кода