Думайте глобально, пишите код локально. Секреты распределенных команд

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

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

Распределенные команды разработчиков могут столкнуться и с другими сложными задачами:

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

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

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

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

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

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

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

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

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

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

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

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

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

Разберем каждый из этих приемов.

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

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

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

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

В-третьих, если сотрудники работают из разных офисов, управлять ожиданиями и налаживать взаимопонимание между командами проще, когда однозначно определены критерии завершенности. Четкие критерии завершенности помогут пролить свет на непонятные моменты в работе. Например, если вы поставляете версию, над которой работало несколько команд, четко определите, что значит «завершенная» работа: код написан, запрос pull создан, код проверен, подвергнут тестированию и объединен с соответствующей веткой.

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

В фотографии под «золотыми часами» понимается время прямо перед восходом и закатом солнца и сразу после них, когда получаются наиболее удачные пейзажные фотографии. Для распределенных команд разработчиков «золотые часы» — это время, когда и местная, и удаленная команды находятся в своих офисах. Когда все команды на рабочих местах, самое время проводить стендапы.

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

Иногда офисы расположены так далеко друг от друга, что общие совещания будут причинять определенные неудобства одной из команд. (Вставать в 5 утра, чтобы провести стендап с другой командой? Нет уж, спасибо.) Чередуйте время проведения совещаний. Так будет справедливо для обеих команд, и ни одной из них не придется постоянно работать сверхурочно (а подобные ситуации серьезно подрывают моральный дух). Внимательно следите за тем, чтобы вся команда была вовлечена в стендап. Если команда испытывает чрезмерное напряжение или недовольна тем, как идет стендап, внимание участников начинает ослабевать, они прекращают слушать или делиться своими мнениями. И необязательно проводить стендап каждый день. Собирайтесь с удаленной командой несколько раз в неделю, а в другие дни проводите стендап для местной команды. Стендап можно проводить не только утром. Лучше всего устраивать его в такое время суток, когда всем удобно принять в нем участие.

Реальность такова, что в распределенной организации все команды являются удаленными. Всем командам нужно приспосабливаться и учиться выполнять одну работу силами нескольких офисов, эффективно обмениваться информацией и формировать общую культуру для сотрудников из разных регионов. В наиболее эффективных командах удаленное представительство не обязано просто копировать культуру главного офиса, потому что такие команды знают: каждому офису есть чему поучиться у других. Успешные подходы применяются во всех регионах, где есть представители команды; их нужно найти и ими нужно поделиться с другими. Офисы должны не противопоставлять себя всем остальным, а относиться друг к другу как к разным частям одной команды.

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