Эволюция Agile — работа в распределенной команде

Ниже представлен вольный пересказ статьи Sandeep Joshi Agile Development — Working with Agile in a Distributed Team Environment.

Sandeep Joshi — Senior Solution Architect и сертифицированный тренер (Microsoft Certified Trainer — MCT). У Sandeep более чем 12-летний опыт в разработке веб-приложений и программного обеспечения для бизнеса, финансовых и страховых услуг.

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

Колокация vs. Распределенные команды

У колоцированных команд максимальное количество возможностей для личного общения. Работа в одном помещении является основой для всех Agile-фреймворков, включая Scrum. Как сказал Кен Швабер, автор The Enterprise and Scrum: «Лучшее общение — лицом к лицу, когда общение происходит через мимику, жесты, интонацию и слова. Когда появляется доска задач и команды разрабатывают дизайн как единое целое, пропускная способность коммуникаций просто невероятна».

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

В опросе State of Agile 2010 года, проведенном VersionOne, более половины респондентов заявили, что в настоящее время они используют Agile как с колоцированными, так и с распределенными командами или планируют сделать это в будущем (прим. ред. — 59% участников исследования Agile в России 2018 работают в распределенных командах). Хотя для внедрения Agile рекомендуется совместное расположение команды, многие команды не могут сделать это по критически важным для бизнеса причинам и должны научиться следовать принципам и практикам Agile в распределенной разработке. В этой статье информация о том, как это сделать.

Декомпозируйте Agile для распределенных команд

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

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

В следующих разделах содержится информация, которая будет особенно полезной при декомпозиции Agile в распределенных командах.

Оптимизируйте размер и состав команды

Эффективная распределенная Agile-разработка сводит к минимуму влияние локализации. Основные Agile-процессы хорошо работают для групп от 10 до 15 человек, но что, если ваша команда намного больше? Утвержденные стратегии о внутрикорпоративных коммуникациях начинают рушиться, поскольку размер команды увеличивается и начинает охватывать несколько часовых поясов. Вы по-прежнему можете использовать Agile для более крупных распределенных команд, но вы должны быть готовы скорректировать свои процессы в соответствии с реальными условиями вашей команды.

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

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

Распределите работу равномерно

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

Уравнять рабочую нагрузку сложно, но это возможно с помощью SWAT-анализа (Субъективная методика оценки рабочей нагрузки). Создание SWAT в распределенной среде является не менее сложной задачей, потому что члены команды распределены географически, а SWAT требует очных встреч один на один. На одной из моих предыдущих должностей я работал с распределенными командами разработчиков в Соединенных Штатах и ​​Австралии. Я обнаружил, что большинство разработчиков в Австралии писали читабельный код с соответствующими комментариями и юнит-тестами, тогда как разработчики из Соединенных Штатов испытывали затруднения. Когда я обсуждал ситуацию с каждым членом команды один на один, я обнаружил, что команда США выполняет больший объем работы. Австралийской команде была поручена лишь небольшая часть работы, а это означало, что у них было гораздо больше времени для выполнения своей работы, чем у их коллег из США.

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

Также убедитесь, что с членами удаленной команды никогда не обращаются как с «помощниками» для членов команды в головном офисе. Если удаленные члены команды чувствуют себя наемными работниками, а не полноправными членами команды, у них снижается приверженность проекту.

Настройте парное программирование

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

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

Применяйте и усиливайте Agile-практики

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

В распределенной среде передовые практики использования инструментов играют жизненно важную роль при внедрении Agile. Например, вы можете применить комментирование кода, настроив политику регистрации изменений в Team Foundation Server, или вы можете использовать централизованный инструмент отслеживания ошибок и назначать обновления статуса перед ежедневным стэндапом для отслеживания обновления статусов. В течение первых нескольких недель после того, как вы установите подобные практики, вы заметите, что все следуют этим правилам. Когда вы приближаетесь к релизу, люди начинают пренебрегать ими, поэтому как Scrum-мастер, вы должны аргументировать необходимость их использования для отслеживания хода реализации проекта и помочь разработчикам довести их до автоматизма.

Используйте онлайн-инструменты для Agile-артефактов

Вы можете воспользоваться преимуществами Agile: доски задач, стикеры и т.д. — заменив их онлайн-инструментами, которых сейчас множество. Я использовал Microsoft SharePoint, Microsoft Visual Studio Team System и другие онлайн-инструменты (даже Google Docs и Live-группы) для отслеживания хода реализации проекта. В Visual Studio реализованы шаблоны для Agile и Scrum, которые можно использовать для организации пользовательских историй, бэклога и ​​т.д. Он также включает в себя ряд предопределенных отчетов, таких как диаграммы сгорания и отчеты об общем состоянии. В SharePoint вы можете использовать списки для управления задачами или ошибками. Вы также можете использовать библиотеку документов для управления проектной документацией.

Очевидным преимуществом SharePoint является легкость обмена списками и документами с пользователями, будь то внутри или вне организации. Если вы работаете в стартапе, Google Docs и Live-группы могут оказать вам огромную помощь. Документы Google можно использовать для обмена документами между группами или с внешними клиентами, если у вас не настроена среда SharePoint и вы готовы разместить свою проектную документацию в Интернете. Я использовал Live-группы для обмена мгновенными сообщениями внутри команды в качестве замены ежедневных стэндапов. Если новостей мало, члены команды делятся статусами через текстовые сообщения в Live Messenger и мы отменяем конференц-связь на этот день.

Поймите разницу во времени

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

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

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

Вы можете помочь своей команде работать с теми, кто работает по всему миру, сначала ознакомив всех с информацией о часовых поясах, в которых работают члены команды. Вы можете использовать что угодно: от физической карты с кнопками, отображающими распределение команды, до утилит для часовых поясов, таких как Microsoft Time Zone, или один из инструментов в Microsoft Outlook, например, Time Zone Data Updater. Когда вы включаете несколько календарей в Outlook, вы можете видеть время в других часовых поясах. В Windows вы можете использовать несколько часов. Когда вы пишите электронное сообщение, указывайте часовой пояс, в котором вы находитесь или на который ссылаетесь, например, добавив что-то вроде: «Было бы удобно обсудить это завтра в 7:00 по восточному часовому поясу?»

Учитывайте культурные различия

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

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

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

Адаптируйте общение удаленных команд

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

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

Вы можете расширить возможности аудиосвязи ваших распределенных команд, предоставив им необходимые инструменты, будь то обмен мгновенными сообщениями, VOIP, вики или мобильные телефоны. Вы также можете сделать доступными инструменты для виртуального личного общения, такие как видеоконференции с Microsoft Lync и Microsoft Lync Server.

Дополнительные вопросы для обсуждения

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

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

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

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

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

Заключение

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

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

Дополнительный ресурс

Чтобы узнать больше о распределенном Agile, прочитайте книгу Дина Леффингвелла Scaling Software Agility: Best Practices for Large Enterprises.