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 является отделение ее от других глобально распределенных конфигураций, чтобы четко указать, чем FTS не является. Следующие четыре типа подобных глобально распределенных конфигураций не являются FTS: [2]
- Глобальная интеллектуальная работа определяется как географически рассредоточенные интеллектуальные работники, работающие совместно из разных мест. [5] Это не FTS, потому что нет передачи обслуживания.
- Круглосуточное обслуживание . В этой конфигурации работа распределяется между работниками, которые доступны в это время. Он ориентирован на доступность, и рабочие имеют небольшую зависимость, тогда как FTS сосредоточен на сокращении продолжительности и требует зависимостей между различными сайтами для выполнения ежедневных передач обслуживания.
- Круглосуточное производство. Эта конфигурация направлена на то, чтобы выполнять смены, полностью оптимизируя дорогостоящие ресурсы, которые не могут производить больше, за счет увеличения количества сотрудников в смену. Однако этот драйвер снижения стоимости ресурсов не является драйвером FTS.
- Совместная работа в несколько смен. В отличие от FTS эта конфигурация выбирает одно место, где рабочая сила дешевая, и работает несколько восьмичасовых смен одновременно.
Трудности
Самая сильная сторона FTS - распространение разработки на несколько часовых поясов - одновременно является ее самой большой слабостью. Его распределенный рабочий процесс сложнее реализовать из-за культурных и технических различий, а также различий во времени, затрудняющих координацию и общение.
Основная причина, по которой FTS трудно реализовать, заключается в том, что передача обслуживания является важным элементом, который трудно реализовать правильно. Самым большим фактором, вызывающим эти трудности, является плохое общение. [3]
Есть несколько задокументированных случаев, когда компании успешно применяют ФНС. [3] Некоторые компании заявляли об успешном внедрении FTS, но эти компании не практиковали ежедневную передачу обслуживания. [3] [6] Однако Кэмерон обнаружил ограниченное количество успешных приложений FTS, которые действительно включали ежедневную передачу артефактов с использованием модели распределенного параллелизма [2] . [7]
Недавние исследования FTS перешли к математическому моделированию FTS. [8] [9] [10] [11] [12] Исследование сосредоточено на проблеме скорости и проблемах передачи обслуживания.
Методы
Поскольку FTS является подразделом GDSE [4], те же самые методологии гибкой разработки программного обеспечения, которые, как было установлено, хорошо работают в GDSE, хорошо работают и с FTS. [2] В частности, Carmel et al. (2009) утверждают, что методологии гибкой разработки программного обеспечения помогают принципам FTS, потому что они: [1]
- поддерживать ежедневную передачу обслуживания. Непрерывная интеграция и автоматическая интеграция исходного кода позволяет каждому сайту работать со своими собственными базами кода в течение рабочего дня, в то время как интеграция поддерживает обновленный, тестируемый код для использования на следующем сайте.
- заниматься общением. Гибкие методологии делают упор на общение. В них особое внимание уделяется общению лицом к лицу, которое может осуществляться в рамках одного сайта. Поскольку FTS стремится уменьшить межсайтовый обмен данными, личная встреча не является большим препятствием для общего применения методологий гибкой разработки.
- вызвать сотрудничество и сотрудничество. Поскольку ФНС требует большего сотрудничества и сотрудничества, этот акцент особенно полезен.
Вызовы
Kroll et al. (2013) исследовали статьи, опубликованные между 1990 и 2012 годами, и обнаружили 36 передовых практик и 17 проблем для ФНС. [13] Проблемы были сгруппированы по трем категориям: координация, коммуникация и культура. Эти проблемы необходимо преодолеть для успешного внедрения FTS.
Координация
- Различия в часовых поясах уменьшают возможности для совместной работы в реальном времени. Члены команды должны быть гибкими, чтобы добиться дублирования с удаленными коллегами. Ограниченное совпадение и задержка ответов отрицательно сказываются на координации.
- Ежедневные циклы передачи обслуживания или передача незавершенного производства являются требованием FTS, потому что без этого время выхода на рынок не может быть сокращено.
- Географическая дисперсия
- Оценка затрат
- Утрата сплоченности
- Количество сайтов
- Нарушение координации
- Управленческие трудности
- Технические платформы
Коммуникация
- Потеря разнообразия общения / личное общение
- Социально-культурное разнообразие трудностей
- Синхронное общение
- Языковая разница
- Технические трудности
- Управляйте религиозными или национальными праздниками.
Культура
- Культурные различия
- Различная техническая подготовка
Лучшие практики
Очень важно выбрать и адаптировать методологию для ежедневной передачи обслуживания [1] [13], например, используя гибкую разработку программного обеспечения или водопадную модель .
Выявленные передовые практики - это использование гибких методов и технологий для развития деятельности FTS. Agile поддерживает ежедневную передачу обслуживания, что является важной задачей для FTS. [1] Инструменты управления можно использовать для оценки и планирования расписаний, управления спринтами и отслеживания прогресса. Кроме того, такие технологии, как конференц-связь, электронная почта и телефонные звонки, легко реализовать, они позволяют компаниям осуществлять синхронную и асинхронную связь между командами и хорошо работают в гибкой среде.
К сожалению, не существует надежной передовой практики, которая бы лучше всего работала, поскольку FTS можно применять множеством способов.
Следуй за луной
Связанная с этим концепция - это « следование за луной» , при котором работа по расписанию должна выполняться специально в местные ночные часы по таким причинам, как экономия затрат на центр обработки данных за счет использования более дешевой электроэнергии в ночное время [14] или резервной вычислительной мощности.
Прочие условия
- 24-часовая разработка
- круглосуточное развитие
Смотрите также
Примечания и ссылки
- ^ a b c d Кармель, Э., Дубинский, Ю., и Эспиноза, А. (2009, январь). Следите за разработкой программного обеспечения «Солнце»: новые перспективы, концептуальные основы и полевые исследования. In System Sciences, 2009. HICSS'09. 42-я Гавайская международная конференция (стр. 1-9). IEEE.
- ^ a b c d Кармель, Э., Эспиноза, Дж. А. и Дубинский, Ю. (2010). Рабочий процесс «Следуй за солнцем» в глобальной разработке программного обеспечения. Журнал информационных систем управления, 27 (1), 17-38.
- ^ a b c d e Treinen, JJ, & Miller-Frost, SL (2006). Следуя за солнцем: Примеры глобальной разработки программного обеспечения. IBM Systems Journal, 45 (4), 773-783.
- ^ а б Кармель, Э. (1999). Глобальные команды разработчиков программного обеспечения: сотрудничество через границы и часовые пояса. Prentice Hall PTR.
- Перейти ↑ Espinosa, JA, Cummings, JN, Wilson, JM, & Pearce, BM (2003). Проблемы границ команды в нескольких глобальных компаниях. Журнал информационных систем управления, 19 (4), 157-190.
- Перейти ↑ Yap, M. (2005, июль). Следуй за солнцем: разработка распределенного экстремального программирования. В Agile Conference, 2005. Труды (стр. 218-224). IEEE.
- ^ Александр Кэмерон (август 2003 г.). "Конференция Rational Users 2003. Сокращение времени выхода на рынок с помощью методов" следования за солнцем " .
- Перейти ↑ Espinosa, JA, & Carmel, E. (2003, май). Затраты на координацию моделирования из-за разделения времени в глобальных командах разработчиков программного обеспечения. В Global Software Development Workshop, Международная конференция по программной инженерии (ICSE) (стр. 64-68).
- ^ Jalote, P., & Jain, G. (2006). Постановка задач в 24-часовой модели разработки программного обеспечения. Журнал систем и программного обеспечения, 79 (7), 904-911.
- ^ Setamanit, SO, Wakeland, W., и Raffo, D. (2007). Использование моделирования для оценки глобальных стратегий распределения задач разработки программного обеспечения. Программный процесс: улучшение и практика, 12 (5), 491-503.
- ^ Sooraj, P., & Mohapatra, ПК (2008). Моделирование 24-часового процесса разработки программного обеспечения. Стратегический аутсорсинг: международный журнал, 1 (2), 122-141.
- ^ Taweel, A., & Бреретон, P. (2006). Моделирование разработки программного обеспечения в разных часовых поясах. Информационные и программные технологии, 48 (1), 1-11.
- ^ а б Кролл, Дж., Хашми, С.И., Ричардсон, И., и Ауди, Дж. Л. (2013, август). Систематический обзор литературы, посвященной передовым методам и проблемам в разработке программного обеспечения «вслед за солнцем». В Global Software Engineering Workshops (ICGSEW), 8-я Международная конференция IEEE 2013 г. (стр. 18–23). IEEE.
- ^ Джефф Карузо (19 августа 2009 г.). «Следуй за луной и спаси миллионы» .
- Годинез, Виктор (2 января 2007 г.). «Sunshine 24/7: работа EDS прекращается в одном часовом поясе, а в другом - возобновляется» . Утренние новости Далласа . Проверено 31 октября 2008 года . CS1 maint: обескураженный параметр ( ссылка )
- «За солнцем: примеры из мировой разработки программного обеспечения» . IBM Systems Journal. 1 октября 2006 . Проверено 31 октября 2008 года . CS1 maint: обескураженный параметр ( ссылка )
- «Глобальная сеть колл-центров сокращает расходы Barclays» . Computer Weekly. 11 октября 2001 . Проверено 31 октября 2008 года . CS1 maint: обескураженный параметр ( ссылка )
Внешние ссылки
- Пример использования в промышленности - ИТ-поддержка