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