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

Совместное размещение и распределенные команды

Совместное размещение команд способствует максимизации личного общения.  Работа в одном помещении является основной для всех методологий Agile, включая scrum. Как сказал Кен Швабер (Ken Schwaber), автор The Enterprise и Scrum: «Лучшее общение происходит лицом к лицу, когда собеседники могут видеть выражение лица, жестикуляцию, чувствуют интонацию друг друга. Когда для разработки группе предоставляется только электронная доска, пропускная способность связи сильно барахлит».

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

В опросе State of Agile за 2010 год, проведенном VersionOne, половины респондентов заявили, что в настоящее время они используют Agile как при работе с совмещенными, так  с распределенными командами, или планируют использовать его в ближайшее время. Хотя совместное размещение вашей команды является рекомендуемым и оптимальным подходом к внедрению Agile-процессов, многие команды не могут сделать это по критически важным причинам и должны научиться следовать принципам и практике Agile при распределенной работе. Информация в остальной части этой статьи объяснит, как это сделать.

De-Agile для распределенных команд

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

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

В следующих разделах приведена особенно полезная информация для включения de-Agile для распределенных команд.

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

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

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

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

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

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

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

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

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

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

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

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

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

Мягко настаивайте на использовании Agile-практик

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

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

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

Вы можете воспользоваться инструментами agile-процессов (электронные доски, заметки и т. д.), превращая их из физических в виртуальные. Можно использовать Microsoft SharePoint, Microsoft Visual Studio Team System 2008/2010 и другие онлайн-инструменты (даже Google Docs и Live группы) для отслеживания командного проекта. Visual Studio 2010 включает в себя шаблоны проектов для Agile и scrum, которые вы можете использовать для организации ваших пользовательских историй  и резерва проекта . Он также включает в себя ряд предопределенных отчетов, таких как диаграмма сгорания задач  и общие отчеты о состоянии. В SharePoint 2007/2010 вы можете использовать списки для управления своими задачами или ошибками. Вы также можете использовать библиотеку документов для управления проектными документами.

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

Учитывайте разницу во времени

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

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

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

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

Понимание культурных различий

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

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

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

Адаптация коммуникации для удаленных команд

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

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

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

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

Другие важные вопросы

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

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

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

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

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

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

No Comments