클라이언트의 확장된 분산 팀으로서 애자일 프로젝트를 실행하는 방법

Computereconomics의 최근 보고서에 따르면 2018/19년 기간에 애플리케이션 개발 프로세스가 최대 아웃소싱 기회를 목격하는 것으로 나타났습니다. 전 세계 조직의 56%가 개발 요구 사항을 아웃소싱했습니다.

모바일 앱 개발 요구 사항에 대한 아웃소싱에 대한 수요가 높아진 이유는 항상 같았습니다. 자국 개발자를 고용하는 경우보다 적은 비용으로 주요 비즈니스에 더 집중할 수 있고 더 나은 서비스 품질을 제공합니다.

그러나 애플리케이션 개발 산업에서 아웃소싱이 중심적인 위치를 차지하고 있음에도 불구하고 클라이언트가 소프트웨어 개발 프로젝트를 지리적 국가 외부에 아웃소싱할 계획을 세울 때 표시하는 몇 가지 공통된 우려 사항이 있음을 발견했습니다.

이 기사에서는 Appinventiv가 분산된 애자일 개발 주기 를 사용하여 역외 클라이언트 와 협력하여 전체에 걸쳐 정렬된 위험 및 보상 모델과 함께 보다 연결된 작업 프로세스를 허용하는 방법을 살펴볼 것입니다.

그러나 우리가 고객의 분산 팀으로 운영하는 방법과 원활하게 작동하여 확장된 사내 기술 팀이 되는 부분으로 넘어가기 전에 Distributed Agile Team 이 의미하는 바를 아는 것이 중요합니다.

분산 애자일 팀 의 의미  

분산 팀은 한 도시에 있는 하나의 사무실 공간이나 두 개의 사무실 공간이 아닌 여러 지리적 위치에서 둘 이상의 팀이 기능하는 이벤트를 설명하는 데 사용되는 개념입니다.
분산된 애자일 팀은 디지털 기술에 의존하여 원활하게 상호 작용하고 동일한 목표인 적시 프로젝트 제공을 위해 함께 일합니다.

기업이 모바일 앱 개발 분산 팀에 투자하는 이유는 무엇입니까?

기업이 분산된 팀에 투자하도록 유도하는 여러 가지 이유는 다음과 같습니다.

1. 자국에서 숙련된 개발자의 부족
2. 팀 구축을 위한 투자를 하기 전에 시장을 테스트할 필요가 있습니다.
3. 앱을 확장할 때 증가할 수 있고 필요가 끝나면 해산할 수 있는 유연한 팀의 이점을 활용하기 위해.

이제 정의와 필요성에 주의를 기울였으므로 이제 Appinventiv 팀이 분산된 클라이언트 팀으로 작동하는 방법을 살펴보겠습니다. 그러나 여기로 이동하기 전에 일반적인 분산 애자일 팀 구조 가 어떻게 보이는지 빠르게 살펴보겠습니다.

분산 애자일 개발에 대한 Appinventiv 접근 방식  

종종 우리는 요구 사항에 따라 고객의 FTE와 긴밀하게 연결하여 작업해야 하는 프로젝트를 받습니다. 이럴 때 일과 일 사이에 천 마일이라는 거리가 생기지 않도록 하고, 실시간으로 발전 과정을 변경하고 조치를 취할 수 있는 것이 매우 중요해집니다.

의사 소통 지연과 오해가 없는 범위에서 적시에 전달을 보장하는 방법은 Distributed Agile Methodology 에 답이 있습니다 .

소규모 및 대규모 비즈니스 모두에 적합하며 분산된 애자일 모범 사례 를 따르는 것은 완전히 다른 시간대의 다른 지리적 위치에 있는 팀과 함께 작업해야 할 때 매우 유용합니다.

모바일 앱 개발 프로세스에 적용한 분산 애자일 개발 방법을 살펴보겠습니다.

모든 팀원을 서로 소개하고 프로젝트 관리 소프트웨어를 공동 작업한 후 실제 작업이 시작됩니다.

우리는 매일의 애자일 스크럼 방법론 의 프로세스를 공식화합니다 . 전통적인 의미에서 스크럼은 모든 참가자가 자신의 작업 상태를 공유하고 다음에 수행할 작업을 팀에 알리는 15분의 대면 회의를 요구하지만 절반이 팀의 일부는 다른 시간대의 다른 지리적 국가에 있습니다.

스크럼에서 대면 상호 작용의 본질을 유지하기 위해 우리가 하는 일은 프로젝트에 참여하는 팀의 모든 사람에게 적합한 정해진 시간에 화상 통화를 하는 것입니다. 화면 공유의 도움으로 Agile Scrum Master 는 Trello 또는 Jira와 같은 도구의 도움으로 가상 스프린트 백로그를 실행하여 모든 팀 구성원이 프로젝트가 향하는 방향에 대한 업데이트를 제공할 수 있도록 합니다.

우리가 경험한 바에 따르면 모든 팀 구성원에게 쉽게 액세스하고 업데이트할 수 있는 작업 추적 플랫폼에 대한 액세스 권한을 부여하는 것이 매우 중요합니다. 또한 모든 사람이 두 스크럼 기간 사이에 업데이트를 공유하거나 의문점을 제기할 수 있도록 Skype 또는 Slack과 같은 커뮤니케이션 플랫폼을 사용하는 것을 강조합니다.

우리가 매일의 애자일 및 스크럼 프로세스를 위해 따르는 또 다른 접근 방식은 모든 다른 스크럼에 대해 한 명의 스크럼 마스터를 지정하는 것입니다. 따라서 모든 개별 팀은 스크럼 마스터와 제품 소유자가 있는 별도의 스크럼 팀으로 작업합니다. 이 프로세스를 스크럼의 스크럼이라고도 합니다.

여기에서 모든 스크럼 담당자는 스크럼에서 다음 질문에 대한 답변을 제공합니다.

• 마지막 Scrum of Scrums 이후로 팀이 완료한 작업
• 작업 팀은 다음 Scrum of Scrums 회의 전에 할 계획입니다.
• 팀이 직면한 현재의 블로커
• 다른 Scrum 팀으로 이어질 수 있는 차단기.

이 방법을 사용하면 프로젝트에 참여하는 모든 주요 개인이 서로 직접 상호 작용할 수 있으며, 이는 시작 단계에서 출시 기간까지 항상 헌신하는 결과를 낳습니다. 이를 통해 모든 팀 간에 개방적이고 명확하며 투명한 의사 소통이 가능하며 모든 사람에게 발언권이 주어집니다.
스크럼의 스크럼을 제외한 프로세스는 일반적인 애자일 방법론에서 따르는 것과 동일합니다.
그러나 우리 팀과 고객 팀 사이의 거리가 몇 마일 떨어져 있지만 가능한 한 원활하게 일해야 한다는 사실만으로도 우리는 Distributed Agile을 채택함으로써 일련의 학습을 이끌어냈습니다. 그 학습 내용이 무엇인지 살펴보겠습니다.

분산 애자일 개발 프로세스 작업을 통해 얻은 학습

1. 분산된 팀 구성은 프로세스가 아닌 문화 구축에 관한 것입니다.

분산된 팀을 위한 애자일 접근 방식에 따라 작업하는 프로젝트의 성공을 정의하는 것은 팀 구성원의 숙련도가 아니라 팀원이 함께 작업할 수 있는 정도, 함께 일하는 주인의식, 궁극적으로 어떻게 하느냐에 달려 있습니다. 그것들은 프로젝트의 목표, 즉 프로세스 형성이 아닌 문화와 함께 제공되는 목표와 밀접하게 연관되어 있습니다.

2. SMART 프로젝트만 성공

사무실은 물론이고 같은 국가에 있지도 않은 팀이 프로젝트를 완료해야 하는 경우 프로젝트에 대해 설정한 목표가 SMART(특정, 측정 가능, 달성 가능, 현실적, 시간)를 따르는 것이 매우 중요합니다. -프레임, 개념 t.

3. 온라인 협업 도구의 대안은 없습니다.

비용이 얼마나 들든 상관없이 실시간으로 지연이 최소화된 온라인 협업 도구에 의존해야 합니다. 온라인 프로젝트 관리 및 커뮤니케이션 플랫폼을 완성하는 측면에서 어쨌든 여유를 줄일 수는 없습니다. 기술적으로 요구 사항을 처리할 수 있는지 확인해야 합니다.

분산 팀으로서 광범위한 작업 경험에서 얻은 교훈을 살펴보았으므로 이제 프로세스 동안 직면한 몇 가지 문제와 이를 어떻게 해결하여 신뢰할 수 있는 분산 애자일 앱 이 되었는지 살펴보겠습니다. 개발 회사 .

분산 애자일 개발 접근 방식의 과제 및 해결 방법

1. 문화의 차이

일반적으로 분산된 애자일 소프트웨어 개발 접근 방식은 다양한 문화적 배경을 가진 팀과 협력해야 합니다. 이 차이는 서로 다른 가치관과 말투로 인해 마찰을 일으킵니다.
우리의 솔루션: 우리는 라인과 컨텍스트 사이에 익숙해질 수 있도록 처음 며칠 동안 클라이언트 팀과 매우 긴밀하게 협력합니다.

2. 시간대의 차이

분산 애자일 방법론 의 핵심은 여러 지리적 국가에서 작업하는 팀입니다. 이와 같은 상황에서 시차로 인한 커뮤니케이션 갭이 발생하는 경우는 매우 흔하다.
우리의 솔루션: 우리는 분산된 팀의 애자일 개념을 핵심으로 따릅니다. 모든 국가의 팀이 참석하여 활동하는 시간을 수정합니다. 완전한 집중과 주의를 끌기 위해 우리는 팀원들에게 스크럼 당일 사무실 시간을 변경하여 숙면을 취하고 주의를 기울이도록 요청합니다.

3. '빅 픽처'에 대한 공통 개념의 부재

지리적 위치, 작업 구조 및 정책의 차이로 인해 모바일 앱의 최종 목표인 큰 그림에 대한 아이디어에 불일치가 있을 수 있습니다. 이러한 차이로 인해 일부 팀 구성원에게는 관심이 부족하고 다른 구성원에게는 관심이 높아질 수 있습니다.
우리의 솔루션: 프로젝트 시작 시 비전 회의 및 모든 스크럼에서 알림을 통해 모든 사람이 동일한 목표를 향해 노력하고 있습니다.

4. 코드 소유권의 부재

공동 코드 소유권이 없다는 것은 아무도 코드를 소유하지 않고 전체 팀이 소유하므로 문제가 발생하면 비난 게임이 시작된다는 것을 의미합니다.
우리의 솔루션: 우리는 버전 제어 시스템을 적용하여 누가 코드 작업을 하고 있는지, 언제 그리고 그 효과를 확인합니다. 이렇게 하면 그림에 완전한 투명성과 정직함이 있습니다.

이것이 Appinventiv가 전 세계 어디에서나 소속된 분산된 클라이언트 팀이 된 방법에 대한 이야기입니다.
분산된 애자일 소프트웨어 개발 수준을 높이는 방법에 대해 논의하고 싶으십니까? 모바일 앱 전략가에게 연락하십시오.