애자일 프로그램 관리란 무엇인가요?

애자일 프로그램 관리는 유연성, 협업, 반복적인 개발, 고객 피드백 우선순위 지정 및 지속적인 개선과 같은 애자일 원칙에 의존하는 여러 관련 프로젝트(프로그램)를 관리하는 접근 방식입니다.

애자일은 특정 방법론이라기보다는 일련의 원칙을 가진 철학입니다. 하지만 스크럼(Scrum), 익스트림 프로그래밍(XP), 칸반(Kanban) 등 애자일 프로그램 관리에 자주 포함되는 잘 확립된 애자일 방법론들도 있습니다. 애자일 프로그램 관리는 처음에 소프트웨어 산업을 위해 설계되어 고객에게 더 빠르게 더 큰 가치를 제공하는 데 목적을 두었으나, 이제는 그 범위를 훨씬 넘어 다양한 산업 분야에 적용되고 있습니다.

애자일 프로그램 관리는 일반적으로 여러 관련 프로젝트를 포함합니다. 개별 프로젝트는 애자일 프레임워크로 관리할 수 있지만, 애자일 프로그램 관리는 전체 라이프사이클 동안 여러 프로젝트를 하나의 통합된 체계로 통합합니다. 한 단계 더 높은 수준에서는 여러 프로그램과 그에 속한 프로젝트들이 보다 광범위한 포트폴리오 관리 전략 아래 조직될 수 있습니다.

애자일 프로젝트 관리는 특정 프로젝트에 집중하며, 해당 프로젝트와 관련된 목표, 일정, 자원, 팀 관리를 포함합니다. 애자일 프로그램 관리는 관련 프로젝트 그룹과 이들을 더 넓은 조직 목표 아래 통합하는 전략을 감독합니다. 이 두 분야는 많은 기능을 공유하지만 범위에 차이가 있으며, 애자일 프로그램 관리자는 프로그램 전략, 위험 관리, 이해관계자 소통 등에서 더 넓은 역할을 담당합니다.

간단히 말해, 프로젝트 관리는 개별 프로젝트의 전술적이고 시기적절한 실행에 더 중점을 둡니다. 반면 프로그램 관리는 프로그램 내 개별 프로젝트들의 전반적인 성공을 조율하기 위해 보다 전략적인 접근 방식을 취합니다.

프로젝트 관리라는 분야는 1950년대 미국에서 본격적으로 형성되기 시작했습니다. 1990년대에 ‘워터폴’로 알려진 일련의 방법론이 공식화되었으며, 이 방식에서는 프로젝트의 각 단계를 전체 팀이 다음 단계로 넘어가기 전에 반드시 완료해야 합니다. 그러나 소프트웨어가 점점 더 중요해지고 복잡해짐에 따라, 전통적인 프로젝트 관리 및 워터폴 방법론은 빠르게 진행되고 빈번한 변화를 겪는 프로젝트에는 번거롭고 이상적이지 않은 것으로 드러났습니다.

2001년, 한 소프트웨어 개발자 그룹은 4가지 핵심 가치와 12가지 원칙을 담은 애자일 프로젝트 관리를 위한 애자일 선언문을 만들었습니다. 주요 가치는 다음과 같습니다.

• 개인과 상호 작용을 프로세스와 툴보다 중시
  
  
• 작동하는 소프트웨어를 포괄적인 문서보다 중시
  
  
• 고객 협업을 계약 협상보다 중시
  
  
• 계획을 따르는 것보다 변화에 대응하는 것을 중시

선호하는 가치는 그렇지 않은 가치를 포기할 것을 요구하지 않습니다. 예를 들어, 애자일 철학은 계획의 사용을 금지하지 않지만 대신 불가피한 변화에 대응하고 준비하는 데 더 큰 비중을 둡니다.

이러한 애자일 원칙은 소프트웨어 개발 프로세스에서 점점 인기를 얻고 있지만, 그 철학은 애자일 소프트웨어 개발을 훨씬 뛰어넘습니다. 애자일 원칙은 이제 패션에서 생명공학, 정부에 이르기까지 다양한 산업 분야에서 사용되고 있습니다.

애자일 접근 방식이 워터폴과 같은 이전 방법과 다른 점은 애자일 방법이 처음부터 반복적이고 협력적이며 유연하게 설계되었다는 것입니다. 애자일 프로그램 관리 시스템에서는 팀 또는 고객의 응답에 따라 프로젝트가 신속하게 생성되고 정기적으로 검토, 논의, 변경됩니다. 처음부터 계획과 접근 방식이 바뀌어야 하며, 초기 계획을 고집하지 않는다고 가정합니다. 개별 팀원들은 다른 접근 방식처럼 확고한 위계질서 없이 자신의 의견을 말할 수 있는 권한을 갖습니다.

애자일 프로그램 관리는 구체적인 방법론이 아니라 철학이기 때문에 애자일 관행의 세부 사항은 조직마다 또는 프로그램마다 크게 다를 수 있습니다. 하지만 애자일 프로그램 관리에서 흔히 볼 수 있는 몇 가지 측면이 있습니다.

애자일 프로그램 관리에는 여러 개별 프로젝트가 포함됩니다. 전체 프로젝트와 각 개별 프로젝트는 모두 애자일 프레임워크 내에서 구성될 수 있습니다. 애자일 프로그램 관리는 여러 프로젝트를 전체적으로 조망하는 포괄적인 시각을 포함합니다. 여기에는 종종 예산 책정, 전체 전략 및 장기 분석과 같은 개별 프로젝트 관리에 존재하지 않는 요소가 포함됩니다.

변화에 신속하게 대응하는 것은 애자일 철학의 핵심 원칙입니다. 따라서 애자일 프로그램 관리는 변화를 진로를 조정하고 고객에게 가치를 제공하는 즉각적인 개선의 기회로써 수용합니다. 달성을 위해 프로젝트를 더 작은 단위로 나누면 조직이 더 유연하고 더 빠르게 전환할 수 있습니다

애자일 프로그램 관리의 핵심은 반복적인 접근 방식에 있습니다. 프로그램 내의 개별 프로젝트는 여러 버전을 거치며, 제품 개발팀은 매번 결과에 대해 논의하고 개선합니다. 전체 프로젝트든 단일 요소든, 작동하는 아웃풋을 지속적으로 제공하는 것이 매우 중요합니다. 또한 고객 피드백, KPI 및 변화하는 요구 사항을 기반으로 반복할 때마다 제품을 개선하는 것도 중요합니다.

애자일은 장황한 이메일이나 기타 문자 기반 소통보다 대면 대화를 더 중요하게 여깁니다. 이메일 스레드는 시간 제약이나 누락된 이메일 때문에 몇 시간, 며칠, 심지어 몇 주가 걸릴 수 있지만, 대면 소통은 같은 작업을 몇 분 만에 완료할 수 있습니다.

애자일 프로그램 관리는 프로그램에 대한 전반적인 관점으로서 효율성에 초점을 맞추고 불필요하거나 번거로운 요소를 제거해야 합니다. 문서는 목적을 위한 수단이지 목적 그 자체가 아니며 필요한 것만 포함해야 합니다.

정직과 개방성은 성공적인 애자일 프로그램의 핵심입니다. 대화를 통해 모든 팀원이 목소리를 높일 수 있어야 합니다. 이러한 관리 접근 방식에서는 모든 사람의 목소리가 유효하고 경청됩니다.

동시에, 실행 불가능한 아이디어를 걸러내면서도 해당 아이디어의 창시자가 향후 발언을 꺼리지 않도록 하는 것도 허용되어야 합니다. '회고'(또는 피드백이 수집되는 프로젝트 후 평가인 '복고')의 성공 여부는 팀의 투명성에도 달려 있습니다.

애자일 프로그램 관리의 철학은 어떤 특정 프레임워크를 사용할 것을 요구하지 않습니다. 하지만 스크럼과 칸반을 비롯한 많은 프로젝트 관리 프레임워크는 애자일 철학과 긴밀하게 연관되어 있습니다. 다음은 가장 인기 있는 몇 가지 프레임워크입니다.

스크럼은 협업 팀 프로젝트 작업을 위한 프레임워크입니다. 이 이름은 약어처럼 보일 수 있지만, 실제로는 럭비 경기에서 선수들이 팔을 맞잡고 함께 상대를 밀어내는 ‘스크럼(scrum)’에서 유래했습니다. 말이 없는 일종의 기병 돌격과 같습니다.

애자일에서 스크럼 팀은 세 가지 역할로 구성됩니다.

• 프로젝트 관리자: 스크럼 팀과 이해관계자(사용자, 고객 또는 모회사 등) 간의 연락 역할을 담당합니다. 프로젝트 관리자는 예산, 인력 배치 및 피드백과 같은 외부 요인을 스크럼 팀에 전달하는 동시에 팀의 진행 상황을 이해관계자에게 전달할 책임이 있습니다.
  
  
• 스크럼 마스터: 스크럼 마스터는 전통적인 ‘상사’라기보다는 스크럼 방법론의 교사이자 지휘자 역할을 하며, 가이드 제공, 소통, 문제 해결을 원활하게 지원합니다. 스크럼 마스터는 일반적으로 채용 및 해고에 대한 책임이 없습니다.
  
  
• 개발자 또는 팀 구성원: 이 용어는 예를 들어 스크럼 팀이 소프트웨어 이외의 산업에 속한 경우 달라질 수 있습니다. 이 역할은 개발자, 팀 구성원 또는 직원 중 어떤 이름으로 불리더라도 계층이 존재하지 않습니다. 이상적인 팀의 구성원 규모는 3명에서 9명 사이입니다. 그룹이 클수록 스크럼 마스터가 안내하기가 더 까다로워집니다. 여기에는 경영진의 과도한 계획 없이 팀이 성공하기 위해 필요한 사람과 대상을 개인이 정확히 결정하는 자율 조직화된 팀도 포함될 수 있습니다.

스크럼은 다른 팀 기반 조직 모델과 구별되는 몇 가지 특정 개념을 가지고 있습니다. 제품 백로그는 팀이 스크럼 기간 동안 필요로 할 수 있는 모든 작업, 아이디어, 요구사항, 산출물 및 리소스를 모아둔 저장소입니다. 효율성과 완전성을 보장하기 위해 팀에서 지속적으로 업데이트하고 모니터링할 수 있으며, 실제로 그렇게 해야 합니다.

스크럼에서는 작업이 스프린트로 구분되며, 일반적으로 1~4주 동안 지속됩니다. 스프린트에서 팀원들은 구체적이고 달성 가능한 목표를 달성하기 위해 노력합니다. 그 목표는 작동하는 모델, 목업, 프로토타입, 또는 완성된 제품이나 솔루션의 단일 기능이나 요소일 수도 있습니다.

스프린트 중에 팀 구성원은 하루에 한 번 '일일 스크럼' 또는 '스탠드업'에서 미팅을 가집니다. 이러한 회의는 스크럼의 원칙에 따르면 매우 높은 수준입니다. 15분을 넘지 않는 일일 스크럼에서 팀 구성원은 진행 상황과 작업을 방해하는 장애물을 최대한 간략하게 보고합니다. 때때로 특정 팀 구성원은 일일 스크럼에서 발표된 내용에 대해 추가로 논의하기 위해 스크럼 후 회의에 참여하기도 합니다.

스프린트가 끝나면 팀 구성원, 스크럼 마스터와 프로젝트 관리자를 포함한 전체 팀이 만나 빌드된 내용을 검토하고 논의합니다. 프로젝트 관리자는 사용자 또는 더 큰 조직과 같은 이해관계자의 변경 내용을 전달할 수 있으며, 논의 후에 팀은 이러한 변경 내용을 다음 스프린트에 반영할 수 있습니다.

칸반은 프로젝트를 관리하고 추적하기 위한 시각적 시스템입니다. 칸반 보드는 프로젝트에서 팀의 진행 상황을 시각적으로 표현하며, 개별 하위 작업이 몇 가지 카테고리 중 하나로 분류됩니다. 이러한 카테고리에는 일반적으로 다음이 포함됩니다.

• 백로그: 아직 다른 카테고리로 이동되지 않은 모든 작업입니다. 프로젝트 시작 시에는 모든 작업이 백로그에 포함됩니다.
  
  
• 진행 중: 현재 진행 중인 작업들입니다.
  
  
• 검토 중: 초기 완료 단계에 도달하여 다른 사람이 평가하고 있는 작업들입니다.
  
  
• 완료: 완료된 작업입니다.

“칸반(Kanban)”은 일본어로 ‘표시’라는 뜻의 “간(kan)”과 ‘판’이라는 뜻의 “반(ban)”이 합쳐진 말로, 게시판이나 전광판과 비슷한 의미를 가집니다. 칸반은 아날로그와 디지털 형태로 모두 만들 수 있습니다. 아날로그 방식에서는 개별 작업을 위해 물리적인 포스트잇 노트를 자주 사용하며, 작업이 완료됨에 따라 이 노트들을 열에서 열로 옮겨갑니다.

또한, 칸반 보드의 디지털 버전도 많이 나와 있어 구성원 일부 또는 전원이 원격 근무자인 프로젝트 팀에 특히 유용할 수 있습니다.

익스트림 프로그래밍(XP)은 원래 소프트웨어 엔지니어가 소프트웨어 품질, 응답성 및 속도를 개선할 수 있도록 설계된 애자일 방법론입니다. 기본적인 개념은 애자일의 한 형태로, 테스트 가능한 생성 타임라인의 더 작은 버스트에 의존합니다.

XP(익스트림 프로그래밍)에서는 전체 프로젝트의 각 개별 요소를 반복적으로 테스트하며, 때로는 고의로 오류를 유발하는 테스트도 수행합니다. 그런 다음 이러한 개별적인 측면을 매주 함께 테스트하여 최대한의 호환성을 보장합니다.

커뮤니케이션에서 XP는 극도로 단순성에 의존합니다. 문서는 다른 팀원들이 이해할 수 있도록 최대한 간결한 언어, 개념, 은유를 사용하여 최소한으로 작성합니다. 이러한 단순성은 작업의 실제 설계에도 적용되며, XP 프로젝트는 향후 추가 기능을 고려하지 않고 설계되는 경우가 많으며, 이를 프로젝트 출시와는 별개의 부가 요소로 간주합니다. 이를 YAGNI(You Aren't Gonna Need It)라고도 합니다.

XP가 모든 프로젝트에 적합한 것은 아닙니다. 확장성이나 상당한 재작업이 필요하지 않은 프로젝트에만 XP를 사용하는 것이 중요합니다.

SAFe는 린-애자일 개발 방법, DevOps 및 시스템 사고를 기반으로 하는 일련의 원칙과 관행입니다. Scaled Agile Framework(SAFe)는 이름에서 알 수 있듯이, 대규모 조직 전반에 걸쳐 애자일 프레임워크를 확장하여 여러 프로젝트를 정렬하고, 교차 기능성과 상호 운용성을 보장하도록 설계되었습니다. 이는 주로 PI(계획 증분) 로드맵을 포함하는 구조를 통해 이루어집니다.

이러한 로드맵 내의 작업은 한눈에 파악할 수 있도록 다양한 방식으로 참조됩니다. 식별 항목에는 ‘인에이블러(enablers)’(다른 작업에 대한 의존성), ‘에픽(epics)’(특정 비즈니스 요구를 위해 설계된 대규모 이니셔티브), 그리고 ‘스토리(stories)’(사용자 또는 비즈니스 관점에서 원하는 기능)가 포함됩니다.

체계적인 애자일은 완전한 방법론이라기보다는 일련의 원칙, 약속 및 지침으로 간주됩니다. 이는 프로그램 관리에 대한 최소한의 가벼운 하이브리드 접근 방식으로, 개별 팀 구성원에게 많은 자유를 제공합니다.

스크럼 및 SAFe와 같은 일부 민첩한 프레임워크에는 규범적인 방법론과 단계가 포함되어 있습니다. 이러한 특수성은 특정 프로젝트에 유용할 수 있지만 DA는 팀 구성원에게 더 많은 자유와 민첩성을 제공하는 것을 목표로 합니다. 기본 개념을 통해 개인은 자신의 특정 워크플로에 적합한 개념과 프레임워크를 선택할 수 있습니다. 스크럼은 어떤 팀에게는 잘 맞을 수 있지만, 특히 더 큰 프로그램 관점에서는 그렇지 않을 수도 있습니다. DA는 개인에게 많은 권한을 부여하기 때문에, 이미 기본적인 애자일 개념에 익숙하고 독립적으로 높은 역량을 가진 팀원들이 있는 프로젝트에 가장 적합합니다.

LeSS로 알려진 대규모 스크럼(Large-Scale Scrum)은 일반적인 스크럼이 처리할 수 있는 것보다 더 큰 팀 또는 팀 그룹을 위해 특별히 설계된 버전의 스크럼입니다. LeSS에는 여전히 스프린트, 일일 스크럼 회의 및 후기가 포함되지만, 대규모 팀이 애자일을 확장하여 목표를 달성할 수 있도록 몇 가지 추가 지침이 있습니다.

LeSS에서는 애자일 프로젝트 관리에서처럼 개별 팀이 개별 스프린트를 계획하는 것이 아닌, 모든 팀이 동일한 스프린트에서 작업합니다. 전체 프로그램에 필요한 모든 작업이 포함된 공유 백로그도 있습니다. 스프린트 계획에는 두 가지 유형의 회의, 즉 모든 팀을 위한 전체 계획 회의와 개별 팀을 위한 개별 스프린트 계획 회의가 포함됩니다.

넥서스(Nexus)는 스크럼과 유사한 프레임워크로, 일부 추가 사항과 제거 사항 및 변경 사항이 있습니다. 가장 큰 차이점은 코치 역할을 하는 별도의 팀 구성원 그룹인 넥서스 통합 팀(NIT)이 추가되었다는 것입니다. NIT에는 스크럼 팀의 구성원이 포함되는 경우가 많으며, 막힌 부분을 해결하고, 지원을 제공하고, 애자일 프로세스를 통해 팀을 코칭하는 일을 담당합니다. NIT에는 일일 스크럼과 별도로 자체 회의가 있습니다.

스크럼은 애자일 프로젝트 관리의 특정 프로젝트를 위한 경이로운 개념이지만, 애자일 프로그램 관리에 대해 논의할 때 실제로는 팀 간의 팀에 대해 논의하고 있습니다. 이것이 바로 Scrum@Scale이 필요한 이유입니다.

Scrum@Scale에서는 모든 애자일 팀원이 스크럼 팀의 일부로 간주되어 다양한 분야 간 협업이 가능해집니다. 더 큰 프로그램에서 실시간으로 발생하는 과제를 돕기 위해 몇몇 새로운 팀원이 추가됩니다. 최고 제품 책임자(CPO)는 모든 스크럼을 위한 단일 백로그를 만들고 개별 제품 책임자들과 조율합니다. 비슷한 역할로는 스크럼 마스터의 스크럼(Scrum of Scrum Master)이 있는데, 이 스크럼 마스터는 스크럼 마스터 간의 작업을 조율합니다.

린(Lean)은 비효율성을 줄이고 결과물의 품질을 지속적으로 개선하는 것을 목표로 하는 방법론입니다. 이것은 종종 애자일 우산 아래에 있는 것으로 간주됩니다. 그러나 애자일이 철학이라면, 린(Lean)은 보다 구체적인 도구와 지침이 있는 방법론입니다. 린(Lean)은 비효율성과 낭비를 최소화하는 데 가장 중점을 두는 반면, 애자일은 주로 반복, 피드백 및 유연성에 중점을 둡니다.

린에는 5가지 주요 원칙이 있습니다.

• 가치 식별: 기본적으로 목표가 무엇인지 정확히 파악하고 가치를 더하지 않는 것은 모두 제거합니다.
  
  
• 가치 흐름 매핑: 칸반 보드와 같은 관리 툴을 사용하여 제품 로드맵을 시각화합니다. 기본적으로 프로젝트 계획을 처음부터 끝까지 시각화합니다.
  
  
• 워크플로 생성: 구체적인 과정으로 생산 프로세스를 구축하고 모든 장애물을 찾아보세요. 목표는 가능한 한 유동적인 워크플로를 구축하는 것입니다.
  
  
• 풀 시스템 구축: 풀 시스템은 고객 요구에 따라 팀 구성원이 더 많은 작업을 수행할 준비가 되었을 때만 새로운 작업을 생성하는 방식입니다. 이 작업은 주로 작업 대기열을 사용하여 수행됩니다.
  
  
• 지속적인 개선: 다양한 기술을 사용하여 지속적으로 가치를 창출하고 제품을 개선합니다. 여기에는 린 식스 시그마(Lean Six Sigma) 및 카이젠(Kaizen)과 같은 방법론 및 철학 또는 스크럼(Scrum)과 같은 구조화된 프레임워크가 포함될 수 있으며, 이는 지속적인 테스트와 유익한 피드백 루프를 장려합니다.

애자일 프로그램 관리는 관련 방법론과 함께 프로젝트 납품을 개선할 수 있는 다양한 방법을 제공합니다.

• 구체성: 애자일 팀은 지속적인 반복을 통해 고객이 원하는 바를 정확히 좁혀 나가며, 프로젝트 전체를 무작정 개선하려 하지 않습니다.
  
  
• 효율성: 애자일 프로그램 관리는 낭비, 문서화, 관료주의를 줄이기 위한 원칙들을 포함합니다.
  
  
• 다재다능함: 고객 피드백에 신속하게 대응할 수 있기 때문에 다재다능함은 애자일 프로그램 관리의 기본이 됩니다. 애자일 팀은 프로젝트가 시작되기 전부터 과정 중에 변경이 있을 것을 인지합니다.
  
  
• 팀 사기: 애자일 프로그램 관리는 개방성, 투명성, 그리고 팀원 개개인이 의견을 낼 수 있도록 권한을 부여하는 것을 장려합니다. 위계질서보다는 정직과 헌신적인 팀워크가 더 중요합니다.