애자일 및 워터폴 프로젝트 관리 비교

애자일 개발의 얼리 어답터는 종종 작고 자립적인 프로젝트를 진행하는 소규모 자립 팀이었습니다. 애자일 모델이 작동할 수 있음을 증명하여 전 세계 소프트웨어 제조업체에 기쁨과 도움을 주었습니다. 워터폴 개발 모델은 대부분의 팀에서 효과적인 애자일 프로젝트 관리와 달리 소프트웨어 개발에 효과적이지 않다는 것이 밝혀졌습니다

애자일 프로젝트 관리의 인기로 인해 더 많은 조직이 단일 팀이나 프로젝트를 넘어 애자일을 확장하고 이것을 전체 프로그램에 적용하게 되었습니다. 애자일은 IT, 마케팅, 비즈니스 개발 등을 포함하여 개발 팀 너머로 확산되었습니다.

애자일 프로젝트 관리는 고객 피드백을 포함하는 지속적 릴리스에 중점을 둔 프로젝트 제공에 대한 반복적 접근 방식입니다. 각 반복 중에 조정할 수 있는 능력은 속도와 적응성을 촉진합니다. 이 접근 방식은 제한된 편차가 있는 경로 설정을 따르는 선형 워터폴 프로젝트 관리 접근 방식과는 다릅니다.

오늘날의 고객과 비즈니스가 신속한 대응과 변화를 필요로 하는 상황에서 애자일은 개발 프로세스 중에 조정하고 반복할 수 있는 유연성을 제공합니다. 애자일 프로젝트 관리는 개발 및 운영 팀이 공동으로 작업하는 DevOps 관행의 초석이기도 합니다.

워터폴 프로젝트 관리 접근 방식은 단계가 최종 승인을 받을 때까지 진행되지 않는 프로젝트 단계를 포함하며 명확하게 정의된 실행 순서를 수반합니다. 단계가 완료되면 이전 단계를 다시 확인하기가 어렵고 비용이 많이 들 수 있습니다. 애자일 팀은 비슷한 순서를 따를 수 있지만 정기적인 피드백 루프를 통해 조금씩 늘려나갈 수 있습니다.

워터폴 프로젝트 관리 접근 방식은 선형의 순차적 공식을 따릅니다. 예측 가능하고 반복되는 프로세스가 있는 작업에 적합하지만 개발 팀이 기습을 당하거나 경쟁업체보다 빠르게 조정할 수 없는 경우가 생깁니다.

A single missed deadline or scope change during a waterfall project can cause outsized impacts on subsequent releases. Additionally, when a team is fully focused on the next phase of work, resolving technical debt or fixing bugs can be painful if the team is fully allocated to new feature work and always pressing forward to the next stage.

아래는 엄격하게 분할된 시간 블록이 있는 표준 워터폴 프로젝트의 그림입니다. 개발자, 제품 소유자 및 이해 관계자가 향후 반복할 기회가 없을 수 있으므로 각 시간대에 가능한 한 많은 시간을 요청하게 되는 “이용하지 않으면 잃는다”라는 사고방식이 만들어집니다. 일반적으로 워터폴을 사용하는 팀은 모두가 원래 계약이 변경되지 않는다는 데 동의하는 “변경 제어”를 통해 범위 초과를 제어하려고 합니다.

워터폴 모델은 제품 구축에서 알려진 과제 중 일부를 악화시킬 수 있습니다.

• 블로커 및 종속성 관리: 기존의 프로젝트 관리 스타일은 차단 이슈가 해결될 때까지 프로젝트를 진행할 수 없는 "중요 경로"를 만드는 경우가 많습니다.
• 사용자 피드백 및 제품 검증을 받기 어려움: 설상가상으로 최종 고객은 제품이 완전히 완성될 때까지 제품과 상호 작용할 수 없습니다. 따라서 제품 디자인 및 코드의 중요한 이슈는 릴리스 때까지 발견되지 않습니다.

워터폴의 장점

• 명확하게 정의된 단계, 순차적 프로세스로 인해 조정이 덜 필요함
• 명확한 프로젝트 단계는 작업의 종속성을 명확하게 정의하도록 지원
• 요구 사항을 정의한 후 프로젝트 비용을 예측할 수 있음
• 디자인 및 요구 사항 문서화에 더 집중
• 소프트웨어를 작성하기 전에 보다 체계적이고 구조적인 디자인 단계

워터폴의 단점

• 더 엄격한 단계 시퀀스로 인해 작업을 분할하고 공유하기 더 어려우며 팀은 더 전문화되어 있음
• 단계 전환 중 지연 및 장애로 인한 시간 낭비 위험
• 전문 단계 팀을 이행하기 위한 추가 채용 요구 사항이 있는 반면 애자일은 더 많은 부서 간 팀 구성을 장려함
• 단계 전환 간 핸드오프 중 추가 커뮤니케이션 오버헤드
• 현재 단계에 초점을 맞추므로 애자일과 비교할 때 제품 소유권과 참여도가 그다지 강하지 않을 수 있음

애자일은 소프트웨어 팀에 의해 처음 도입되었으며, 소프트웨어 팀은 기존의 순차적 워터폴 접근 방식에서 개발 수명 주기 전반에 걸쳐 일관된 피드백과 조정을 받는 방법으로 전환했습니다.

애자일 프로젝트 관리는 정기적인 피드백 간격을 통해 몇 가지 증분 단계를 만들어 개발에 대한 반복적인 접근 방식을 취합니다. 이것은 팀이 선형 경로에 국한되지 않고 제품 개발 프로세스 전반에 걸쳐 조정할 수 있기 때문에 조정 가능성을 촉진합니다. 또한 시간이 지나면서 팀이 일련의 성공을 거둘 수 있도록 영향력이 큰 정기적인 릴리스를 허용합니다.

반복 릴리스는 팀이 다음을 수행할 수 있는 다양한 기회를 제공합니다.

• 새로 발견된 요구 사항에서 차단된 작업에 이르기까지 변화하는 상황에 적응합니다.
• 최종 제공 기한에 대한 스트레스 없이 대응을 통해 반복하고 프로세스 중에 이해 관계자로부터 피드백을 수집할 수 있습니다.
• 역할 전반에 걸쳐 관계 및 연결을 구축하여 구성원이 더 쉽게 연결하고 효과적으로 소통할 수 있도록 합니다.

애자일을 사용하면 팀이 프로젝트 중에 불가피하게 발생하는 변경 사항에 더 탄력적으로 대응할 수 있습니다.

훨씬 더 큰 장점은 소프트웨어 팀 간에 스킬 집합을 공유한다는 것입니다. 팀의 겹치는 스킬 집합은 팀 코드베이스의 모든 부분에서 작업에 유연성을 더합니다. 이렇게 하면 프로젝트 방향이 바뀌더라도 작업과 시간이 낭비되지 않습니다. (자세한 내용은 훌륭한 애자일 팀 구축에 대한 문서를 참조하세요.)

• 애자일 프로젝트는 정기적인 피드백 간격을 포함하는 몇 가지 증분 단계로 분할됩니다.
• 프로젝트 요구 사항은 더 작은 조각으로 분할된 다음 중요도에 따라 우선 순위가 지정됩니다.
• 공동 작업, 특히 고객과의 공동 작업을 촉진합니다.
• 고객의 요구 사항을 충족할 수 있도록 정기적으로 조정됩니다
• 계획과 실행을 통합하여 팀이 변화하는 요구 사항에 효과적으로 대응할 수 있도록 합니다

애자일 프로젝트 관리의 장점

• 더 빠른 피드백 주기
• 조기에 문제 식별
• 고객 만족 가능성 증대
• 시장 출시 시간 대폭 개선
• 가시성/책임감 향상
• 시간이 지나면서 전담 팀의 생산성 향상
• 가치 제공에 중점을 둔 유연한 우선 순위 지정

애자일의 단점

• 중요 경로 및 프로젝트 간 종속성이 워터폴에서와 같이 명확하게 정의되지 않을 수 있음
• 조직 학습 곡선 비용이 있음
• 지속적 배포 파이프라인을 통한 진정한 애자일 실행에는 많은 기술적 종속성과 엔지니어링 비용이 필요함

애자일로 전환하는 것은 어려울 수 있습니다. 특히 팀이나 조직이 보다 전통적인 프로젝트 관리 접근 방식에 뿌리를 두고 있는 경우 더욱 그렇습니다. 애자일 관행으로 전환하려면 많은 프로세스 변경이 필요할 수 있습니다. 특히 개발 및 운영 팀이 긴밀하게 협력하여 소프트웨어를 개발하고 유지 관리하는 DevOps 접근 방식을 도입하는 경우 더욱 그렇습니다. 애자일 원칙을 도입할 때 팀과 이해 관계자는 다음 두 가지 중요한 개념을 수용해야 합니다.

• 제품 소유자는 팀의 결과 가치를 최적화하는 데 중점을 둡니다. 팀은 가장 중요한 작업을 우선시하는 제품 소유자에게 의존합니다.
• 개발 팀은 작업 수용량이 맞는 작업만 수락할 수 있습니다. 제품 소유자는 팀에 작업을 푸시하거나 임의의 기한에 커밋하지 않습니다. 개발 팀은 새 작업을 수락할 수 있으므로 프로그램의 백로그에서 작업을 끌어옵니다.

애자일 프로그램이 반복적인 방식으로 작업을 구성, 실행, 구조화하는 데 사용하는 메커니즘을 살펴보겠습니다.

제품 로드맵은 시간이 지나면서 제품 또는 솔루션이 어떻게 발전하는지 간략하게 설명합니다. 애자일 개발 로드맵은 팀이 증분 목표와 프로젝트 전체 목표를 모두 달성할 수 있도록 지원하는 중요한 컨텍스트를 제공합니다. 로드맵은 광범위한 기능 영역인 이니셔티브로 구성되며 기능을 사용할 수 있는 시기를 알리는 타임라인을 포함합니다. 작업이 진행되고 팀이 더 많은 것을 배우면 새로운 정보를 반영하기 위해 로드맵이 변경됩니다. 아마도 미묘하거나 광범위한 방식으로 변경될 것입니다. 목표는 이해 관계자와 효과적으로 협력하고 경쟁 환경에 대응하기 위해 프로젝트에 영향을 미치는 현재 조건과 장기 목표에 로드맵을 집중시키는 것입니다.

다음은 제품 팀을 위한 간단한 로드맵으로, 상자에 이니셔티브가 있고 타임라인은 빨간색 마일스톤 마커로 표시됩니다.

로드맵의 각 이니셔티브는 일련의 요구 사항으로 나뉩니다. 애자일 요구 사항은 기존 프로젝트와 관련된 100장 분량의 문서가 아니라 필요한 기능에 대한 간단한 설명입니다. 요구 사항은 시간이 지나면서 진화하며 고객과 원하는 제품에 대한 팀의 공유된 이해를 활용합니다. 모든 팀원이 지속적인 대화와 공동 작업을 통해 공유된 이해를 개발하는 동안 애자일 요구 사항은 효율적으로 유지됩니다. 구현이 곧 시작될 때만 완전한 세부 사항으로 구체화됩니다.

백로그는 애자일 프로그램의 우선 순위를 설정합니다. 팀은 새로운 기능, 버그, 개선 사항, 기술 또는 아키텍처 작업 등 모든 작업 항목을 백로그에 포함합니다. 제품 소유자는 엔지니어링 팀의 백로그에서 작업의 우선 순위를 지정합니다. 그런 다음 개발 팀은 수행해야 하는 작업에 대한 SSoT(Single Source of Truth)로 우선 순위가 지정된 백로그를 사용합니다.

애자일 팀은 메트릭을 바탕으로 성공합니다. WIP(진행 중인 작업) 제한 덕분에 팀과 비즈니스는 우선 순위가 가장 높은 작업을 제공하는 데 집중할 수 있습니다. 번다운 차트 및 컨트롤 차트 같은 그래프는 팀이 제공 케이던스를 예측하는 데 도움이 되며 연속 흐름 다이어그램은 병목 현상을 식별하도록 지원합니다. 이 메트릭 및 아티팩트를 통해 모두가 큰 목표에 집중하고 향후 작업을 제공할 수 있는 팀의 능력에 대한 자신감을 키울 수 있습니다.

애자일 프로세스는 팀원들 사이에 높은 수준의 신뢰가 있어야만 작동할 수 있으므로 신뢰를 만들어 냅니다. 프로그램과 제품에 무엇이 적합한지에 대해 어려운 대화를 나누려면 솔직함이 필요합니다. 대화는 정기적으로 이루어지기 때문에 아이디어와 우려 사항이 정기적으로 표현됩니다. 즉, 팀원들은 대화 중에 내린 결정을 실행할 수 있는 서로의 능력 및 의지에 확신을 가져야 합니다.

애자일 프로젝트 관리는 소프트웨어 프로젝트뿐만 아니라 모든 유형의 프로젝트를 위한 혁신적인 접근 방식입니다. 애자일은 개발 수명 주기 동안 변화에 대응할 수 있는 유연성을 제공하여 팀이 고객의 요구를 충족하는 더 높은 품질의 제품을 제공할 수 있도록 합니다. 애자일은 팀의 역량을 강화하고 책임을 구축하며 혁신을 장려하는 동시에 지속적인 개선을 촉진합니다. 애자일은 레일에서 벗어나지 않고도 변화에 대응할 능력을 제공합니다. 모든 프로그램에 좋습니다.

Learn more about agile project management and check out our free jira project management template. Plus, dive into agile adoption with agile tools for software teams, and learn how to communicate the progress of work across teams.