5가지 애자일 확장 프레임워크 비교: 어떤 것을 사용해야 할까요?

이것을 상상해 보십시오. 프로젝트를 시작할 때 제품 목표를 달성하기 위해 최선을 다하는 단일의 효과적인 교차 기능 개인 팀을 구성합니다. 성능을 개선하려면 팀이 Agile에 능숙하도록 해야 합니다. 제품에 대한 수요가 증가하고 요구 사항이 증가하고 백로그가 확장됩니다. 당신과 다른 이해 관계자는 팀을 확장해야 한다는 것을 알고 있습니다. 익숙한 소리?

확장을 통해 여러 팀이 함께 작업하여 민첩성을 유지할 수 있습니다. 팀이 합리적인 시간 내에 처리할 수 있는 것보다 더 많은 작업을 수행해야 하는 경우 확장해야 합니다. 그러나 그렇게 하려면 올바른 프레임워크를 선택해야 하며 선택할 수 있는 프레임워크가 여러 개 있습니다. 잘못 선택하면 구현이 실패하여 생산성이 저하되고 막대한 재정적 영향을 받을 수 있습니다.

팀에 가장 적합한 프레임워크는 사용 가능한 자금, 조직적 접근 방식, 제품 복잡성과 같은 요소에 따라 달라집니다.

언제 확장해야 합니까?

확장을 고려하기 전에 충족해야 하는 몇 가지 주요 기준이 있습니다.

한 팀만으로 개발을 관리할 수 있습니까?

확장된 Agile 프레임워크를 구현하는 것은 복잡하고 시간이 많이 소요될 수 있으므로 필요하지 않은 경우 확장하지 마십시오. 팀의 워크로드가 기능을 초과하면 확장이 필요합니다.

당신의 팀은 민첩합니까?

아마도 가장 중요한 기준은 애자일 접근 방식에 대한 팀의 숙련도일 것입니다. 팀이 Agile에 익숙하지 않은 경우 확장하면 더 많은 문제가 발생합니다.

팀의 개발 관행에 개선이 필요합니까?

팀의 엔지니어링 방식이 효율적이지 않은 경우 확장을 통해 원하는 결과를 얻지 못할 수 있습니다. DevOps 및 CI/CD 파이프라인의 적절한 구현과 같은 관행은 팀 간의 일관성을 위해 필수적입니다. 또한 표준화된 품질 보증 없이는 새로운 기능을 테스트하기 어려울 수 있습니다.

귀하의 팀은 통합된 증분을 제공합니까?

확장에는 각 팀이 함께 작동하는 기능을 생성하는 동일한 제품에서 공동 작업하는 여러 팀을 통합하는 작업이 포함됩니다. 다음 표는 팀과 제품의 가능한 네 가지 구성에 대해 자세히 설명합니다. 하나만 스케일링이 필요하다는 점에 유의하십시오.

확장 프레임워크 선택

선택할 수 있는 애자일 확장 프레임워크는 많지만 가장 널리 사용되는 5가지 솔루션인 SAFe(Scaled Agile Framework), Nexus, LeSS(Large-Scale Scrum), Scrum@Scale 및 Disciplined Agile(DA)에 중점을 둘 것입니다. . 저는 이것이 가장 효과적인 프레임워크임을 발견했으며 다양한 시나리오와 조직에 적용할 수 있습니다. 다음 섹션에서는 고유한 확장 컨텍스트에 가장 적합한 선택을 하는 데 필요한 정보를 제공합니다.

1. 확장된 애자일 프레임워크(SAFe)

SAFe는 애자일 확장을 위해 가장 널리 사용되는 프레임워크입니다. 2021년 조사에 따르면 애자일 실무자의 37%가 가치 흐름에 중점을 두고 잘 정의된 지침과 절차가 있는 다중 구성으로 인해 애자일을 사용하는 것으로 나타났습니다.

SAFe는 50명 이상의 인력이 필요한 복잡한 솔루션을 제공하는 데 사용되기 때문에 팀을 ART(Agile Release Train)로 구성합니다. ART에서 팀을 동기화하기 위해 SAFe는 스크럼 스프린트와 유사한 프로그램 증분 반복을 사용하며 각 반복은 일반적으로 8주에서 12주 동안 지속됩니다. 이 접근 방식을 통해 제품 관리자는 전체 목표에 계속 집중하고 과도한 변경을 도입하지 않고도 복잡한 제품 로드맵을 효율적으로 감독할 수 있습니다.

SAFe는 Scrum 프레임워크를 기반으로 하지만 몇 가지 주요 차이점이 있습니다. SAFe 채택은 팀 수준이 아닌 엔터프라이즈 수준에서 이루어집니다. Scrum은 우선 순위에 대한 독점 권한을 제품 소유자에게 부여하지만 SAFe는 보다 민주적인 접근 방식을 권장합니다.

SAFe에는 네 가지 수준의 구현이 있습니다.

필수 SAFe

필수 SAFe는 SAFe의 기초이며 후속 구성으로 이동하기 전에 마스터해야 합니다. 스크럼 마스터, 제품 관리자 및 제품 소유자와 같은 기존 스크럼 역할을 활용하고 새로운 역할인 릴리스 트레인 엔지니어도 도입합니다. 이 사람은 서번트 리더 및 ART 코치 역할을 하여 팀이 목표를 조정하도록 안내합니다. ART에는 5~12개의 팀이 있을 수 있으며 각 ART는 완전한 솔루션을 제공할 수 있습니다.

대형 솔루션

이 구성은 Essential SAFe 상단에 있으며 "솔루션 트레인"이라는 개념을 도입합니다. 동일한 가치 흐름에서 작업하는 여러 ART(잠재적으로 수백 또는 수천 명의 사람들)의 조정이 필요한 크고 복잡한 솔루션을 구축할 때 사용됩니다. 예를 들어, Microsoft에서 일하고 Excel, Word 및 PowerPoint를 프로그래밍하는 세 개의 개별 팀이 있는 경우 모두 동일한 가치 흐름인 Microsoft Office에 기여하고 있습니다.

포트폴리오

포트폴리오는 서로 다른 가치 흐름에서 작동하는 여러 ART로 구성됩니다. 계속해서 Microsoft의 예: 회사의 Office, Skype 또는 Xbox 제품에 대해 작업하는 별도의 팀.

완전 안전

이 구성은 모든 계층(Essential, Large Solution 및 Portfolio)을 결합하여 전사적 팀 관리를 조정합니다.

2. 넥서스

Nexus 프레임워크도 Scrum을 기반으로 하지만 SAFe보다 가볍기 때문에 3~9개 팀 간의 협업을 용이하게 하는 약간의 조정만 필요합니다. Nexus를 구현하는 데는 추가 역할이 필요하지 않습니다. 오히려 각 팀의 대표 한 명이 단일 목표를 향해 작업을 조정하는 중앙 통합 팀에 합류합니다. 스크럼과 유사하게 모든 팀은 스프린트 계획 세션을 위해 함께 모이며 그 결과는 공유 제품 백로그를 형성합니다. 진행 상황을 확인하기 위해 각 팀은 스탠드업과 같은 일일 회의를 열고 통합 팀도 만나서 팀의 진행 상황을 보고합니다.

스프린트 동안 팀은 개선 세션에 참여하여 백로그의 우선 순위를 지정하고 추정합니다. 백로그 관리의 복잡성은 팀 수와 함께 증가하기 때문에 Nexus는 개선 세션을 요구합니다. 팀은 각 스프린트 후에 검토 및 회고를 위해 소집됩니다.

3. 대규모 스크럼(LeSS)

LeSS는 Nexus와 거의 동일하지만 명명 규칙 및 추가 팀별 스프린트 계획 세션과 같은 사소한 차이점이 있습니다. 또한 8개 이상의 팀의 협업을 지원하는 두 번째 구성인 LeSS Huge로 확장할 수 있는 능력도 다릅니다.

LeSS Huge는 개발 구성에 대해 고객 중심 접근 방식을 취합니다. 작업을 효과적으로 관리하려면 제품 소유자가 높은 수준의 제품 백로그를 더 세분화된 항목의 더 작은 "영역 백로그"로 분할한 다음 요구 사항 영역으로 더 분류해야 합니다.

이러한 요구 사항 영역은 영역 제품 소유자(APO)가 관리합니다. APO는 각 영역과 관련된 분야를 전문으로 하며 여러 팀과 함께 해당 영역에 대한 솔루션을 제공합니다. 백로그에 저장된 각 요구사항은 하나의 요구사항 영역에만 속하며, 각 영역은 단 하나의 APO에 의해 관리됩니다. 제품 소유자와 APO는 함께 제품 전반에 걸친 관점에서 우선 순위를 정하는 팀을 구성합니다.

4. 스크럼@스케일

Scrum@Scale은 Scrum의 확장이며 아마도 배우고 이해하기 가장 쉬운 프레임워크일 것입니다. 한 팀에서 여러 팀으로 확장됩니다.

프레임워크의 핵심 구성 요소는 스크럼의 스크럼(SoS)입니다. 각 팀은 SoS 회의에서 자신을 대표할 개인을 선택합니다. SoS 회의는 일반적으로 개별 팀의 입장이 끝난 후 매일 진행됩니다. 매일의 SoS 회의의 목표는 팀 간의 조정 및 의사 소통을 돕고 종속성 또는 중복을 쉽게 관리할 수 있도록 하는 것입니다.

이 프레임워크 내에서 고유한 역할에는 본질적으로 스크럼 마스터의 확장 버전인 SoS 마스터와 팀 제품 소유자와 협력하여 SoS에 대한 공동 백로그를 형성하는 수석 제품 소유자가 있습니다.

Scrum@Scale은 다른 프레임워크보다 덜 규범적이므로 조직이 자체 속도로 확장할 수 있습니다. 팀 수가 계속 증가하고 SoS 회의가 너무 많아지면 조직은 프레임워크를 스크럼 스크럼(SoSoS)으로 확대할 수 있습니다.

5. 절제된 애자일(DA)

DA는 준수해야 하는 규칙이 있는 엄격한 프레임워크보다는 가장 적절한 확장 전략을 선택할 수 있는 도구 상자 역할을 한다는 점에서 다른 프레임워크와 다릅니다. 'Choice is good'이라는 원칙을 중심으로 각 프로젝트의 요구 사항에 맞게 조정할 수 있는 Scrum, Kanban 등 다양한 프레임워크의 컨텍스트 기반 하이브리드입니다. DA는 모든 팀과 조직이 규모, 분포 및 영역에서 고유하며 각 팀 구성원도 고유한 기술과 경험을 갖고 있다는 아이디어를 기반으로 합니다.

소프트웨어 개발 팀 수준 또는 전사적으로 적용할 수 있습니다. 후자의 경우 DA 툴킷은 재무, IT 운영 및 공급업체 관리와 같은 다양한 비즈니스 기능이 해결해야 하는 사항을 식별하고 이를 위한 다양한 옵션을 제시합니다.

DA는 시작, 건설 및 전환의 세 가지 프로젝트 단계를 구분하며 각 단계는 전달 지향적인 프로세스 목표로 구성됩니다. 이 프레임워크는 빌드가 아닌 전체 제공 수명 주기에 초점을 맞추기 때문에 다른 프레임워크보다 더 많은 역할을 도입합니다. 모든 DA 팀에서 볼 수 있는 주요 역할은 이해 관계자, 팀 구성원, 팀 리더, 제품 소유자 및 아키텍처 소유자입니다. 또한 확장을 지원하기 위해 일시적으로 사용되는 전문가, 도메인 전문가, 기술 전문가, 독립 테스터 및 통합자의 5가지 지원 역할도 있습니다.

DA는 다른 프레임워크 위에 추가로 사용하여 확장할 수 있습니다.

신중하게 선택하고 천천히 확장

Agile 팀을 확장하고 작업을 원활하게 통합하는 것은 어렵지만 최상의 프레임워크를 선택하면 더 쉽게 만들 수 있습니다. 의사 결정 과정을 안내하는 첫 번째 단계로 아래 순서도를 사용하십시오.

여기에 제시된 것 중에서 조직의 경험, 접근 방식, 예산 및 제품에 적합한 확장 프레임워크를 찾을 수 있을 것이라고 확신합니다. 어떤 프레임워크를 선택하든 서두르지 않는 것이 중요합니다. 중단을 최소화하고 사전에 변경을 계획하기 위해 점진적으로 확장하십시오.

확장 활동에서 이러한 프레임워크를 활용한 적이 있습니까? 의견 섹션에서 귀하의 경험에 대해 알려주십시오.