Распределенная гибкая разработка программного обеспечения - Википедия - Distributed agile software development

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

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

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

История / Исследования

Растущая глобализация с помощью новых возможностей, обеспечиваемых технологической эффективностью Интернета, побудила компании-разработчики программного обеспечения перенести свои разработки в более экономически привлекательные области. Это явление зародилось в 90-х годах, а его стратегическое значение осознали в 2000-х годах. [1]. Большинство первоначальных связанных исследований также датируются примерно этим временем. [2].

За это время Agile манифест был выпущен [3], который представляет собой эволюцию преобладающих тяжеловес подходы к разработке программного обеспечения. Это, естественно, привело к вопросу: «Может ли распределенная разработка программного обеспечения быть гибкой?». Один из первых исчерпывающих обзоров, пытающихся ответить на этот вопрос, был проведен в 2006 году. [4]. Изучив три организации, они обнаружили, что «тщательное включение гибкости в распределенные среды разработки программного обеспечения имеет важное значение для решения нескольких проблем, связанных с коммуникацией, контролем и доверием между распределенными командами». Позже, в 2014 году, был проведен систематический обзор литературы (SLR) для выявления основных проблем в обеспечении гибкости для работы в распределенном режиме. [5]. В 2019 была сделана аналогичная SLR. [6]. Более того, общий обзор по этому вопросу был сделан в [7]. Результаты некоторых из этих исследований будут обсуждаться в разделе «Проблемы и риски».

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


Возможности

В распределенной среде могут возникнуть трудности с отслеживанием рабочей нагрузки и вклада каждого в результат. Благодаря принятию гибких принципов и практик видимость становится более ясной, поскольку существует несколько итераций, в которых можно визуализировать проблемы или критические моменты на начальных этапах проекта. Непрерывная интеграция программного кода, который является одним из основных элементов гибкой разработки программного обеспечения, дополнительно помогает уменьшить количество исполнительных вопросов. Принятие гибких принципов, по-видимому, положительно сказывается на переписке между группами, поскольку циклическое продвижение позволяет членам легче видеть краткосрочные цели. Обзоры спринтов можно рассматривать как мощный метод улучшения внешней корреспонденции, в то же время они помогают обмениваться данными о функциях и предварительных условиях между партнерами или заинтересованными сторонами. Практики Agile также помогают в установлении доверия между различными командами, связанными с процессом, стимулируя последовательное общение и передачу результатов программирования. Как показало расследование, проведенное Пассиварой, Дурасевичем и Лассениусом, качество программного обеспечения и переписка улучшаются, а общение и скоординированные усилия становятся более регулярными по сравнению с результатом подхода Scrum, используемого в этом предприятии. Вдобавок было учтено вдохновение коллег в расширении [8]. Таким образом, внедрение гибких практик в распределенной среде продемонстрировало свою ценность для качества проекта и его выполнения. Таким образом, это можно рассматривать как некоторые из преимуществ, достигаемых за счет объединения гибкой разработки в распределенной разработке.[9]Однако этот список исчерпывающий. Основные преимущества можно перечислить следующим образом [10]:

Повышение межкультурного и внутрикультурного разнообразия

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

Гибкие планы работы

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

Путешествие по часовым поясам

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

Лица с инвалидностью и ограниченными возможностями передвижения

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

Повышение уровня благосостояния

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

Сниженные командировочные расходы

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

Итеративная идея Agile

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

Обширный пул HR

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

Уменьшает офисное пространство

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

Проблемы и риски

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

Вызовы

В результате несовместимости, с которой сталкиваются при объединении гибких принципов и практик в распределенной среде, могут возникнуть следующие проблемы. [12]:

Документация

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

Парное программирование

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

Разные часовые пояса

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

Обучение

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

Распределение работы

Что касается распределения работы, мы не хотим, чтобы архитектура отражала географическое распределение команды, распределяя работу в зависимости от местоположения. Лучше распределить задачи, относящиеся к одной пользовательской истории, по всей команде, думая с точки зрения историй, а не компонентов. Чрезмерная специализация по географическому положению и / или компоненту - признак того, что ваша команда плохо справляется с коммуникативными проблемами, которые ставятся перед распределенными командами. Эта чрезмерная специализация приводит к непреднамеренным последствиям изменения продукта в соответствии с разработкой, а не требованиями заказчика.[15].

Риски

В исследовании, проведенном в 2013 году, была сделана попытка объединить литературу по управлению рисками в распределенной гибкой разработке. [11]. В более всестороннем исследовании была сделана попытка классифицировать факторы риска для распределенных Agile-проектов в [16], это было сделано с использованием как исследовательской литературы, так и реального опыта тринадцати ИТ-организаций. Для краткости опущен полный список из 45 факторов риска с соответствующими методами управления. Вместо этого дается краткое изложение основных категорий и общих методов управления.


Жизненный цикл разработки программного обеспечения

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

Управление проектом

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

Групповая осведомленность

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

Сотрудничество с внешними заинтересованными сторонами

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

Настройка технологии

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

Инструменты и лучшие практики

Коммуникация

Одним из наиболее важных факторов в преодолении проблем, с которыми сталкивается распределенная гибкая разработка программного обеспечения, является улучшение коммуникации. [12]. Это означает минимизацию времени, необходимого для установки и прерывания сеанса связи, и предпочтение видеоконференцсвязи перед голосовой, если она доступна.

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

Различия в часовых поясах

Один из вариантов решения проблемы доступности встреч из-за часовых поясов - это назначить представителя команды, который будет посредником для двух команд, установивших хорошие отношения с обеими. Другой вариант - использовать вложенный Scrum с многоуровневой отчетностью и несколькими ежедневными встречами Scrum. [18].

Решение для проведения встреч Scrum в командах, которые справляются с различиями в часовых поясах, заключается в проведении различия между локальными встречами команды и глобальными встречами Scrum [19]. Каждая команда проводит локальную встречу в начале своего дня и глобальную встречу в другое время дня. Это возможно только в том случае, если их рабочие дни совпадают по времени.

Идти в ногу с гибкими практиками

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

Чтобы каждый член команды был в курсе принятого гибкого подхода, важно вести документацию по проекту. Это улучшает совместную работу группы при использовании гибких принципов и практик в среде распределенной разработки программного обеспечения. [18] [20] [21] [22]. Для этого можно использовать различные инструменты, которые помогают команде поддерживать документацию. [20].

Использование инструментов

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

Коммуникация

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

Управление проектом

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

Инструменты разработки

Чтобы обеспечить общий опыт для каждого члена команды, каждый член команды должен иметь доступ к одним и тем же инструментам для их разработки. [23]. Наличие одних и тех же инструментов управления конфигурацией программного обеспечения, связанных с инструментами управления проектами, позволяет разработчикам работать в одном темпе и одинаково сообщать о разработке.

Управление знаниями

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

Совместимость с Agile Manifesto

Ценности и принципы Agile Manifesto были исследованы на предмет их применимости в распределенной рабочей среде в 12 тематических исследованиях.[24] Исследования проводились с участием компаний-разработчиков программного обеспечения, которые применяли распределенную гибкую разработку программного обеспечения в своих проектах. Из 12 случаев 10 оншорных компаний были расположены в США, а семь офшорных компаний - в Индии. Результаты представлены в следующей таблице:

Характеристики, продвигаемые Agile ManifestoСлучай 1Случай 2Случай 3Случай 4Дело 5Дело 6Дело 7Дело 8Дело 9Дело 10Дело 11Дело 12
Значения
Люди и взаимодействия важнее процессов и
инструменты		✓✓✓✓✓✓✓✓✓✓✓✓
Рабочее программное обеспечение над комплексным
документация		✓✓✓✓✓✓✓✓✓✓
Сотрудничество с клиентами вместо переговоров по контракту✓✓✓✓
Реагирование на изменения вместо следования плануИксИксИкс✓
Принципы
Ранняя и непрерывная поставка ценного программного обеспечения✓✓✓ИксИксИкс✓✓
Приветствуем меняющиеся требования даже поздно
разработка
Часто доставляйте работающее программное обеспечение✓✓✓✓✓✓✓✓✓
Деловые люди и разработчики работают вместе
на протяжении всего проекта		✓✓✓✓✓
Создавайте проекты вокруг мотивированных людей и
поддерживай и доверяй им		✓✓✓✓
Личный разговор в рамках разработки
команда		✓✓✓✓✓✓✓✓✓✓✓✓
Работающее программное обеспечение - это основная мера
прогресс		✓✓✓✓✓✓✓✓✓✓
Содействовать устойчивому развитию для поддержания
постоянный темп бесконечно		✓✓✓✓✓
Постоянное внимание к техническому совершенству и
хороший дизайн		✓✓✓✓✓
Простота важна✓
Самоорганизующиеся команды✓✓✓✓
Команда регулярно корректирует поведение для улучшения
эффективность		✓✓


Из этого мы узнаем, что все тематические исследования подчеркивали первую ценность Agile-манифеста, который гласит, что люди и взаимодействия должны цениться выше процессов и инструментов. Agile Manifesto предпочитает работающее программное обеспечение исчерпывающей документации, не обязательно полностью отрицая документацию. Это значение также отражается в большинстве случаев. Было выявлено только четыре случая, которые подчеркивают важность сотрудничества с клиентами по сравнению с переговорами по контракту. Как ясно видно из таблицы, четвертое значение было принято наименее из всех ценностей софтверными компаниями: «вместо того, чтобы строго следовать методикам гибкой разработки, как это обычно определяется, компании постоянно настраивают их, чтобы соответствовать меняющимся потребностям свои проекты ». [25] Что касается принципов гибкой разработки, неудивительно, что личный разговор с командой разработчиков был оценен во всех исследованиях. Это было смоделировано в электронном виде между командами, работающими на суше, и на море. О том, следует ли изменять требования даже на поздних стадиях разработки, ни одна из компаний-разработчиков программного обеспечения, участвовавших в исследовании, не предоставила подробностей. Таким образом, мы можем предположить, что он не считался таким важным, как некоторые другие принципы.


Рекомендации

  1. ^ Хименес, М., Пиаттини, М., и Вискайно, А. (2009). Проблемы и улучшения в распределенной разработке программного обеспечения: систематический обзор. * Достижения в области разработки программного обеспечения *, * 2009 *.
  2. ^ Прикладницкий, Р., Дамиан, Д., и Ауди, Дж. Л. Н. (2008, июнь). Модели эволюции в практике распределенной разработки программного обеспечения: количественные результаты систематического обзора. В * 12-й Международной конференции по оценке и оценке в программной инженерии (EASE) 12 * (стр. 1-10)
  3. ^ Фаулер, М., и Хайсмит, Дж. (2001). Манифест Agile. Разработка программного обеспечения, 9 (8), 28-35.
  4. ^ Рамеш Б., Цао Л., Мохан К. и Сюй П. (2006). Может ли распределенная разработка программного обеспечения быть гибкой? Коммуникации АКМ, 49 (10), 41-46.
  5. ^ Разави, А. М., и Ахмад, Р. (2014, сентябрь). Гибкая разработка в больших и распределенных средах: систематический обзор литературы по организационным, управленческим и культурным аспектам. В 2014 году 8-е. Конференция по разработке программного обеспечения Малайзии (MySEC) (стр. 216-221). IEEE.
  6. ^ Гани И., Лим А., Хаснаин М., Гани И. и Бабар М. И. (2019). Проблемы в среде распределенной гибкой разработки программного обеспечения: систематический обзор литературы. KSII Транзакции в Интернете и информационных системах, 13 (9).
  7. ^ [6] Шривастава, С. В. (2010). Распределенная гибкая разработка программного обеспечения: обзор. * препринт arXiv arXiv: 1006.1955 *.
  8. ^ М. Паасиваара, С. Дурасевич, К. Лассениус, Использование Scrum в распределенной гибкой разработке: исследование нескольких примеров, Международная конференция IEEE по глобальной разработке программного обеспечения, стр.195-204, 2009 г.
  9. ^ Шривастава, С. В. и Дате, Х. (2010). Распределенная гибкая разработка программного обеспечения: обзор. Сео-чогу: журнал компьютерных наук и инженерии. 10-17
  10. ^ https://www.knowledgehut.com/blog/agile/key-factors-to-succeed-agile-teams
  11. ^ а б Шривастава, С.В. и Ратод, У., 2014. Риски в распределенной гибкой разработке: обзор. Процедурно-социальные и поведенческие науки, 133, стр. 417-424.
  12. ^ а б Шривастава, С.В., 2010. Распределенная гибкая разработка программного обеспечения: обзор. Препринт arXiv arXiv: 1006.1955.
  13. ^ М. Фаулер, «Использование гибкого программного процесса при офшорной разработке», http://martinfowler.com/articles/agileOffshore.html, Июль 2006 г. (последнее посещение - 11 мая 2020 г.)
  14. ^ Уильямс, Л., Кесслер, Р., Каннингем, В. и Джеффрис, Р., 2000. Укрепление аргументов в пользу парного программирования. Программное обеспечение IEEE, 17 (4), стр. 19-25
  15. ^ а б Аде Миллер, «Шаблоны и практики распределенной гибкой разработки в Microsoft», шаблоны и практики Microsoft, http://www.pnpguidance.net/Post/DistributedAgile 16 DevelopmentMicrosoftPatternsPractices, октябрь 2008 г. (получено 11 мая 2020 г.)
  16. ^ Шривастава, С. В., и Ратод, У. (2015). Классификация факторов риска для распределенных гибких проектов. * Информационные и программные технологии *, * 58 *, 373-387.
  17. ^ Прессман, Р. С. (2005). * Программная инженерия: подход практикующего *. Palgrave macmillan.
  18. ^ а б Смитс, Х., Пшигода, Г., 2007, август. Внедрение scrum в распределенной организации по разработке программного обеспечения. В Agile 2007 (AGILE 2007) (стр. 371-375). IEEE.
  19. ^ Дж. Сазерленд, А. Викторов, Дж. Блаунт и Н. Пунтиков, «Распределенный Scrum: гибкое управление проектами с привлечением сторонних разработчиков», 2007 40-я Гавайская международная конференция по системным наукам (HICSS'07), Вайколоа, Гавайи, 2007, С. 274a-274a, DOI: 10.1109 / HICSS.2007.180.
  20. ^ а б Хоссейн, Э., Бабар, М.А., Пайк, Х.Ю. и Вернер Дж., 2009 г., декабрь. Процессы выявления и смягчения рисков для использования схватки в глобальной разработке программного обеспечения: концептуальная основа. В 2009 году 16-я Азиатско-Тихоокеанская конференция по разработке программного обеспечения (стр. 457-464). IEEE.
  21. ^ Хольмстрём, Х., Фицджеральд, Б., Огерфальк, П.Дж. и Кончур, Э.Ш., 2006. Практики гибкой разработки сокращают дистанцию ​​в глобальной разработке программного обеспечения. Управление информационными системами, 23 (3), стр.7-18.
  22. ^ Берчук, С., 2007, август. Вернемся к основам: роль гибких принципов в успехе распределенной scrum-команды. В Agile 2007 (AGILE 2007) (стр. 382-388). IEEE.
  23. ^ Сазерленд, Дж. (28 февраля 2020 г.). Распределенные команды: как снизить значительный бизнес-риск коронавируса. Получено 13 мая 2020 г., из https://www.scruminc.com/distributed-teams-how-to-mitigate-a-significant-business-risk-of-the-coronavirus/
  24. ^ Бозе, И., 2008. Уроки, извлеченные из распределенных гибких программных проектов: анализ на основе конкретных случаев. Коммуникации Ассоциации информационных систем, 23 (1), стр.34.
  25. ^ Рамеш Б., Цао Л., Мохан К. и Сюй П., 2006. Может ли распределенная разработка программного обеспечения быть гибкой? Сообщения ACM, 49 (10), стр.41-46.

внешняя ссылка