stringtranslate.com

Следуй за солнцем

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

Follow-the-sun (FTS), подраздел глобально распределенной программной инженерии (GDSE) , представляет собой тип глобального потока знаний, разработанный для сокращения времени выхода на рынок , в котором продукт знаний принадлежит и продвигается производственным участком в одном часовом поясе и передается в конце рабочего дня следующему производственному участку, который находится на несколько часовых поясов западнее, для продолжения работы. [1] [2] В идеале рабочие дни в этих часовых поясах перекрываются таким образом, что когда один участок заканчивает свой день, начинается следующий.

FTS имеет потенциал для значительного увеличения общего времени разработки в день (с точки зрения одного часового пояса): при наличии двух площадок время разработки может увеличиться до 16 часов или до 24 часов при наличии трех площадок, что сокращает продолжительность разработки на целых 67%.

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

История

Follow-the-sun можно проследить до середины 1990-х годов, когда IBM создала первую глобальную команду разработчиков программного обеспечения, специально созданную для использования преимуществ FTS. [4] Команда была распределена по пяти сайтам по всему миру. К сожалению, в этом случае FTS не увенчалась успехом, поскольку было необычно передавать программные артефакты ежедневно.

Два других случая FTS в IBM были задокументированы Трейненом и Миллер-Фростом. [3] Первая команда была распределена по площадке в Соединенных Штатах и ​​площадке в Австралии. FTS была успешной для этой команды. Вторая команда была распределена по площадке в Соединенных Штатах и ​​площадке в Индии. В этом случае FTS не увенчалась успехом из-за недопонимания, проблем с часовыми поясами и культурных различий.

Принципы

FTS основана на четырех принципах:

  1. Основная цель — сокращение сроков разработки/ вывода продукта на рынок .
  2. Производственные площадки находятся во многих часовых поясах друг от друга.
  3. Всегда существует только одна площадка, которая владеет проектом и работает над ним.
  4. Передача осуществляется ежедневно в конце каждой смены. Следующая производственная площадка находится на несколько часовых поясов западнее.

Распространенные заблуждения

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

Трудности

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

Основная причина, по которой FTS трудно реализовать, заключается в том, что передачи являются существенным элементом, который трудно сделать правильно. Самым большим фактором, вызывающим эту трудность, является плохая коммуникация. [3]

Существует несколько задокументированных случаев успешного применения FTS компаниями. [3] Некоторые компании заявили об успешном внедрении FTS, но эти компании не практиковали ежедневную передачу данных. [3] [6] Тем не менее, Кэмерон обнаружил ограниченное количество успешных применений FTS, которые включали ежедневную передачу данных артефактов с использованием распределенно-параллельной модели [2] . [7]

Недавние исследования FTS перешли к математическому моделированию FTS. [8] [9] [10] [11] [12] Исследования сосредоточены на вопросах скорости и проблемах, связанных с передачей обслуживания.

Методы

Поскольку FTS является подразделом GDSE, [4] те же гибкие методологии разработки программного обеспечения, которые хорошо зарекомендовали себя в GDSE, хорошо работают и с FTS. [2] В частности, Кармель и др. (2009) утверждают, что гибкие методологии разработки программного обеспечения способствуют принципам FTS, поскольку они: [1]

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

Вызовы

Кролл и др. (2013) исследовали статьи, опубликованные в период с 1990 по 2012 год, и обнаружили 36 лучших практик и 17 проблем для FTS. [13] Проблемы были сгруппированы в три категории: координация, коммуникация и культура. Эти проблемы необходимо преодолеть для успешного внедрения FTS.

Координация

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

Культура

Лучшие практики

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

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

Следуй за Луной

Схожая концепция — «следуй за луной» , которая заключается в планировании работ, которые будут выполняться специально в ночные часы по местному времени, по таким причинам, как экономия затрат на центр обработки данных за счет использования более дешевой электроэнергии в ночное время [14] или резервной вычислительной мощности.

Другие термины

Смотрите также

Примечания и ссылки

  1. ^ abcd Кармель, Э., Дубинский, И. и Эспиноза, А. (2009, январь). Разработка программного обеспечения Follow the Sun: новые перспективы, концептуальная основа и исследовательское полевое исследование. В System Sciences, 2009. HICSS'09. 42-я Гавайская международная конференция (стр. 1-9). IEEE.
  2. ^ abcd Кармель, Э., Эспиноза, JA, и Дубинский, Y. (2010). Рабочий процесс «Следуй за солнцем» в глобальной разработке программного обеспечения. Журнал систем управленческой информации, 27(1), 17-38.
  3. ^ abcde Treinen, JJ, & Miller-Frost, SL (2006). Вслед за солнцем: примеры глобальной разработки программного обеспечения. IBM Systems Journal, 45(4), 773-783.
  4. ^ ab Carmel, E. (1999). Глобальные команды разработчиков программного обеспечения: сотрудничество вне границ и часовых поясов. Prentice Hall PTR.
  5. ^ Эспиноза, JA, Каммингс, JN, Уилсон, JM, и Пирс, BM (2003). Проблемы границ команд в нескольких глобальных фирмах. Журнал систем управленческой информации, 19(4), 157-190.
  6. ^ Яп, М. (2005, июль). Следуйте за солнцем: разработка распределенного экстремального программирования. В Agile Conference, 2005. Труды (стр. 218-224). IEEE.
  7. ^ Александр Кэмерон (август 2003 г.). «Конференция Rational Users 2003. Сокращение времени вывода продукта на рынок с помощью методов Follow-the-Sun».
  8. ^ Эспиноза, JA, и Кармель, E. (2003, май). Моделирование затрат на координацию из-за разделения времени в глобальных командах разработчиков программного обеспечения. В Глобальном семинаре по разработке программного обеспечения, Международная конференция по программной инженерии (ICSE) (стр. 64-68).
  9. ^ Jalote, P., & Jain, G. (2006). Назначение задач в 24-часовой модели разработки программного обеспечения. Журнал систем и программного обеспечения, 79(7), 904-911.
  10. ^ Setamanit, SO, Wakeland, W., & Raffo, D. (2007). Использование моделирования для оценки глобальных стратегий распределения задач разработки программного обеспечения. Software Process: Improvement and Practice, 12(5), 491-503.
  11. ^ Сурадж, П. и Мохапатра, П. К. (2008). Моделирование круглосуточного процесса разработки программного обеспечения. Стратегический аутсорсинг: международный журнал, 1(2), 122-141.
  12. ^ Тавил, А. и Бреретон, П. (2006). Моделирование разработки программного обеспечения в разных часовых поясах. Информационные и программные технологии, 48(1), 1-11.
  13. ^ ab Kroll, J., Hashmi, SI, Richardson, I., & Audy, JL (2013, август). Систематический обзор литературы по лучшим практикам и проблемам в разработке программного обеспечения follow-the-sun. В Global Software Engineering Workshops (ICGSEW), 8-я международная конференция IEEE 2013 г. (стр. 18-23). ​​IEEE.
  14. ↑ Джефф Карузо (19 августа 2009 г.). «Следуйте за луной и спасите миллионы».

Внешние ссылки