프로젝트 관리 청사진 2부: Waterfall, DAD, SAFe, LeSS 및 Scrum@Scale의 포괄적인 비교

개요

프로젝트 관리 청사진의 1부에서 우리는 린 소프트웨어 개발, 애자일, 스크럼 및 칸반 소프트웨어 개발 방법론과 이들이 모두 린 제조로 그 뿌리를 추적하는 방법을 다루었습니다. 이러한 방법론은 일반적으로 단일 팀 수준에서 배포됩니다. 그러나 프로젝트와 프로젝트 팀이 커지고 규모에 맞게 민첩하게 대응하기 위해 새로운 접근 방식이 필요함에 따라 복잡성이 증가합니다.

2부에서는 먼저 프로젝트 관리자가 기존 회사에서 소프트웨어 개발을 위한 가장 일반적인 프레임워크인 폭포수 방법론을 사용하는 방법에 대해 자세히 알아볼 것입니다. 이와 함께 DAD(Disciplined Agile Delivery), SAFe(Scaled Agile Framework), LeSS(Large Scale Scrum) 및 Scrum@Scale과 같은 대규모 애자일 원칙을 통합하려는 가장 인기 있는 프레임워크를 다룹니다.

폭포

폭포수 방법론(SDLC(Software Development Life Cycle Model)이라고도 함)은 소프트웨어 개발이 폭포수처럼 한 단계에서 다음 단계로 계단식으로 진행되는 보다 전통적인 방법론입니다. 단계는 겹치지 않으며 한 단계에서 다음 단계로 이동하기 위한 특정 진입 및 퇴장 기준이 있습니다.

원래 폭포수 모델의 6가지 수명 주기 단계는 다음과 같습니다.

1. 요구 사항: 이 단계에서는 일반적으로 비즈니스 분석가가 프로젝트의 기대치와 목표를 정의하고 요구 사항을 광범위하게 분석 및 문서화합니다. 이 단계를 종료하기 전에 요구 사항을 검토하고 승인합니다.
2. 설계: 요구 사항이 승인된 후 승인된 요구 사항을 충족하도록 제품을 설계하고 설계하는 작업이 시작됩니다. 물리적 아키텍처, 구성 요소 아키텍처, 데이터베이스 설계, 세부 구성 요소, 모듈 설계 및 기타 설계 측면은 소프트웨어 설계자 또는 설계자가 문서화합니다. 그런 다음 구현을 시작하기 전에 검토 및 승인됩니다.
3. 구현: 설계가 승인된 후 요구 사항 및 설계에 따라 소프트웨어의 구현 또는 코딩이 소프트웨어 개발자에 의해 수행됩니다.
4. 검증: 구현이 완료된 후 테스트 또는 QA 팀에서 소프트웨어를 테스트하여 요구 사항과 디자인이 충족되고 원하는 품질 수준이 달성되었는지 확인합니다. 결함이 발견되고 기록되고 분류되며 많은 경우에 수정됩니다.
5. 출시 및 유지보수: 테스트 및 디버깅이 완료된 후 제품을 클라이언트에 출시하여 설치합니다. 종종 설치가 성공적인지 확인하기 위해 테스트 라운드가 발생합니다. 제품이 배송된 후 제품이 설계된 대로 계속 작동할 수 있도록 지속적인 유지 관리 및 지원이 이루어집니다.

폭포의 장점

폭포수에는 몇 가지 장점이 있으며 특정 유형의 프로젝트에 적합하지만 몇 가지 심각한 단점도 있습니다. Waterfall은 요구 사항, 기술이 잘 이해되고 크게 변경되지 않는 짧은 프로젝트에 가장 적합합니다.

올바른 유형의 프로젝트에 적용하면 폭포수 모델의 장점 중 일부는 다음과 같습니다.

• 단순성: Waterfall은 범위를 미리 식별하고 경직된 단계와 한 단계에서 다음 단계로의 명확한 전환으로 인해 구현하기 쉽습니다.
• 가시성: 작업의 전체 범위를 미리 알고 프로젝트가 한 단계에서 다음 단계로 전환됨에 따라 이해 관계자가 진행 상황을 보다 쉽게 ​​측정하고 볼 수 있습니다.
• 문서화: 범위, 요구 사항 및 계획을 철저하게 고려하고 문서화할 수 있으므로 경험이 부족한 팀이 프로젝트에서 더 쉽게 작업할 수 있습니다.
• 단계별 작업: 엄격한 역할과 단계 간 전환으로 인해 프로젝트 리소스는 기본 단계가 진행되지 않을 때 다른 프로젝트에서 작업할 수 있습니다.

폭포의 단점

Waterfall은 요구 사항이 잘 이해되지 않거나 변경될 가능성이 있거나 상당한 기술적 위험이 있는 장기 프로젝트에는 적합하지 않습니다. 시장 상황이 끊임없이 변화하고 출시 시간이 중요한 오늘날의 시대에 이것은 대부분의 소프트웨어 프로젝트에 적용됩니다.

주로 변화에 적응할 수 없다는 점을 중심으로 하는 폭포수 모델의 단점은 다음과 같습니다.

• 모놀리식 범위: 이해 관계자가 프로젝트 범위를 정의할 때 모든 것을 생각하도록 보상하여 모놀리식 범위로 이어집니다.
• 늦은 클라이언트 피드백: 이해 관계자와 특히 클라이언트는 프로젝트의 전체 세부 범위를 상상하기 어렵습니다. 폭포수는 대부분 프로젝트의 마지막 단계에서 프로젝트 결과에 클라이언트를 노출 시키므로 불가피하게 클라이언트 피드백을 프로젝트에 통합하기 어려워집니다.
• 요구 사항 변경: 장기 프로젝트에서는 시장 조건, 따라서 프로젝트 목표 및 요구 사항이 프로젝트 중에 변경될 위험이 매우 높습니다.
• 마지막에 생성된 가치: Waterfall은 많은 선행 작업이 필요합니다. 즉, 프로젝트 후반까지 가치가 생성되지 않습니다.
• 단계 상호 의존성: 변경 사항을 통합하면 종종 프로젝트의 다른 영역에 영향을 미칠 수 있는 요구 사항 및/또는 설계 재작업이 발생합니다. 초기 단계에 대한 후기 단계의 종속성은 프로젝트의 작은 변경을 과도하게 어렵게 만들 수 있습니다.

훈련된 애자일 전달(DAD)

Disciplined Agile Delivery(DAD)는 IBM과 Mark Lines의 Scott Ambler에 의해 공식화되었으며 조직의 비애자일 부분이 일반적으로 소프트웨어 프로젝트를 제공하는 데 어느 정도 관련되어 있음을 인식하여 애자일 및 스크럼 프레임워크를 확장합니다. 이 프레임워크에는 IT 운영, 엔터프라이즈 아키텍처, 포트폴리오 관리, 재무 및 조달에서 전체 제공 라이프사이클까지의 활동이 명시적으로 포함됩니다. DAD는 실용적인 방식으로 전반적인 비즈니스 민첩성을 높이는 것을 목표로 합니다.

주요 원리 및 구성 요소

역할

DAD는 스크럼보다 훨씬 더 많은 역할을 하며 두 가지 범주의 팀 역할로 나뉩니다. 기본 역할은 지속적으로 프로젝트와 함께 일하는 사람들로 채워집니다. 보조 역할은 일반적으로 팀 확장 또는 기타 문제를 돕기 위해 일시적으로 도입됩니다. DAD는 전체 솔루션 제공 수명 주기를 다루고 현실 세계에서 발견되는 다양한 유형의 필요한 임시 및 지원 역할을 인식하기 때문에 이러한 추가 역할이 있습니다.

기본 역할:

1. 이해 관계자: 프로젝트를 완료하는 팀에 의존하는 사람: 클라이언트, 최종 사용자 또는 내부 동료.
2. 팀 구성원: 실제로 계획된 작업을 수행하는 팀 내 사람들: 개발자, 디자이너, 테스터 등
3. 팀 리더: 스크럼 마스터와 유사하게 팀 리더는 장애를 제거하고 팀 결속을 촉진하며 민첩한 가치를 전파함으로써 팀의 서번트 리더 역할을 합니다.
4. 제품 소유자: 때때로 "고객의 소리"라고도 합니다. 제품 소유자는 이해 관계자를 대표하고 수행해야 할 작업의 우선 순위 목록을 유지 관리합니다.
5. 아키텍처 소유자: 대규모 아키텍처 위험을 완화할 책임이 있습니다. 이 역할은 일반적으로 깊은 기술 배경과 탄탄한 비즈니스 도메인 지식이 필요하기 때문에 팀 내의 선임 개발자가 담당합니다.

보조 역할:

1. 전문가: 팀에 일시적으로 합류하여 전문적인 역할을 돕는 사람들. 예를 들어, 데이터 분석가는 프로젝트의 초기 단계에서 연구 기능을 제공하기 위해 합류할 수 있습니다.
2. 도메인 전문가: 세무 컨설턴트, 법률 고문 및 도메인 전문 지식을 갖고 관련 문제에 대해 팀을 돕는 기타 사람들입니다.
3. 기술 전문가: 데이터베이스 관리자, 보안 전문가 빌드 마스터 등. 이 사람들은 수명 주기의 주요 지점에서 보다 일반화된 팀 구성원을 돕습니다.
4. 독립 테스터: 테스터는 일반적으로 주요 팀의 일부이지만 일부 경우 수명 규정 요구 사항 또는 매우 복잡한 시스템의 경우 독립 테스터가 병렬로 작업하여 전달 작업을 검증합니다.
5. 통합자: 규모에 따라 서로 다른 팀이 전체 시스템의 서로 다른 부분에서 작업하고 있습니다. 통합자는 팀이 자신의 부분을 전체 시스템과 통합하고 종속성을 관리하는 데 도움이 됩니다.

수명 주기 지원

DAD는 애자일/스크럼에서 다루는 프로그래밍 및 릴리스 부분뿐만 아니라 프로젝트 비전이 정의 및 승인되는 시작 단계와 릴리스 후 지원 및 폐기 단계를 포함하여 전체 제공 라이프사이클을 촉진합니다. 현재 DAD는 6가지 수명 주기를 지원합니다.

• 애자일 라이프사이클: 스크럼 기반 프로젝트 라이프사이클
• 린 라이프사이클: Kanban 기반 프로젝트 라이프사이클
• 지속적 제공: 애자일 라이프사이클
• 지속적 제공: 린 라이프사이클
• 탐색적(린 스타트업) 수명 주기
• 팀 팀을 위한 프로그램 수명 주기

이러한 수명 주기는 다양한 작업 스타일, 회사 민첩성 수준 및 팀이 처할 수 있는 기타 상황을 설명합니다. 요점은 이러한 수명 주기가 제안 역할을 한다는 것입니다. DAD는 모든 상황이 고유하고 훈련된 애자일 실무자는 필요에 따라 애자일 프로세스를 채택해야 하기 때문에 순수주의보다 실용주의를 장려합니다.

프로세스 목표

DAD는 목표 중심 접근 방식을 사용하여 민첩한 프로세스를 만들고 적용합니다. 이 방법론의 저자는 대부분의 팀이 수명 주기 동안 직면하게 될 21가지 가장 중요하고 일반적인 프로세스를 설명합니다.

이러한 모든 프로세스에는 팀이 해당 프로세스를 구성하는 방법을 결정해야 하는 문서화된 결정 사항이 있습니다. 각 결정 지점은 결정을 구현하는 데 사용할 수 있는 제안된 기술 또는 관행을 제공합니다. 아래 이미지에서 이에 대한 예를 볼 수 있습니다. "공통 비전 개발" 프로세스에는 6가지 결정 사항이 있습니다. 이러한 각 결정에는 2~5개의 제안된 사례가 있습니다. 화살표는 DAD 작성자가 이 목록에서 맨 위 항목이 가장 좋은 방법이고 맨 아래 항목이 가장 나쁜 방법으로 목록을 정렬했음을 나타냅니다. _ 굵게 표시된 기울임꼴_ 텍스트는 DAD를 이제 막 시작하는 새 팀을 위한 좋은 출발점을 나타냅니다.

DAD의 확장

Disciplined Agile Delivery는 두 가지 다른 각도에서 확장에 접근합니다.

• 규모에 따른 전술적 민첩성

• 규모에 따른 전략적 민첩성

전술적 민첩성은 프로세스 목표 및 제안된 사례를 상황에 따라 적용하여 규모, 지리적 분포, 프로젝트 복잡성 등과 같은 개별 팀 확장 요인을 해결하려고 합니다.

전략적 민첩성은 조직의 다른 영역을 다루기 위해 프레임워크를 확장함으로써 조직 전체에 걸쳐 애자일 및 린 전략의 적용을 통해 확장을 해결하려고 합니다.

• 전문적인 DevOps: DevOps를 사용하여 조직에 보다 효과적인 결과를 제공하는 방법을 다룹니다.

• Disciplined Agile IT(DAIT): IT의 모든 측면에 애자일 및 린 전략을 적용하는 방법을 다룹니다.

• 절제된 민첩한 기업:. 기업 전체에 린 앤 애자일을 적용하는 방법을 다룹니다.

안전한

SAFe(Scaled Agile Framework)는 현재 가장 복잡하고 포괄적인 확장된 Agile 프레임워크일 뿐만 아니라 가장 대중적입니다. 애자일 현황 보고서의 응답자 중 29%는 조직에서 이 프레임워크를 사용한다고 주장합니다. 차례로 시장에는 많은 SAFe 프로젝트 관리자가 있습니다.

SAFe의 시작은 2007년에 출판된 Dean Leffingwell의 저서 "Scaling Software Agility: Best Practices for Large Enterprises"였습니다. Leffingwell은 현재 SAFe의 수석 방법론자이지만 다른 많은 사람들도 이 프레임워크에 기여하고 있습니다. 현재 버전 4.6에서 이 프레임워크는 버전 관리, 이전 버전과의 호환성 및 다양한 구성 요소가 있는 소프트웨어 제품과 유사합니다.

주요 원리 및 구성 요소

SAFe의 주요 목표는 다양한 유형의 회사가 부분적으로 가장 짧고 지속 가능한 기간에 지속적으로 가치를 제공해야 하는 소프트웨어 회사임을 인식함으로써 린 엔터프라이즈의 생성 및 성장을 촉진하는 것입니다.

SAFe for Lean Enterprises는 입증된 원칙, 역량 및 모범 사례에 대한 지식 기반을 제공하여 Lean Enterprise를 만들기 위해 노력합니다.

SAFe 4.6은 린 기업의 5가지 핵심 역량을 정의합니다. 각 역량은 관련 지식, 기술 및 행동의 집합이며, 이를 통해 조직이 다음과 같이 탁월해질 수 있습니다.

1. 린-애자일 리더십 : 리더가 SAFe의 린-애자일 사고방식을 배우고, 가르치고, 구현함으로써 조직의 변화를 주도하고 유지하는 방법을 설명합니다.

2. 팀 및 기술적 민첩성 : 고성능 Agile 팀을 만드는 데 필요한 기술, 원칙 및 관행을 설명합니다.

3. DevOps 및 릴리스 온 디맨드 : DevOps 및 지속적 제공 파이프라인을 구현하여 수요를 충족하는 데 필요한 언제든지 제품 증분을 릴리스할 수 있는 기능을 조직에 제공하는 방법을 설명합니다.

4. 비즈니스 솔루션 및 린 시스템 엔지니어링 : 크고 복잡한 소프트웨어 애플리케이션의 사양, 개발, 배포 및 진화에 린 애자일 원칙과 사례를 적용하는 방법을 설명합니다.

5. 린 포트폴리오 관리 : 전략 및 투자 자금 조달, 애자일 포트폴리오 운영, 거버넌스에 린 및 시스템 사고 방식을 적용하여 전략과 실행을 조정합니다.

각 핵심 역량은 전체 프로세스를 포괄하는 Lean-Agile Leadership을 제외하고 SAFe 프로세스 다이어그램의 해당 수준에 직접 매핑됩니다.

린애자일 리더십 역량

린-애자일 리더십 역량의 주요 목표는 조직을 린-애자일 기업으로 전환하는 데 도움이 되는 것입니다. 이것은 SAFe의 Lean-Agile 사고 방식, 가치, 원칙 및 관행을 배우고, 실천하고, 가르치는 것으로 이루어집니다.

SAFe의 핵심 가치는 린 기업으로의 전환을 안내합니다. 기회가 있을 때마다 리더의 행동은 리더를 승진시키는 데 중요한 역할을 합니다. 핵심 가치는 다음과 같습니다.

1. Alignment : 미션, 포트폴리오 전략, 솔루션 비전을 전달합니다. 관련 브리핑을 수행하고 프로그램 증분(PI) 계획 및 백로그 유지 관리에 참여합니다.

2. 투명성 : 모든 관련 작업을 시각화합니다.

3. 기본 제공 품질 : 수명 주기 전반에 걸쳐 품질을 제공하기 위한 관행에 참여합니다. 저품질 작업을 거부합니다. 유지 관리에 대한 투자를 지원하고 기술 부채를 줄입니다.

4. 프로그램 실행 : PI 실행에 사업자로 참여하여 비즈니스 가치를 구축합니다. 범위가 수요 및 용량과 일치하는지 확인합니다. 방해 요소와 동기 부여 요소를 적극적으로 제거하십시오.

SAFe 핵심 가치는 Lean-Agile Mindset을 수용하고 SAFe 원칙을 적용하여 지원됩니다.

1. 경제적인 시각을 가져라

2. 시스템 사고 적용

3. 변동성을 가정합니다. 보존 옵션

4. 빠르고 통합된 학습 주기로 점진적으로 구축

5. 작업 시스템의 객관적인 평가에 대한 기본 이정표

6. WIP 시각화 및 제한, 배치 크기 축소, 대기열 길이 관리

7. 케이던스 적용, 도메인 간 계획과 동기화

8. 지식 근로자의 내재적 동기 부여

9. 의사 결정을 분산화

이러한 원칙은 린 및 애자일 원칙과 유사합니다. 마지막으로 SAFe 구현 로드맵에 따라 조직을 혁신할 수 있습니다.

팀 및 기술적 민첩성 역량/팀 수준

팀 및 기술 민첩성 역량은 고품질 솔루션을 생성하는 고성능 애자일 팀을 생성하는 데 필요한 기술, 원칙 및 관행을 설명합니다. 두 가지 주요 특성이 중요합니다.

• 팀 민첩성 : 팀은 안정적인 케이던스에 따라 일하고, 배우고, 적응할 수 있도록 애자일 방식과 원칙을 채택합니다.

• 기술적 민첩성 : 팀은 코드 및 구성 요소 품질, 생성한 코드의 유지 관리 가능성을 보장하는 민첩한 기술 관행을 적용합니다. 품질은 팀 및 기술적 민첩성 역량에서 큰 초점입니다. 이를 달성하기 위해 행동 주도 개발(BDD) 및 테스트 주도 개발(TDD)과 같은 애자일 엔지니어링 기술을 적용하여 품질과 흐름을 높입니다. 오류가 흐름에 심각한 영향을 미치고 릴리스가 지연될 수 있으므로 빠른 흐름은 시스템 전체의 건물 품질에 따라 달라집니다.

SAFe 다이어그램의 팀 레벨은 개별 애자일 팀이 어떻게 운영되는지 설명합니다. 모든 팀은 제품 증분을 제공하기 위해 노력하는 Agile Release Train의 일부입니다. 팀이 작업 시스템을 제공하기 위해 반복적으로 작업하는 기존의 애자일/스크럼 흐름의 대부분이 적용됩니다. 스크럼 마스터, 제품 소유자 및 팀 구성원의 역할은 대부분의 스크럼 활동 및 아티팩트와 마찬가지로 SAFe에서 사용됩니다. 팀은 제품 관리, 시스템 설계자 및 기타 공유 서비스와 같은 프로그램 수준 역할에서도 지원됩니다. Kanban은 전달 수명 주기와 팀 간의 상호 작용 및 전달을 통해 기능의 흐름을 시각화하는 데 사용됩니다.

DevOps 및 Release on Demand 역량/프로그램 수준

DevOps 및 Release on Demand Competency는 "DevOps 및 지속적인 제공 파이프라인을 구현하여 시장 및 고객 요구를 충족하는 데 필요한 언제든지 전체 또는 부분적으로 가치를 공개할 수 있는 능력을 기업에 제공하는" 방법을 설명합니다.

DevOps는 개발, 운영, 비즈니스 및 기타 영역을 조정하여 함께 협력하여 비즈니스 결과를 제공합니다. 모든 조직이 DevOps 운동의 일부 업계 리더만큼 자주 릴리스할 필요는 없지만(Amazon은 몇 초마다 릴리스), 모든 조직은 온디맨드로 릴리스할 수 있어야 합니다.

• DevOps는 지속적 제공 및 온디맨드 릴리스를 가능하게 하는 문화, 자동화, 린 흐름, 측정 및 복구(CALMR) 접근 방식을 제공합니다.

• 애자일 릴리스 트레인(ART)은 지속적인 제공 파이프라인을 통해 주문형 가치를 제공하도록 구성된 애자일 팀의 팀입니다.

다이어그램의 프로그램 수준은 ART(Agile Release Train) 를 통해 지속적으로 제공하는 데 필요한 역할과 활동을 설명합니다. 이 수준은 팀 수준과 유사한 반복 방식으로 작동하지만 여러 애자일 팀을 통합하고 더 많은 주기를 포함합니다. ART는 RTE(Release Train Engineer) 및 제품 관리와 같은 중요한 프로그램 역할뿐만 아니라 기존의 애자일 역할을 포함하여 5-12개 팀(50-125명)으로 구성된 애자일 팀입니다. ART는 PI Planning 을 통해 계획되고 제품 관리자 가 이끄는 8-12주 프로그램 증분(PI) 을 제공합니다.

PI 기능, 에픽 등의 진행 상황은 Program Kanban 보드를 통해 추적 및 관리됩니다. RTE는 ART에서 스크럼 마스터 역할을 합니다. 일일 동기화 회의에는 팀 일일 스탠드업, 스크럼-오브-스크럼(RTE 및 스크럼 마스터), PO 동기화(제품 관리 및 제품 소유자) 및 ART 동기화(스크럼-오브-스크럼 및 PO 동기화 함께)가 포함됩니다. 각 PI에는 시스템 데모와 회고가 있습니다.

비즈니스 솔루션 및 린 시스템 엔지니어링 역량/대형 솔루션 수준

비즈니스 솔루션 및 린 시스템 엔지니어링 역량은 "대규모의 복잡한 소프트웨어 애플리케이션 및 사이버-물리적 시스템의 사양, 개발, 배포 및 진화에 린-애자일 원칙 및 사례를 적용하는 방법"을 설명합니다.

SAFe 원칙 외에도 대규모 솔루션 작업 시 다음 8가지 원칙을 적용하는 것이 이 역량의 핵심입니다.

대규모 솔루션 수준에는 크고 복잡한 솔루션을 구축하는 데 필요한 역할, 아티팩트 및 프로세스가 포함됩니다. 여러 ART가 솔루션을 제공하기 위해 솔루션 트레인 에서 함께 일하고 있습니다. 주요 목표는 다음과 같습니다.

• 빈번한 통합 관리

• 규정 준수 문제를 지속적으로 해결

• 확장성, 모듈성, 릴리스 가능성 및 서비스 용이성을 위한 설계자

솔루션 관리 는 솔루션의 내용을 제어하고 STE(Solution Train Engineer) 는 작업을 안내합니다. Solution Architect 는 솔루션의 모든 ART에 대해 우수한 아키텍처를 유지 관리할 책임이 있습니다. 사전 및 사후 PI 계획 은 여러 프로그램 증분을 통해 제공되는 솔루션을 계획하는 데 사용됩니다. 솔루션 백로그 에는 기능 및 솔루션 에픽 이 포함되며 솔루션 칸반 보드를 통해 추적됩니다.

포트폴리오 수준/린 포트폴리오 관리 역량

린 포트폴리오 관리 역량은 "전략 및 투자 자금 조달, 민첩한 포트폴리오 운영 및 거버넌스에 린 및 시스템 사고 방식을 적용하여 전략과 실행을 조정합니다."

린 포트폴리오 관리는 다음 영역에 중점을 둡니다.

1. 전략 및 투자 자금 조달: 포트폴리오를 기업 전략에 연결하고, 가치 흐름에 자금을 조달하고, 포트폴리오 흐름을 설정합니다.

2. 애자일 포트폴리오 운영: 가치 흐름을 조정하고 프로그램 실행 및 운영 우수성을 지원합니다.

3. 린 거버넌스: 예산 예측, 포트폴리오 성과 측정, 규정 준수 시행

포트폴리오 수준에는 일련의 개발 가치 흐름을 시작하고 관리하는 데 필요한 원칙, 관행 및 역할이 포함됩니다. 포트폴리오 백로그 에는 비즈니스 에픽 과 인 에이블러 에픽 이 포함되며 포트폴리오 칸반* 보드를 통해 추적됩니다. **린 포트폴리오 관리(LPM) 는 포트폴리오에 있는 가치 흐름을 결정하고 기업의 최고 의사 결정권자를 포함합니다. Enterprise Architect 는 가치 흐름 전반에 걸쳐 작업과 조정을 안내합니다.

더 적은

대규모 스크럼(LeSS) 프레임워크는 금융 및 통신 산업에서의 경험을 기반으로 Craig Larman과 Bas Vodde가 만들었습니다. 이름에서 알 수 있듯이 LeSS는 많은 스크럼 팀이 함께 작업할 수 있도록 가능한 한 적은 수의 프로세스와 절차를 사용하도록 권장합니다. 확장은 사람들이 복잡하게 만들기 때문에 어렵기 때문에 여기에서 목표는 가능한 한 간단하게 만드는 것입니다.

주요 원리 및 구성 요소

“LeSS는 하나의 제품에 대해 여러 팀이 함께 작업하는 Scrum입니다.” LeSS는 Lean-Agile 원칙에 익숙한 사람이라면 누구에게나 친숙하게 보일 10가지 원칙을 기반으로 합니다.

1. 대규모 스크럼은 스크럼입니다

2. 경험적 공정 제어

3. 투명도

4. 적은 비용으로 더 많이

5. 전체 제품 초점

6. 고객 중심의

7. 완벽을 향한 끊임없는 개선

8. 시스템 사고

9. 린 생각

10. 큐잉 이론

LeSS는 Scrum에서 차용한 두 가지 주요 역할만 있습니다.

1. 제품 소유자: 2-8개 팀과 함께 작업합니다.
2. 스크럼 마스터: 1-3개 팀과 함께 작업합니다.

모든 팀은 1-4주 스프린트에서 동일한 제품 백로그 로 작업합니다. 팀은 병렬로 작업합니다. 즉, 동시에 스프린트를 시작하고 종료합니다. 스프린트가 끝나면 팀은 집합적으로 제품 증분 을 제공합니다. 한 제품 소유자가 8개 팀과 작업하는 것은 거의 불가능해 보일 수 있습니다. LeSS는 제품 백로그 항목 설명의 책임을 팀으로 옮기는 것을 촉진합니다. 결과적으로 팀은 여러 기능을 수행해야 하며 코딩, 디자인 및 테스트 역량뿐 아니라 비즈니스 도메인 지식도 포함해야 합니다. 더 중요한 것은 팀이 고객에게 다가갈 수 있도록 권한을 부여해야 한다는 것입니다.

스프린트 계획

계획은 두 부분으로 나뉩니다.

1. 스프린트 계획 1: 팀 대표가 제품 소유자와 만나 그들이 맡을 백로그 항목을 결정하고 스프린트 동안 팀 간에 필요할 수 있는 잠재적 협력에 대해 논의합니다.
2. 스프린트 계획 2: 기존 스크럼과 마찬가지로 각 팀은 개별적으로 모여서 백로그 항목을 수행하는 방법에 대한 계획을 만듭니다.

제품 백로그 개선

제품 백로그 개선(PBR)은 스프린트 계획을 위한 제품 백로그 항목을 준비하기 위해 스프린트 중에 수행됩니다. LeSS는 PBR을 수행하는 방법에 대한 규칙을 제공하지 않으며 가장 효과적인 프로세스를 자체적으로 파악하는 회사의 몫입니다. PBR에는 세 가지 주요 활동이 포함됩니다.

1. 큰 항목을 분할합니다.
2. 준비가 될 때까지 항목을 자세히 설명합니다.
3. 추정.

스프린트 종료

각 스프린트가 끝나면 세 가지 일이 발생합니다.

1. Sprint Review: 팀과 고객이 Sprint 동안 수행한 작업과 다음에 수행해야 하는 작업을 탐색하는 공유 Sprint 데모입니다.
2. 회고: 각 팀은 프로세스를 개선하기 위해 자체 회고를 개최합니다.
3. 전반적인 회고: 팀, 제품 소유자 및 스크럼 마스터가 함께 모여 조직 관행을 보다 효과적으로 검사하고 조정합니다.

스크럼@스케일

Scrum at Scale과 Scrum@Scale은 같은 의미로 사용됩니다. 이 방법론은 스크럼 방법론을 창안한 애자일 선언문 서명자 중 한 명인 Jeff Sutherland가 2014년에 도입했습니다.

Scrum@Scale은 스크럼을 출발점으로 삼고 "최소 실행 가능한 관료제"로 스크럼을 확장할 수 있는 간단하고 가벼운 프레임워크를 제공합니다. 다른 확장된 애자일 방법론보다 덜 규범적이며 메타 프레임워크로 간주될 수 있습니다. 확장 문제와 영역을 강조하고 해결 방법에 대한 정신적 프레임워크를 제공합니다.

주요 원리 및 구성 요소

Scrum@Scale은 Scrum을 확장하기 위해 Scrum을 사용하여 확장을 근본적으로 단순화하는 프레임워크입니다. 스크럼에서 "무엇"(제품 소유자)은 "어떻게"(스크럼 마스터)와 명확하게 구분됩니다. 동일한 전략이 Scrum@Scale에서 사용되어 관할권과 책임이 잘 이해되어 낭비와 갈등을 제거합니다.

Scrum@Scale에는 관할 구역을 명확하게 구분하는 두 가지 주기가 있습니다. 스크럼 마스터 주기 와 두 개의 접점이 있는 제품 소유자 주기 , 즉 팀 수준 프로세스와 제품 릴리스 피드백입니다.

스크럼 마스터 사이클

스크럼 마스터 주기 는 제품 소유자 주기가 식별한 항목이 구축되는 방식을 담당합니다. Scrum@Scale에서 개별 스크럼 팀은 기존 스크럼과 동일한 역할, 유물, 활동 및 의식을 갖습니다.

스크럼 팀은 스크럼의 스크럼(SoS) 으로 그룹화되어 공동 제품 증분을 생성하는 공동 책임이 있습니다. 그들은 공동 백로그 정리 및 우선순위 지정에 참여하고, 회고를 개최하고, 장애 백로그를 유지하고, 팀을 조정하고 장애물을 제거하기 위해 SDS(스케일드 데일리 스크럼) (일일 스크럼과 형식이 유사)를 개최합니다. SDS에는 참여하는 각 팀의 최소 한 명(보통 팀의 스크럼 마스터)이 참석하고 스크럼 팀 및 제품 소유자와의 조정을 담당 하는 스크럼 마스터(SoSM) 가 주도합니다.

추가 확장이 필요한 경우 매일 만나기도 하는 여러 SoS에서 생성된 스크럼 스크럼(SoSoS) 이 있습니다. 전체 리더는 조직에서 애자일을 홍보하고 필요에 따라 스크럼 팀을 조정하며 장애를 제거하기 위한 최종 중지 역할을 담당하는 EAT(Executive Action Team) 입니다.

제품 소유자 주기

제품 소유자 주기 는 생성될 제품 또는 서비스와 이를 지원하는 데 필요한 모든 활동에 대한 책임이 있습니다. 제품 소유자는 스크럼 팀에 할당되고 스크럼에 정의된 역할의 모든 활동을 수행합니다. 제품 소유자는 SoS 팀에 매핑되는 제품 소유자 팀 으로 그룹화됩니다. 제품 소유자 팀은 매일 메타 스크럼 에서 만나 팀을 위한 높은 수준의 전략을 논의하고 해당 SoSM 및 기타 제품 소유자 및 이해 관계자와 필요에 따라 조정합니다. 메타 스크럼은 최고 제품 소유자(CPO) 가 주도합니다.

제품 소유자는 조직의 규모에 따라 스크럼 마스터 주기와 유사한 방식으로 확장되며 회사 전체의 우선 순위 설정을 담당하는 EMT(Executive Meta Scrum) 에서 절정에 이릅니다.

Scrum@Scale 구현

Scrum@Scale의 구현은 확장 가능한 참조 모델, 즉 소규모에서 스크럼을 사용하는 소규모 팀 집합을 만드는 것으로 시작됩니다. 이는 애자일을 방해하는 조직 정책 및 개발 관행을 해결하기 위해 수행됩니다. Scrum@Scale은 모든 팀이 이러한 조직의 광범위한 문제에 직면할 가능성이 있고 그에 따른 좌절이 애자일 채택을 방해할 수 있기 때문에 이러한 문제를 조기에 해결할 것을 제안합니다. 그런 다음 참조 모델은 스크럼을 다른 팀 및 부서로 확장하기 위한 패턴으로 사용됩니다.

참조 모델을 구현하려면 처음에 EAT(Executive Action Team)를 만들어야 합니다. EAT는 조직 정책 변경을 구현할 수 있으므로 조직 내에서 정치적, 재정적으로 권한을 부여받은 개인으로 구성됩니다.

결론

프로젝트 관리 청사진의 두 번째 부분에서는 대규모 프로젝트 또는 프로그램에서 사용되는 가장 인기 있는 프레임워크 중 일부를 다루었습니다. Waterfall은 여전히 ​​많은 조직에서 널리 사용되며 유연하지 않은 프로세스로 인해 많은 단점이 있지만 프로젝트가 작고 범위가 잘 정의되어 변경될 가능성이 없는 경우 이 프레임워크를 사용하는 것이 합리적입니다.

기업은 요구 사항이나 목표가 끊임없이 변화하는 더 크고 복잡한 프로젝트에 직면함에 따라 더 많은 애자일 접근 방식을 찾습니다. Agile은 원래 5-9명으로 구성된 소규모 팀을 위한 것이었기 때문에 다양한 Agile 실무자는 단일 팀에서 여러 팀으로, 전체 기업으로 Agile을 확장하는 여러 가지 방법을 사용했습니다. 이 기사에서는 Disciplined Agile Delivery(DAD), Scaled Agile Framework(SAFe), Large Scale Scrum(LeSS) 및 Scrum@Scale에 대해 설명했습니다.

프로젝트 관리 청사진의 마지막 부분에서는 PMP(PMBOK) 및 PRINCE2와 같은 몇 가지 프로젝트 관리 특정 프레임워크를 다룹니다. 우리는 또한 "해야 할 일"(JTBD) 및 "디자인 사고"와 같은 일부 혁신 프로세스 및 프레임워크에 대해 살펴볼 것입니다.