모든 애자일 소프트웨어 프로젝트에는 목표(프로젝트가 제공해야 하는 것, 제공 기한 및 할당된 예산)가 있습니다. 그러나 이러한 세 가지 제약 조건을 관리하는 것은 힘든 작업일 수 있습니다. 수십 년된 계획의 철의 삼각관계에서 단서를 얻고 다양한 변수의 균형을 조정하여 애자일 소프트웨어 팀이 애자일 프로젝트 관리 마스터 경지에 이르는 데 어떻게 도움이 되는지 알아보세요.
전통적인 철의 삼각관계
철의 삼각관계 프로젝트 관리에는 제약 조건이 있습니다. 그리고 이러한 제약 조건은 다른 제약 조건에 영향을 주지 않고는 한 제약 조건을 변경할 수 없기 때문에 "철"로 간주됩니다. 1969년 Martin Barnes 박사가 제안한 원래 철의 삼각관계는 제품 개발에 대한 워터폴 접근 방식을 따릅니다. 범위는 고정되어 있고 리소스와 시간은 가변적입니다. 소프트웨어 팀의 경우 팀이 프로젝트 범위(작업 항목의 목록)를 결정하기 위해 제품 요구 사항을 정의하여 프로젝트를 시작한다는 의미입니다. 리소스와 일정은 가변적이며 고정 범위 따라 추정합니다.
- 범위는 작동하는 제품을 제공하기 위해 수행해야 하는 작업(예: 기능 및 작동)입니다.
- 리소스에는 제공 및 실행을 위해 노력하는 팀원과 예산이 포함됩니다.
- 시간은 릴리스 및 마일스톤과 같이 팀이 시장에 제품을 전달하는 시점입니다.
철의 삼각관계 프로젝트 관리의 목적은 제품 팀에 비즈니스에 도움이 될 균형을 만드는 데 필요한 정보를 제공하는 것입니다. 예를 들어 팀이 고정 범위에 직면한 경우 프로젝트의 절반을 완료했으며 릴리스 날짜를 맞출 수 없다는 것을 인식할 수 있습니다. 이때, 팀에서 다룰 수 있는 유일한 변수는 1) 시간(더 늦은 출시 날짜를 수락할 수 있음) 또는 2) 리소스(프로젝트에 더 많은 팀원을 추가할 수 있음, 이로 인해 비용이 증가함)입니다. 21세기에 소프트웨어 개발이 발전함에 따라 더 나은 공동 작업의 필요성과 고객 피드백에 신속하게 대응할 수 있는 능력이 중요해졌고, 이에 따라 애자일 방법론이 탄생했습니다.
철의 삼각관계를 애자일에 매핑
워터폴 프로젝트 관리를 실행하는 팀이거나 애자일 개발을 처음 접하는 팀이라면 기억해야 하는 중요한 점은 고정된 것과 추정하는 것의 차이입니다. 워터폴 개발과 달리 애자일 프로젝트는 일정과 리소스가 고정되어 있는 반면 범위가 달라집니다. 애자일 개발에서는 프로젝트의 범위가 변경될 수 있지만 팀은 고정된 작업의 반복(스크럼 프레임워크를 사용하는 경우에는 스프린트, 칸반 프레임워크를 사용하는 경우에는 WIP 제한)에 커밋합니다. 또한 개발 프로세스 전반에 걸쳐 팀을 고정하는 것이 모범 사례입니다. 제품 또는 프로젝트에서 팀의 일관성을 유지함으로써 신뢰와 연속성을 쌓아서 효율성을 높일 수 있습니다.
애자일 개발에서도 범위에 대한 개념은 같습니다. 즉, 만들고 제공하려는 소프트웨어입니다. 그러나 애자일은 심층적이고 상세한 요구 사항을 미리 제시하려고 노력하기보다는 높은 수준의 요구 사항에 중점을 둡니다. 프로젝트의 범위는 Jira와 같은 도구에서 제품 매니저가 정기적으로 관리 및 그루밍(우선 순위 지정)합니다. 제품 매니저는 다양한 채널(시장 상황, 고객 피드백 및 경쟁 등)에서 애자일의 정성적 및 정량적 피드백을 기반으로 다음 스프린트에서 완료해야 할 작업을 결정합니다. 또한 리소스와 시간이 고정되어 있기 때문에 개발 팀이 시장 변화에 더 쉽게 대응하고 고객에게 더 빠르게 가치를 제공할 수 있습니다. 이러한 제약 조건의 투명성은 애자일 개발의 핵심 테넌트인 일관되고 빠른 릴리스 주기에 대해 팀을 투명하게 유지하며 철의 삼각관계의 렌즈를 통해 프로젝트를 살펴봄으로써 팀은 계획을 포기하지 않고 적응할 수 있습니다.
장기 애자일 계획 및 철의 삼각관계 프로젝트 관리
프로젝트가 커질수록 더 많은 팀이 필요하고 시간도 길어집니다. 따라서 범위가 달라질 수 있는 반면에 리소스와 시간을 수정한다는 개념은 모든 애자일 프로젝트에 유효한 접근 방식은 아닙니다. 장기적인 애자일 계획에는 팀이 미리 계획하고 비즈니스 목표를 달성할 수 있도록 보다 유연한 철의 삼각관계가 필요합니다. 예를 들어 린 스타트업 운동과 MVP(Minimum Viable Product) 개념에 대해 생각해 보세요. 정의에 따르면 MVP는 고객 가치를 제공하는 작은 기능의 집합(범위)입니다. 이러한 MVP에 도달하기 위해 팀은 고정된 범위(기능의 수)를 고수해야 할 수 있으며 시간은 유일한 변수가 될 수 있습니다(예: 특정 기능 없이는 출시할 수 없으므로 출시 날짜를 연기). MVP를 시작한 후에만 팀이 가변 범위로 전환합니다.
워터폴과 애자일 개발의 차이점과 관계없이 철의 삼각관계를 사용할 때 옳고 그른 방법은 없습니다. 비즈니스 목표를 달성하기 위해 최선의 의사 결정 및 절충안을 결정하는 데 도움을 주기 위한 것입니다. 타임라인과 같은 도구는 계획의 구성 요소(범위, 인력 및 시간)를 시각화하여 팀이 실시간으로 계획을 수립하도록 지원합니다. Jira에서 팀의 기존 데이터를 사용하여 범위, 팀 및 시간을 고려해 다음 제품 릴리스를 계획할 수 있습니다.