Привлекая более квалифицированную или дефицитную рабочую силу, снижая издержки, компании-разработчики неизбежно за это «расплачиваются». Усложняется их контроль над качеством продуктов, увеличиваются сроки создания программных продуктов, растет количество проблем, связанных с координацией действий разрозненных рабочих групп. Есть ли возможность хотя бы минимизировать негативные последствия децентрализации разработки? Есть, но она обеспечивается не только определенными инструментами поддержки групповой работы. Не существует «серебряной пули», которая разом решит все проблемы, поэтому необходимо комплексное использование инструментов и новых методологий разработки и контроля над качеством.
Ключевое отличие распределенной разработки
При сопоставлении с распределенной разработкой традиционного процесса (при котором разработчики находятся если не в одной комнате, то, по крайней мере, в одном здании) выявляется несколько различий. Одно из них можно считать ключевым: это значительное усложнение взаимодействия (особенно неформального) между участниками проекта.
Хотя в обществе сложилось представление о программисте как о классическом интроверте (человеке, который полностью погружен в работу и мало общается с коллегами в течение рабочего дня), исследования дают совершенно другую картину. Одно из них свидетельствует, что каждый разработчик уделяет в среднем 75 минут в день неформальному обсуждению с коллегами вопросов, связанных с проектом. Согласно исследованию [1], разработчики телекоммуникационного программного обеспечения тратят на формальное и неформальное взаимодействие с коллегами 50% своего времени — вплоть до последнего месяца разработки, когда этот показатель снижается до 10%. Конечно, показатели варьируются от проекта к проекту, но можно однозначно утверждать, что общение имеет для разработчика огромное значение.
Современная практика допускает внесение изменений в проект не только при проектировании, но и на этапе кодирования, что обусловлено требованиями непрерывно изменяющегося рынка и условиями, в которых находится заказчик. Даже при идеально составленной проектной документации и определении ролей каждого из участников проекта неизбежно будут возникать ситуации, требующие согласования интерфейсов, поведения отдельных компонентов системы и даже общей функциональности. Однако координация, которая не вызывает особых проблем при работе в пределах одного здания, может оказаться сложной, если коллективы разработчиков разделены тысячами километров. Впрочем, согласно некоторым исследованиям, сотрудники, работающие в разных зданиях, общаются примерно с той же интенсивностью, что и их коллеги, находящиеся в разных частях света.
Одно время казалось, что современные коммуникации могут решить проблему взаимодействия. Видеоконференц-связь, электронная почта, средства передачи мгновенных сообщений, инструменты поддержки групповой работы и т.п., безусловно, помогают в работе, но для решения проблемы их явно недостаточно. Ни одно из перечисленных средств не свяжет участника проекта, который уже закончил работу и отправился домой, с тем, чей рабочий день еще не закончился и кому срочно требуется согласовать те или иные детали.
Какое непосредственное влияние оказывает уровень взаимодействия разработчиков на выполнение проекта? Наиболее очевидным параметром является время завершения проекта. Если одним специалистам регулярно приходится ждать других для решения каких-либо вопросов, то задержки неизбежны. Они возникают и при обычной, нераспределенной, разработке, но бывают значительно меньшими по времени. Опрос разработчиков нескольких десятков компаний из Великобритании и Германии, проведенный исследовательским подразделением Lucent Technologies, дал следующие результаты. При работе в пределах одного здания каждый реципиент сталкивался в среднем с 2,1 задержки в месяц при продолжительности каждой 0,9 рабочего дня. При распределенной разработке возникало 1,9 задержки в месяц, но их средняя продолжительность составляла уже 2,1 дня. Итак, разница в количестве задержек при локальной и распределенной разработке несущественна, тогда как разница в их продолжительности достаточно ощутима.
Примерно те же результаты получены при анализе запросов на изменение проекта в целом. В среднем при локальной разработке на одно существенное изменение в проекте (исправление ошибок или добавление новых функций) требовалось 5 дней (с начала реальной работы до внесения последних изменений в код — это называется «рабочим интервалом»). Если в создании программных продуктов участвовали несколько удаленных коллективов, такой интервал увеличивался до 12,7 дня (то есть более чем в два с половиной раза). Ситуация с полным интервалом (временем с момента поступления запроса на изменение до внесения последнего изменения в код; этот интервал несколько больше рабочего, поскольку включает в себя время, необходимое для анализа запроса, назначение приоритета и т.п.) аналогична: 20,5 дня против 12,7.
Количество и продолжительность задержек зависят от ряда параметров, характеризующих каждый проект создания программного обеспечения. Выявление зависимости этих параметров от задержек поможет свести последние к минимуму. С использованием статистических данных, полученных в том числе при опросе нескольких сотен разработчиков, было проанализировано влияние следующих параметров на продолжительность задержек.
- Число занятых в проекте разработчиков. Логично предположить, что при увеличении числа разработчиков растет количество и продолжительность задержек.
- Распределение изменений по удаленным объектам. Чем больше количество модулей системы, затрагиваемых изменениями (особенно если эти модули разрабатываются в разных местах), тем более вероятны задержки.
- Масштаб изменений. Чем больше изменений вносится, тем больше вероятность задержек.
- Время первой модификации исходного кода. Считается, что время, затрачиваемое на изменение продукта с целью исправления ошибок, отличается от времени изменения при добавлении новых функций.
- Серьезность изменений. Данный фактор можно рассматривать как аналог приоритетности изменений. Считается, что чем более высокий приоритет назначен изменению (например, при исправлении критически важных ошибок), тем быстрее оно будет проведено. Предполагается, что внесение изменений в рамках распределенной разработки потребует больше времени, чем при работе всей команды в одном месте.
Число разработчиков, масштаб и распределение изменений значительно увеличивают рабочий интервал внесения изменений в проект. Этот интервал увеличивается также со временем и уменьшается в соответствии с серьезностью изменений. Удивительно, но факт: то, что проект выполняется с участием удаленных коллективов, не приводит к существенному увеличению рабочего интервала. Для масштабных изменений требуется больше времени, и вполне вероятно, что для их реализации будут привлечены удаленные коллективы. Для реализации изменений, затрагивающих большее число компонентов системы (критерий — распределение изменений по удаленным объектам), требуется больше времени, и весьма вероятно, что такие изменения будут выполняться с помощью удаленных коллективов. Участие удаленных коллективов требует большего числа разработчиков, что, в свою очередь, приводит к значительному росту задержек.
Для дальнейшего анализа служит графическая модель Гаусса (см. рисунок). Узлы здесь — исследуемые переменные факторы, а дуги — частная корреляция между ними. Частная корреляция между переменными X1 и X2 отличается от обычной выборочной корреляции тем, что показывает величину взаимосвязи между переменными при фиксированных значениях других переменных (Xi), напрямую влияющих на X1 и X2. Синий цвет дуги означает положительную частную корреляцию, а красный — отрицательную. Толщина линии определяет значимость корреляции. Цифры рядом с дугой означают отклонение (чем оно больше, тем больше и значимость) и частную корреляцию. В отличие от обычной корреляции (взаимозависимости величин), частная корреляция используется, если нельзя достоверно утверждать, что величины связаны между собой напрямую, а не через некоторую третью величину или группу величин. В таких случаях рассматривается так называемая «частная корреляция двух величин при неизменных значениях остальных величин». Переменные, не связанные между собой напрямую, являются независимыми при фиксированных значениях переменных, с которыми они связаны.
На рисунке видно, что переменными, напрямую связанными с рабочим интервалом, являются число разработчиков, распределение и масштаб изменений. Не подтверждаются предположения о том, что более масштабные изменения требуют больших времени и участия удаленных коллективов, а также что изменения большего количества компонентов системы требуют большего времени и, скорее всего, — участия тех же удаленных коллективов. Критерий участия удаленных коллективов не имеет существенной частной корреляции с масштабом или распределением изменений.
Модель подтверждает предположение, что распределенная разработка обусловливает использование большего числа разработчиков, что, в свою очередь, приводит к увеличению задержек. Удаленная разработка сильно связана с количеством разработчиков, а последний фактор, в свою очередь, — с рабочим интервалом. Получается, что при выполнении проекта несколькими удаленными коллективами снижается скорость создания программного обеспечения — из-за привлечения большего количества разработчиков. Похоже, что одна из причин этого состоит в снижении эффективности взаимодействия разработчиков друг с другом, а также в недостатках координации коллективов.
Компаниям, участвовавшим в исследовании Lucent, был задан ряд вопросов. Анализ их ответов показал, что наибольший вклад в увеличение задержки вносит отсутствие помощи коллег при решении сложных задач в условиях распределенной разработки. Интересно, что данный фактор, по сути, является единственным значимым. Кроме того, ни один из опрошенных разработчиков не считает себя частью проблемы. Другими словами, разработчики уверены, что в равной степени помогают коллегам, находящимся с ними в одном здании и за тысячи километров от них. Однако те же самые специалисты убеждены, что получают гораздо большую помощь от местных коллег, нежели от удаленных. Одно из объяснений может быть таким: разработчики действительно пытаются быть полезными для других, но дистанционная помощь менее эффективна. Или же им трудно определять уровни сложности и срочности проблем, возникающих у удаленных разработчиков, то есть недооценивается важность помощи, за которой к ним обращаются.
В целом опрос свидетельствует о том, что координация и взаимодействие сильно страдают при распределенной разработке. Во-первых, значительно проще разрабатывать и осуществлять изменения в многомодульном проекте, если все модули создаются и поддерживаются в одном месте. У разработчиков появляется возможность оперативно получать всю необходимую информацию «из первых рук». Во-вторых, неформальное общение с разработчиками, создававшими изменяемый код (которое зачастую бывает весьма эффективным), практически недоступно участникам распределенных проектов. В-третьих, при распределенной работе значительно сложнее найти специалиста, обладающего необходимыми информацией и опытом. Вероятность вовлечения в изменения нужного человека из удаленного коллектива много меньше, чем в том случае, когда все работы ведутся в одном месте, поэтому изменения займут больше времени и потребуют участия большего числа разработчиков.
Концептуальное решение
Проблемы обеспечения взаимодействия разработчиков существуют и при локальной разработке, но их масштаб — намного меньше.
Причин этого много: культурные, языковые различия, разница в часовых поясах, плохая согласованность действий. Решить проблему лишь за счет применения новых средств управления групповой работой (groupware) невозможно. Концептуально надо стремиться к тому, чтобы, с одной стороны, уменьшалась потребность во взаимодействии удаленных разработчиков (поскольку нельзя добиться такой же его эффективности, какая достижима при «живом» общении), а с другой стороны, повышалась эффективность инструментария разработчика.
- J. Herbsleb etс. Object-oriented analysis and design in software project teams. // Human-Computer Interaction, 1995, Vol. 10, № 2-3.
Алексей Абсалямов (aa@cybercontrol.ru) — аспирант МГТУ им. Н. Э. Баумана (Москва).
Выбор типа разработки
Распределенная разработка объективно является более сложным методом, которым тем не менее пользуются все чаще и чаще. Руководитель проекта должен принимать во внимание следующие факторы.
- «Возраст» проекта. Проект может быть как новым, так и продолжением прежнего. Большинство разработчиков очень не любят разбираться в чужом коде, особенно если его автор не сидит за соседним столом. Действительно, «старые» проекты гораздо сложнее адаптировать к новому стилю разработки: они содержат много кода, который уже отчасти не поддерживается, а архитектура проекта может быть неудобна для разделения задач. Надо отказаться от перехода к распределенной модели при выполнении проектов, которые ранее долгое время выполнялись сугубо на локальном уровне.
- Критичность проекта для производителя и потребителя. Продукт, созданный несколькими удаленными коллективами, при прочих равных условиях обычно оказывается худшим по качеству, нежели продукт, разработанный локальной командой, — при распределенной разработке контроль над качеством и тестирование усложнены.
- Бюджет. Если денежный вопрос является одним из наиболее существенных в проекте, распределенная разработка может дать преимущества. Экономия средств достигается не только при выполнении аутсорсинга программных проектов в Индии, России или государствах Юго-Восточной Азии, но и при работе с удаленными коллективами внутри страны.
- Модульность проекта. Абсолютно независимых модулей в проекте не бывает, но можно легко отличить условно неделимые проекты от полностью модульных. Разработку основной системы можно поручить удаленным коллективам, а взаимодействие с ней модулей регулировать четко определенными программными интерфейсами. Чем большей модульностью отличается проект, тем легче его выполнять удаленно и тем больше причин выбрать распределенную разработку.
- Размер проекта. Малые проекты сравнительно легко передать распределенным коллективам, но экономически это бывает неоправданным. Экономия на заработной плате оказывается незначительной и перекрывается затратами на поиск небольших команд или индивидуальных разработчиков, поскольку крупные сервисные компании неохотно берутся за такие проекты. Кроме того, за то время, которое понадобится удаленным разработчикам, чтобы войти в курс дела, местный специалист зачастую успеет написать и отладить код.
Одним из немногих исключений из этого правила является малый бизнес. В общем случае небольшая фирма не является привлекательной для высококвалифицированных программистов, поэтому она может потратить на поиск кадров в крупных городах столько же времени, сколько в регионах. Да и отношение даже к небольшой экономии «живых» средств в таких компаниях другое. Итак, малые проекты в средних и крупных фирмах лучше выполнять локально, а в небольших — удаленно.
Что же касается больших проектов, ситуация складывается скорее в пользу локальной разработки. В таких случаях фактор затрат обычно находится на втором плане, а вот сроки — на первом. В качестве исключения можно указать проекты с открытым кодом, но не ограничивается конкретными сроками и ответственностью перед заказчиками, а потому может выполняться удаленно.
- Кадровый потенциал. Этот фактор является тяжело формализуемым, поскольку зависит от уровня зарплаты, доступности кадров на местном рынке, сложности и уникальности поставленных задач и т.п.
