사고는 전체적으로, 코딩은 로컬로: 분산된 팀의 비결

분산된 팀과 원격 사무실은 사라지지 않습니다. 하지만 이들이 성장하는 애자일 문화의 일부가 될 수 있을까요? 우리의 대답은 '그렇다'입니다.

Dan Radigan 작성자: Dan Radigan
주제 찾아보기

애자일 개발은 원래 클러스터링된 팀 또는 물리적으로 같은 사무실에 함께 위치한 팀을 위해 구상되었습니다. "개발 팀과 정보를 주고받는 가장 효율적이고 효과적인 방법은 대면 대화"라는 생각에 따라 초기 애자일 팀은 가까운 거리에서 함께 작업해야 했습니다.

그러나 오늘날 대부분의 비즈니스에는 분산된 팀이 몇 개 또는 여러 개 있습니다. 이것은 단순한 트렌드가 아니라 매우 합리적인 것입니다. 분산된 팀은 24시간 내내 프로젝트를 진행할 수 있으며 경쟁이 덜 치열한 시장에서 유능한 인재를 찾을 수 있습니다. (원하지 않는 재배치가 필요하지 않으므로 당연히 인재를 쉽게 유지할 수 있습니다.) 그러나 분산된 팀의 이점에는 약간의 절충도 필요합니다. 많은 분산된 팀의 경우 대면 상호 작용이라는 애자일 관행을 도입하기가 어렵습니다.

분산된 소프트웨어 팀에서 발생하는 기타 과제:

  • 시간대에 걸친 조정
  • 모두가 같은 사무실에 있지 않을 때 관계 구축
  • 다양한 개발 문화 간의 공동 작업
  • 두 팀이 단 몇 시간 동안(또는 더 짧게) 동시에 온라인 상태일 때 회의 또는 비공식 대화 예약

이것이 진짜 문제입니다. 하지만 해결 방법은 있습니다. 로컬 사무실과 원격 사무실 간의 거리 격차를 해소할 수 있는 몇 가지 전략과 다른 잠재적 이슈를 완화할 수 있는 아이디어를 살펴보겠습니다.

글로벌 팀을 구성하는 방법

좋은 소프트웨어 아키텍처는 모듈식 설계를 요구하므로 팀을 동일한 방식으로 구성하세요. 모든 사무실은 단일 기술을 자체 개발하여 다른 시간대에 있는 팀과의 공동 작업을 최소화하고 일반적으로 자율적인 수행이 가능해야 합니다. 프로젝트에서 서로 다른 위치에 있는 팀이 참여해야 하는 경우 통합 지점과 API에 집중할 수 있습니다.

코드 검토도 중요한 역할을 합니다. 인력이 서로 다른 시간에 온라인 상태이기 때문에 사무실 간에 코드 지식을 배포하면 지원 및 유지 관리가 훨씬 쉬워집니다. 팀이 온라인 상태가 아닐 때 프로덕션 이슈가 발생할 경우 교차 팀 또는 교차 위치 코드 검토에서 얻은 노하우를 통해 다른 사무실이 쉽게 개입하여 이슈를 지원하고 해결할 수 있습니다.

관계 구축

모든 프로그램, 특히 애자일 프로그램에서는 팀 전체가 탄탄한 관계를 유지하는 것이 중요합니다. 개인적인 소통은 신뢰를 쌓고, 기대를 놓치는 것을 최소화하며, 자체 조직을 완화하고, 사기를 높입니다. 사무실 내에서 시간을 내어 모든 팀원을 알아가세요. 또한 원격 사무실에서 함께 일하는 인력도 최대한 똑같이 대하세요. 개인적인 소통은 중요합니다. 개인적인 소통이 강해질수록 원격으로 근무하는 동료를 익숙하지 않은 곳에서 멀리 떨어진 좋은 관계가 없는 동료가 아니라 다른 동료와 똑같이 볼 가능성이 커집니다.

프로 팁:

Atlassian에서 각 신규 직원은 Atlassian의 콘텐츠 공동 작업 도구인 내부 Confluence 인스턴스에 "소개 블로그"를 게시합니다. 블로그를 통해 신규 직원을 전문적으로뿐만 아니라 개인적으로(취미, 관심사, 가족 등) 소개하여 사무실 간 격차를 해소할 수 있습니다. 서로를 더 많이 알수록 팀으로서 더 강력하게 함께 일할 수 있습니다.

무엇보다도 얼굴을 맞대고 만나는 것을 대체하는 것은 없습니다. 각 사무실 팀원은 정기적인 대면 만남을 이점을 누릴 수 있으며 여기에는 화상 회의와 원격 사무실 방문이 포함됩니다.

Zoom 같은 화상 회의 도구는 특히 분산된 애자일 팀의 경우 팀 간 격차를 해소해 줍니다. 그러나 Zoom에 의존하는 팀은 특정 제한 사항을 알고 있어야 합니다.

  • 화상 회의는 종종 매우 짧은 커뮤니케이션 기회만 허용하는 반면, 같은 사무실에서 일하면 다른 구성원의 세계(과제, 성공 및 기회)에 대한 상당한 가시성을 얻을 수 있습니다.
  • Zoom은 네트워크 문제를 해결하는 데 효과적이었습니다. 그러나 여전히 사무실 간에 네트워크 이슈가 발생하여 비디오와 오디오가 고르지 않거나 이해하기 어려울 수 있습니다.
  • 대부분은 여전히 Zoom 화상 회의를 예정된 시간으로만 생각합니다. 화상 채팅을 자연스럽고 일상적인 대화에 사용하는 문화를 만드는 데는 시간이 걸립니다. Slack 같은 인스턴트 메시징 도구를 사용하여 빠른 질문을 할 수도 있습니다.

일부 화상 회의 이슈를 완화하려면 팀원들이 매주 1:1 화상 채팅 세션을 갖도록 권장하세요. 형식에 덜 얽매이면서 일상적인 방식으로 지식 공유를 지원할 수 있습니다. 팀원들은 이 기회를 활용하여 관계를 구축하고 더 잘 협력할 수 있습니다.

어조, 목소리, 자세는 커뮤니케이션에서 중요한 역할을 한다는 사실을 기억하세요. 직접 만나서 대화하면 팀이 원격 동료를 더 충실하게 파악할 수 있으며, 향후 화상 회의를 더 효과적으로 만듭니다.

주택이든 제품이든 비전을 정의하고 전략적 테마를 개략적으로 설명해야 합니다. 테마를 조직 전체의 집중 영역으로 생각하세요. 다음 분기, 6개월, 1년 동안 무엇에 집중하고 싶습니까? 어디에 시간과 리소스를 사용하겠습니까? 성능, 사용자 경험, 보안, 경쟁력 있는 새로운 기능(온수 욕조?) 아니면 이 모든 것의 조합입니까?

Atlassian의 방법:

파견 근무는 몇 주에서 1년에 이르는 기간 동안 새로운 직무 역할 또는 위치에 임시 배정됩니다. 팀 전체에 교감을 구축하고 문화를 전파하는 효과적인 방법일 뿐만 아니라 직원들이 다른 문화를 경험할 수 있는 좋은 방법이기도 합니다.

통합 개발 문화 구축

팀이 지역 간 작업을 더 쉽게 하고 공통의 개발자 문화를 공유할 수 있는 4가지 간단한 방법이 있습니다.

  • 모든 지역에서 최대한의 커뮤니케이션
  • 개발 환경 설정 시 마찰 최소화
  • '완료'를 명확하게 정의
  • 효과적인 버그 보고서 제출을 위한 가이드라인 작성

함께 분석해 봅시다.

첫째, 공동 배치된 사무실에서 분산된 문화로 이동할 때 커뮤니케이션은 훨씬 더 어려워집니다. 의사결정을 내릴 때 커뮤니케이션이 필요하다는 것을 이해하도록 팀을 교육하는 것이 첫 번째 과제입니다. 당연하게 들릴지 모르지만 간과하기 쉬운 것입니다. 복도에서의 대화, 비공식 지역 팀 회의 또는 개인이 중요한 결정을 내리는 경우가 많습니다. 또한 작은 결정은 중요하지 않다고 쉽게 넘겨버릴 수도 있습니다.

두 사무실 모두 효율적인 상태를 찾을 때까지 사소한 사항까지 소통하세요.

결정이 내려지면 각 사무실의 모든 팀원이 결정에 대한 내용을 이해하고 이상적으로는 결정의 이유까지 이해해야 합니다. 이메일을 사용하지 마세요. 이메일로는 중요한 정보를 잃어버리기 아주 쉽습니다. 팀원이 팀 전체에서 업데이트를 쉽게 찾아볼 수 있는 위키와 같은 콘텐츠 관리 시스템을 사용하고 이메일이나 Slack 그룹 채팅 도구를 통해 업데이트 알림을 받으세요. Slack을 사용하여 개인과 팀이 커뮤니케이션하고 업데이트를 확인하는 채널을 만들 수도 있습니다. 팀원이 오래된 정보를 가지고 작업하면 장애물에 부딪히고 질문을 하게 되어 지연이 발생합니다. 따라서 팀이 적극적으로 정보를 공유하는 것보다 시간이 훨씬 더 소모됩니다.

프로 팁:

Atlassian에서는 Atlas를 사용하여 팀 간 프로젝트 및 목표에 대한 업데이트를 공유합니다. 주간 요약 이메일 또는 Slack을 통해 업데이트 알림을 받습니다. 이렇게 하면 팀이 열린 자세로 소통하고 업무의 컨텍스트에 대한 공통된 이해를 갖추며 다음과 같은 질문에 답할 수 있습니다.

  • 무슨 작업을 하고 있습니까?
  • ShipIt Day를 진행하는 이유
  • 누가 작업하고 있습니까?
  • 작업 진행률

둘째, 팀 전체의 일관된 개발 환경을 통해 더 쉽게 공동 작업하고 이슈를 추적할 수 있습니다. 시간을 들여 간단한 "시작하기" 가이드를 작성하고 설정을 최대한 자동화하여 첫날의 마찰을 줄이세요.

셋째, 사무실 간에 작업할 때 "완료"의 정의에 대한 명확한 표준을 통해 더 쉽게 기대치를 관리하고 팀 간에 관계를 구축합니다. 완료를 확고하게 정의하면 작업의 모호성이 제거됩니다. 예를 들어 여러 팀이 참여하는 릴리스를 제공하는 경우 코드 작성, 풀리퀘스트 만들기, 코드 검토, 테스트 및 적절한 브랜치에 병합 등 완료의 의미를 명확하게 해야 합니다.

마지막으로 개발을 배포하는 이유는 문제가 발생할 때 모두가 온라인 상태가 아닐 수 있기 때문입니다. 버그 신고 및 문제 해결 방법에 대한 명확한 지침을 마련하면 팀원 누구나 이슈를 더 쉽게 추적할 수 있습니다. 코드 검토와 우수한 자동 테스트도 코드베이스에 대한 지식을 공유하며, 영향을 받는 팀이 수정을 수행하고 변경 사항에 예상치 못한 부작용이 없는지 확인할 수 있습니다. 이렇게 하면 어떤 팀도 블로커가 되지 않습니다.

황금 시간대 최대화

모든 사진작가는 일출과 일몰 직전과 직후의 "황금 시간대"가 멋진 풍경 사진을 찍기에 가장 효과적인 시기임을 알고 있습니다. 분산된 소프트웨어 팀의 황금 시간대는 로컬 팀과 원격 팀이 동시에 각자의 사무실에 있을 때입니다. 모든 팀이 사무실에 있을 때야말로 스탠드업을 하기에 좋은 시기입니다.

시간대 간에 작업을 공유하는 팀의 경우 스탠드업은 일을 이어받기에 좋은 시간이므로 온라인에 막 접속하는 팀이 다른 팀이 중단한 부분부터 다시 시작할 수 있습니다. 또한 화상 회의를 통해 스탠드업을 개최하면 쉽게 질문하고 속도를 높일 수 있으므로 회의가 완료되는 즉시 모든 인력이 즉시 업무에 뛰어들 수 있습니다.

때로는 사무실이 너무 멀리 떨어져 있기 때문에 회의가 한 팀에는 다소 고통을 줄 수 있습니다. (다른 팀과 함께하는 스탠드업 때문에 오전 5시에 일어나야 하나요? 음... 거절할게요.) 원격 팀만 계속 엉뚱한 시간에 나오게 하는 대신 공동 부담이 되도록 회의 시간을 순환하세요. 그러지 않으면 팀의 사기가 꺾일 수 있습니다. 스탠드업 시 팀 전체가 참여하는지 면밀히 모니터링합니다. 부담이 과도하거나 팀이 많은 것을 얻지 못하면 팀원들은 참여를 멈추고 경청 또는 공유를 중단하기 시작합니다. 또한 스탠드업이 매일 회의일 필요는 절대 없습니다. 일주일에 몇 번 원격 팀과 만나고 다른 날을 로컬 스탠드업에 사용하세요. 마찬가지로 스탠드업이 아침 루틴일 필요도 없습니다. 모든 참여자에게 가장 편리한 시간이 하루 중 가장 좋은 시간입니다.

모든 팀이 분산되어 있음

분산된 조직에서는 모든 팀이 멀리 떨어져 있는 것이 현실입니다. 모든 팀은 사무실 간에 업무를 공유하고, 효과적으로 커뮤니케이션하며, 여러 지역에서 일관된 문화를 발전시키는 방법에 적응하고 또 배워야 합니다. 가장 효과적인 팀은 모든 사무실이 다른 사무실로부터 무언가를 배울 수 있다는 사실을 알고 있으므로 반드시 원격 사무실이 본사 문화에 따르도록 강요하지 않습니다. 그들은 모든 지역에서 성공적인 관행을 찾고 공유하려고 노력합니다. 또한 "우리 대 그들" 문화보다는 "우리"를 포용합니다.

때때로 그들도 분산된다는 것이 현실이기 때문입니다. 팀원은 출장 때문에 사무실 밖으로 나가기도 하고, 때때로 집에서 일하면 직원들이 일과 삶의 균형을 더 잘 관리할 수 있습니다. 구조와 투명성을 모두 수용하는 팀은 더 효율적으로 확장됩니다. 프로젝트가 사무실 너머로 확장되면 문화는 자연스럽게 올바른 일을 할 수 있도록 설정됩니다.