태양을 쫓다

글로벌 유통 소프트웨어 엔지니어링(GDSE)의 하위 분야인 FTS(Follow the Sun, FTS)는 지식제품을 한 시간대에 생산현장에서 소유·진출해 업무 종료 시 다음 생산현장으로 넘겨주는 글로벌 지식 워크플로우의 일종이다.서부 표준 시간대로 작업을 계속하십시오.^[1][2] 이상적으로는 이러한 시간대의 근무일이 겹쳐서 한 사이트가 하루 일과를 마치면 다음 사이트가 시작되는 것이다.

FTS는 하루 총 개발 시간을 크게 늘릴 수 있는 잠재력을 가지고 있다(단일 시간대의 관점에서 볼 때). 두 개의 부지로 개발 시간을 최대 16시간, 또는 3개의 부지가 있는 경우 최대 24시간까지 늘릴 수 있어 개발 기간을 최대 67%까지 단축할 수 있다.

그것은 산업에서 일반적으로 실행되지 않으며 성공적으로 적용되는 문서화된 사례가 거의 없다.^[3] 이는 흔치 않은 요구사항으로 인해 FTS를 실제로 성공적으로 적용하는 방법에 대한 지식이 부족하기 때문일 수 있다.

역사

팔로우 더 선은 1990년대 중반으로 거슬러 올라갈 수 있다. IBM은 FTS를 이용하기 위해 특별히 설립된 최초의 글로벌 소프트웨어 팀을 가지고 있었다.^[4] 그 팀은 전 세계 5개 사이트에 퍼져 있었다. 불행히도 이 경우 FTS는 소프트웨어 유물을 매일 나눠주는 일이 드물었기 때문에 성공하지 못했다.

Treinen과 Miller-Frost에 의해 IBM에서 FTS의 다른 두 사례가 문서화되었다.^[3] 첫 번째 팀은 미국의 한 사이트와 호주의 한 사이트로 퍼져나갔다. FTS는 이 팀에서 성공적이었다. 두 번째 팀은 미국의 한 사이트와 인도의 한 사이트로 퍼져나갔다. 이 경우 FTS는 의사소통 오류, 시간대 문제 및 문화적 차이로 인해 성공하지 못했다.

원칙

FTS는 다음 4가지 원칙에 기초한다.

1. 주요 목표는 개발 기간/시장 출시 기간 단축이다.
2. 생산 현장은 시간대가 많이 다르다.
3. 프로젝트를 소유하고 운영하는 사이트는 항상 하나뿐입니다.
4. 핸드오프는 각 교대 근무가 끝날 때마다 매일 실시된다. 다음 생산지는 몇 개의 시간대가 서쪽이다.

일반적인 오해

FTS를 정의하는 중요한 단계는 FTS가 아닌 것을 명확히 설명하기 위해 FTS를 전세계적으로 분산된 다른 구성으로부터 분리하는 것이다. 다음과 같은 4가지 유형의 유사 글로벌 분산 구성은 FTS가 아니다.^[2]

• 글로벌 지식작업은 지리적으로 분산된 지식인력이 여러 위치에서 협력적으로 일하는 것으로 정의된다.^[5] 이것은 FTS가 아니다 왜냐하면 핸드오프가 없기 때문이다.
• 24시간 연중무휴 서비스. 이 구성에서는 해당 시간에 가능한 작업자에게 배포된다. FTS는 기간 단축에 초점을 맞추고 일일 핸드오프를 수행하기 위해 서로 다른 사이트 간의 종속성을 필요로 하는 반면, 가용성에 초점을 맞추고 작업자의 의존성은 거의 없다.
• 24시간 제조. 이 구성은 교대조당 직원 수를 늘림으로써 더 이상 생산할 수 없는 값비싼 자원을 완벽하게 최적화하는 작업에 초점을 맞춘다. 그러나, 자원 비용을 절감하는 이 동인은 FTS의 동인은 아니다.
• 정렬된 다중 교대. FTS와는 대조적으로, 이 구성은 노동력이 저렴하고 동시에 8시간 교대 근무를 하는 한 장소를 선택한다.

어려움

FTS의 가장 큰 강점은 여러 시간대에 걸쳐 개발을 확산시키는 동시에 가장 큰 약점이다. 그것의 분산된 작업흐름은 문화적, 기술적 차이뿐만 아니라 시간의 차이로 인해 조정과 의사소통이 어려워져 실행하기가 더 복잡하다.

FTS가 구현이 어려운 주된 이유는 핸드오프가 제대로 전달되기 어려운 필수 요소이기 때문이다. 이런 어려움을 초래하는 가장 큰 요인은 의사소통 불량이다.^[3]

기업들이 FTS를 성공적으로 적용한 사례는 문서로 거의 없다.^[3] 일부 기업은 FTS를 성공적으로 구현한다고 주장했지만 이들 기업은 매일의 핸드오프를 실천하지 않았다.^[3][6] 그러나, FTS의 일일 핸드오프를 포함했던, 분산-전류 모델을 사용한 FTS의 제한된 양의 성공적인 적용이 카메론에 의해 발견되었다.^[2][7]

FTS에 대한 최근의 연구는 FTS의 수학적 모델링으로 옮겨갔다.^{[8][9][10][11][12]} 이 연구는 속도 문제와 핸드오프를 둘러싼 문제에 초점을 맞추고 있다.

방법들

FTS는 GDSE의 하위 분야인 만큼 GDSE에서 잘 작동한다고 판명된 것과 동일한 민첩한 소프트웨어 개발 방법론이 FTS와 잘 통한다.^[4][2] 특히, 카멜 외 (2009) 신속한 변화를 위한 소프트웨어 개발 방법이 FTS 원칙을 보조한다고 주장하는 이유는 다음과 같다.^[1]

1. 매일의 핸드오프를 지지하다 소스 코드의 지속적인 통합과 자동화된 통합을 통해 각 사이트는 업무일 중 자체 코드 베이스에서 작업할 수 있으며, 통합은 다음 사이트에서 사용할 업데이트되고 테스트 가능한 코드를 유지한다.
2. 통신을 다루다 민첩한 방법론은 소통을 강조한다. 이들은 특히 한 사이트 내에서 할 수 있는 대면 커뮤니케이션을 강조한다. FTS는 사이트 간 통신을 줄이는 것을 목표로 하고 있기 때문에, 대면 측면은 민첩한 개발 방법론의 전체적인 적용에 큰 장애가 되지 않는다.
3. 협력과 협력을 이끌어내다 FTS는 더 많은 협업과 협력이 필요하기 때문에 특히 이러한 강조가 유용하다.

과제들

크롤 외 연구진(2013년)은 1990년부터 2012년 사이에 발표된 논문을 연구했으며, FTS의 모범 사례 36건과 17건의 과제를 발견했다.^[13] 도전과제는 조정, 소통, 문화의 3가지 범주로 분류되었다. FTS를 성공적으로 구현하려면 이러한 과제를 극복해야 한다.

조정

• 시간대 차이는 실시간 협업 기회를 감소시킨다. 팀원들은 외진 동료들과 중첩될 수 있도록 융통성이 있어야 한다. 제한된 중복과 대응 지연은 조정에 부정적인 영향을 미친다.
• 일일 핸드오프 사이클이나 진행 중인 작업 분기는 FTS의 요구 사항이다. FTS가 없으면 출시 시간을 줄일 수 없기 때문이다.
• 지리적 분산
• 원가추정
• 팀성 상실
• 사이트 수
• 조정파괴
• 경영상의 어려움
• 기술 플랫폼

커뮤니케이션

• 커뮤니케이션 리치/대면 커뮤니케이션 손실
• 사회문화다양성애로
• 동기식 통신
• 언어차이
• 기술적 어려움
• 종교적 또는 국경일을 관리한다.

문화

• 문화적 차이
• 서로 다른 기술 배경

모범 사례

민첩한 소프트웨어 개발이나 폭포 모델을 사용하는 등 일상적인 핸드오프를^[1][13] 위한 방법론을 선택하고 조정하는 것이 매우 중요하다.

확인된 모범 사례로는 민첩한 방법을 사용하고 FTS 활동을 개발하기 위한 기술을 사용하는 것이다. 애자일리는 FTS에서 중요한 과제인 일일 핸드오프를 지원한다.^[1] 관리 도구를 사용하여 일정을 예측하고 계획하며 스프린트를 관리하고 진행 상황을 추적할 수 있다. 또한, 회의 비디오, 이메일, 전화 통화와 같은 기술은 구현하기 쉽고 기업들이 팀들 간의 동기식 및 비동기식 통신을 수행할 수 있도록 하며 민첩한 환경에서 잘 작동한다.

불행히도 FTS는 다양한 방법으로 적용될 수 있기 때문에 가장 잘 작동하는 확실한 모범 사례는 없다.

달을 따라가기

이와 관련된 개념은 보다 저렴한 야간 전기^[14] 또는 예비 처리 능력을 사용하여 데이터 센터 비용을 절감하는 등의 이유로 현지 야간 시간 동안 특별히 수행될 작업을 스케줄링하는 사후 관리(Folfollow the month-the-moon은 다음과 같은 개념이다.

기타 용어

• 24시간 개발
• 24시간 개발

참고 항목

• 출시 시간
• 교대조 보고서

참고 및 참조

외부 링크

• 업계에서의 사용 예 - IT 지원