Следуй за солнцем
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: [2]
- Глобальная информационная работа определяется как географически разбросанные интеллектуальные работники, работающие совместно из разных мест. [5] Это не ФНС, потому что нет никаких передач обслуживания.
- Круглосуточное обслуживание . В этой конфигурации работа распределяется между доступными в данный момент рабочими процессами. Он ориентирован на доступность, и работники практически не зависят друг от друга, тогда как FTS ориентирован на сокращение продолжительности и требует наличия зависимостей между различными сайтами для выполнения ежедневных передач обслуживания.
- Круглосуточное производство. Эта конфигурация ориентирована на то, чтобы смены полностью оптимизировали дорогостоящие ресурсы, которые не могли производить больше, за счет увеличения количества сотрудников в смену. Однако этот драйвер снижения стоимости ресурсов не является драйвером ФНС.
- Совместное размещение в несколько смен. В отличие от FTS, эта конфигурация выбирает одно место, где рабочая сила дешевая, и одновременно работает в несколько восьмичасовых смен.
Трудности [ править ]
Самая сильная сторона ФСТ, заключающаяся в том, что ее деятельность охватывает несколько часовых поясов, одновременно является ее самой большой слабостью. Его распределенный рабочий процесс сложнее реализовать из-за культурных и технических различий, а также различий во времени, что затрудняет координацию и общение.
Основная причина сложности внедрения FTS заключается в том, что передача управления является важным элементом, который трудно реализовать правильно. Самым большим фактором, вызывающим эту трудность, является плохая связь. [3]
Задокументированных случаев успешного применения ФНС компаниями немного. [3] Некоторые компании заявили, что успешно внедрили FTS, но эти компании не практиковали ежедневную передачу полномочий. [3] [6] Однако ограниченное количество успешных применений FTS, которые включали ежедневную передачу артефактов с использованием модели распределенного одновременного выполнения, [2] были найдены Кэмероном. [7]
Недавние исследования FTS перешли к математическому моделированию FTS. [8] [9] [10] [11] [12] Исследование сосредоточено на проблеме скорости и проблемах, связанных с передачей обслуживания.
Методы [ править ]
Поскольку FTS является подразделом GDSE, [4] те же гибкие методологии разработки программного обеспечения, которые хорошо зарекомендовали себя в GDSE, хорошо работают и с FTS. [2] В частности, Кармель и др. (2009) утверждают, что гибкие методологии разработки программного обеспечения помогают принципам FTS, потому что они: [1]
- Поддержка ежедневных передач: непрерывная интеграция и автоматическая интеграция исходного кода позволяют каждому сайту работать со своими собственными базами кода в течение рабочего дня, в то время как интеграция поддерживает обновленный, тестируемый код, который будет использоваться следующим сайтом.
- Работайте с коммуникацией: в гибких методологиях упор делается на коммуникацию. Они особо подчеркивают личное общение, которое можно осуществить в рамках одного сайта. Поскольку FTS стремится сократить межсайтовое общение, личный аспект не является большим препятствием для общего применения методологий гибкой разработки.
- Выявляйте сотрудничество и сотрудничество: поскольку ФНС требует большего сотрудничества и сотрудничества, этот акцент особенно полезен.
Проблемы [ править ]
Кролл и др. (2013) изучили статьи, опубликованные в период с 1990 по 2012 год, и выявили 36 передовых практик и 17 проблем для ФНС. [13] Проблемы были сгруппированы в три категории: координация, коммуникация и культура. Эти проблемы необходимо преодолеть для успешного внедрения ФСТ.
Координация [ править ]
- Различия в часовых поясах сокращают возможности для совместной работы в режиме реального времени. Члены команды должны проявлять гибкость, чтобы добиться дублирования работы с удаленными коллегами. Ограниченное дублирование и задержка ответов отрицательно сказываются на координации.
- Ежедневные циклы передачи или передачи незавершенного производства являются требованием ФСТ, поскольку без этого невозможно сократить время вывода продукции на рынок.
- Географическая разбросанность
- Оценка стоимости
- Потеря командности
- Количество сайтов
- Нарушение координации
- Управленческие трудности
- Технические платформы
Общение [ править ]
- Потеря богатства общения / личное общение
- Трудности социального культурного разнообразия
- Синхронная связь
- Языковая разница
- Технические трудности
- Управляйте религиозными или национальными праздниками.
Культура [ править ]
- Культурные различия
- Разное техническое образование
Лучшие практики [ править ]
Очень важно выбрать и адаптировать методологию ежедневной передачи [1] [13] например, используя гибкую разработку программного обеспечения или водопадную модель .
Выявленные лучшие практики – это использование гибких методов и технологий для развития деятельности ФНС. Agile поддерживает ежедневную передачу управления, что является критической проблемой в FTS. [1] Инструменты управления можно использовать для оценки и планирования графиков, управления спринтами и отслеживания прогресса. Кроме того, такие технологии, как видеоконференция, электронная почта и телефонные звонки, просты в реализации и позволяют компаниям осуществлять синхронное и асинхронное общение между командами и хорошо работают в гибкой среде.
Следовать за Луной [ править ]
Связанная с этим концепция — «следование за луной» , которая планирует выполнение работ специально в ночное время по местному времени по таким причинам, как экономия на центры обработки данных затрат за счет использования более дешевой электроэнергии в ночное время. [14] или запасную вычислительную мощность.
Другие термины [ править ]
- 24-часовая разработка
- круглосуточное развитие
См. также [ править ]
Примечания и ссылки [ править ]
- ↑ Перейти обратно: Перейти обратно: а б с д Кармель Э., Дубинский Ю. и Эспиноза А. (январь 2009 г.). Следуйте за разработкой программного обеспечения Sun: новые перспективы, концептуальная основа и поисковые полевые исследования. В системных науках, 2009. HICSS'09. 42-я Гавайская международная конференция (стр. 1–9). IEEE.
- ↑ Перейти обратно: Перейти обратно: а б с д Кармель Э., Эспиноза Дж. А. и Дубинский Ю. (2010). Рабочий процесс «Следуй за солнцем» в глобальной разработке программного обеспечения. Журнал информационных систем управления, 27 (1), 17-38.
- ↑ Перейти обратно: Перейти обратно: а б с д и Трейнен, Джей-Джей, и Миллер-Фрост, С.Л. (2006). Следуя за солнцем: практические примеры глобальной разработки программного обеспечения. IBM Systems Journal, 45(4), 773-783.
- ↑ Перейти обратно: Перейти обратно: а б Кармель, Э. (1999). Глобальные команды разработчиков программного обеспечения: сотрудничество, невзирая на границы и часовые пояса. Прентис Холл PTR.
- ^ Эспиноза, Дж. А., Каммингс, Дж. Н., Уилсон, Дж. М., и Пирс, Б. М. (2003). Проблемы границ команд в нескольких глобальных фирмах. Журнал информационных систем управления, 19 (4), 157–190.
- ^ Яп, М. (2005, июль). Следуй за солнцем: разработка распределенного экстремального программирования. На конференции Agile, 2005 г. Материалы (стр. 218–224). IEEE.
- ^ Александр Кэмерон (август 2003 г.). «Конференция пользователей Rational 2003. Сокращение времени выхода на рынок с помощью методов следования за солнцем» .
- ^ Эспиноза, Дж. А., и Кармель, Э. (2003, май). Затраты на координацию моделирования из-за разделения времени в глобальных группах разработчиков программного обеспечения. На Глобальном семинаре по разработке программного обеспечения, Международной конференции по программной инженерии (ICSE) (стр. 64-68).
- ^ Джалоте П. и Джайн Г. (2006). Распределение задач в модели круглосуточной разработки программного обеспечения. Журнал систем и программного обеспечения, 79 (7), 904–911.
- ^ Сетаманит, С.О., Уэйкленд, В., и Раффо, Д. (2007). Использование моделирования для оценки глобальных стратегий распределения задач по разработке программного обеспечения. Программный процесс: совершенствование и практика, 12 (5), 491-503.
- ^ Сурадж П. и Мохапатра ПК (2008). Моделирование круглосуточного процесса разработки программного обеспечения. Стратегический аутсорсинг: Международный журнал, 1 (2), 122–141.
- ^ Тавил А. и Бреретон П. (2006). Моделирование разработки программного обеспечения в разных часовых поясах. Информационные и программные технологии, 48(1), 1-11.
- ↑ Перейти обратно: Перейти обратно: а б Кролл Дж., Хашми С.И., Ричардсон И. и Оди Дж.Л. (август 2013 г.). Систематический обзор литературы, посвященный передовому опыту и проблемам в разработке программного обеспечения. На Глобальных семинарах по разработке программного обеспечения (ICGSEW), 8-я Международная конференция IEEE 2013 г. (стр. 18–23). IEEE.
- ^ Джефф Карузо (19 августа 2009 г.). «Следуй за Луной и спаси миллионы» .
- Годинес, Виктор (2 января 2007 г.). «Солнечный свет 24/7: работа EDS прекращается в одном часовом поясе, но возобновляется в другом» . «Утренние новости Далласа» . Проверено 31 октября 2008 г.
- «Следуя за солнцем: тематические исследования глобальной разработки программного обеспечения» . IBM Systems Journal. 1 октября 2006 года . Проверено 31 октября 2008 г.
- «Глобальная сеть колл-центров сокращает расходы Barclays» . Компьютерный еженедельник. 11 октября 2001 года . Проверено 31 октября 2008 г.