По всем вопросам звоните:

+7 495 274-22-22

УДК: 658.511.3

Децентрализованная разработка программных продуктов

А. Абсалямов аспирант, МГТУ им. Н.Э. Баумана, г. Москва, 2-я Бауманская ул., д. 5, стр. 1; e-mail: bauman@bmstu.ru

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

Литература:

1. Herbsleb J. [и др.]. Объектно ориентированный анализ и проектирование в проектных командах программного обеспечения // Human-Computer Interaction, 1995. — № 2–3.

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

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

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

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

Хотя в обществе сложилось представление о программисте как о классическом интроверте — человеке, который полностью погружен в работу и мало общается с коллегами в течение рабочего дня, исследования дают совершенно другую картину. Одно из них свидетельствует, что каждый разработчик уделяет в среднем 75 минут в день неформальному обсуждению с коллегами вопросов, связанных с проектом. Согласно исследованиям [1] разработчики телекоммуникационного программного обеспечения тратят на формальное и неформальное взаимодействие с коллегами 50 % своего времени — вплоть до последнего месяца разработки, когда этот показатель снижается до 10 %. Конечно, показатели варьируются от проекта к проекту, но можно однозначно утверждать, что общение имеет для разработчика огромное значение.

Для Цитирования:
А. Абсалямов, Децентрализованная разработка программных продуктов. Управление качеством. 2018;1-2.
Полная версия статьи доступна подписчикам журнала
Язык статьи:
Действия с выбранными: