프로젝트 개발에 적합한 방법론을 선택하는 일은 프로젝트 성공을 위한 첫걸음이다. 그러나 각 조직이 당면한 프로젝트에 어떤 방법론이 가장 적합한지를 구별하기는 쉽지 않다. 선택할 수 있는 프로젝트 관리 방법론의 가짓수가 너무 많을 땐 특히 그렇다.
널리 사용되는 대표적인 방법론은 애자일과 워터폴이다. 프로젝트 유형, 팀 구조, 역량, 인재 등의 요인에 따라 적합한 방법론의 유형은 다르다.
애자일이란 무엇인가?
애자일은 1970년대 윌리엄 로이스가 대형 소프트웨어 시스템 개발에 관해 제출한 논문에서 처음 등장했으며, '스프린트'(sprint)라는 짧고 점진적인 개발 주기로 구성된 프로젝트 관리 방법론이다.
각 주기는 제품이나 서비스 개발을 지속적으로 향상시키는 데 초점이 맞춰져 있다. 애자일 방법론은 애자일 선언(Agile Manifesto)의 4가지 기본 가치와 12가지 원칙에 바탕을 두고 있으며, 반복적이며 사람 중심적인 개발 방식을 취한다. 프로세스는 다음과 같다.
· 계획: 고객과 주요 이해관계자들이 함께 프로젝트 개념화, 브레인스토밍, 정의, 우선순위설정, 필요 자원, 예산 책정을 논의한다. 그다음 승인 및 실행하는 작업이 이뤄진다.
· 설계: 사용자경험 전문가가 스크럼 마스터, 클라이언트, 제품팀 그리고 기타 주요 이해관계자와 협력해 제품의 모양새와 여타 요소들을 결정한다.
· 개발: 개발팀은 이 단계에서 ‘스프린트’라고 불리는 여러 반복 작업을 거치며 고객 요구사항에 맞는 제품을 개발한다.
· 테스팅: 테스팅 단계에서는 제품이 고객 요구사항을 충족하는지 확인한다. 만약 결함이 발견되면 해당 제품을 개발 단계로 보내 결함을 수정하고 다시 테스트한다. 이 단계는 제품이 고객 요구사항이나 목표를 충족할 때까지 지속된다.
· 배포: 모든 단계가 완료되면 최종 제품을 클라이언트에게 전달한다.
피드백: 팀이 전체 개발 프로세스를 회고하며 제품이나 팀의 성과를 개선하는 방법을 검토한다.
애자일 개발을 위한 역량
애자일 팀은 고객 중심적이고, 환경 변화에 잘 적응하며, 악조건 속에서도 제품을 출시할 수 있어야 한다. 애자일 방식으로 개발하려면 팀과 고객 모두에 강력한 팀워크와 책임감이 있는 인력이 있어야 한다. 애자일 팀은 진행 속도가 빠른 개발 환경에서 좋은 성과를 낼 뿐 아니라 결과물의 퀄리티 및 개발 프로세스를 개선하는 데 초점을 둔다.
워터폴이란 무엇인가?
워터폴 방법론 또한 제품 개발에 사용되지만 개발 과정은 선형적이다. 즉 프로젝트 시작부터 최종 결과물 전달까지 특정 순서에 따라 이뤄진다. 워터폴 기반 프로젝트 팀은 아래의 프로세스나 주기를 동일하고 정확한 순서로 실행 및 완료한다.
· 요구사항 수집과 분석: 프로젝트에 사용될 기능적, 시스템적 또는 기술적 사양 정보를 클라이언트와 주요 이해관계자로부터 수집한다.
· 설계: 사용자경험 전문가는 고객, 제품팀 및 기타 주요 이해관계자와 함께 제품의 모양새와 여타 요소들을 결정한다.
· 테스팅: 성능, 시스템 및 사용자 승인 테스팅을 수행하여 제품이 요구사항을 충족하는지 확인한다. 만약 결함이나 버그가 발견되면 제품이 전달되기 전에 해결된다.
· 프로젝트 최종 결과물 전달: 프로젝트를 착수할 때 확정했던 사양을 제품이 충족하면 클라이언트에게 전달한다.
· 유지보수: 클라이언트는 제품을 전달받은 후 추가적인 스코프 변경을 요청할 수 있다. 프로젝트 비용과 시간은 추가될 수 있다.
워터폴과 관련된 역량
기존 워터폴 기반 프로젝트 팀은 프로세스와 절차가 잘 정착된 환경에서 업무를 능숙하게 처리한다. 이들은 의외적인 상황이 없을 때 작업 능률이 오른다. 또 체계적이면서 사전합의된 요구사항을 충족하는 데 초점을 맞춘다. 팀 구성원은 고객뿐 아니라 조직 내 다양한 영역의 이해관계자와도 능숙하게 협업할 수 있으며 정책이나 엄격한 가이드라인도 잘 준수한다.
애자일과 워터폴의 장단점
애자일 | 워터폴 | |
장점 | 개발 과정이 빠르면서도 유연하다. | 개발 주기가 애자일보다 형식적, 연속적이긴 하지만 프로세스가 길고 순서가 잡혀 있기 때문에 팀의 규모에 상관없이 따르기가 쉽다. |
짧고 반복적인 스프린트로 구성돼 있으면서 품질에 초점을 맞추기 때문에, 워터폴 방법론보다 빠르게 결함을 식별 및 수정할 수 있다. | 개발 주기가 이미 정해져 있어서 팀이 새로운 프로젝트를 안정적으로 시작할 수 있다. | |
여러 소규모 팀들이 개발 과정상의 여러 과제를 각각 할당 받아 처리할 수 있다. | 프로젝트 요구사항이 확정돼 있기 때문에, 프로젝트를 실행하기가 수월하며 개발 목표를 자주 변경하지 않아도 된다. | |
짧은 반복 과정을 거치므로 필요 시 개발과정 중에 신속하게 제품 변경을 할 수 있다. | 프로젝트 전 과정에 필요한 예산과 자원이 초기에 확정되기 때문에 예상 결과와 리스크를 통제하기가 훨씬 쉽다. | |
단점 | 스프린트에 대한 경험이 있으면서 빠른 반복 작업에 익숙한 스크럼 마스터가 필요하다. | 개발이 순차적으로 진행되기 때문에 앞단계가 완성돼야 다음 단계로 넘어갈 수 있다. 이로 인해 개발 속도가 느리며 유연성이 떨어진다. |
고객이 수많은 변경사항을 검토해야 하는 번거로움이 발생할 수 있다. | 테스팅 단계에 이르러서야 이슈가 발견되곤 한다. | |
팀원이 다양한 시간대의 지역에 흩어져 있음에도 잘 조직되지 않거나 자립성이 없는 경우, 애자일 방법론을 채택하면 문제가 발생할 수 있다. | 개발 요구사항이 프로젝트 초기에 정해지기 때문에 범위 변경이 자유롭지 못하다. | |
이런 조직에 적합함 | 고성능 소프트웨어 개발 팀 중에서도 특히 소프트웨어 개발 분야 팀 | 높은 예측 가능성과, 순차적인 프로젝트 타임라인, 사전 확정 예산이 필요한 팀 |
고품질의 결과물과 지속적인 개선에 초점을 맞춘 조직. 특히 이들이 생각하는 가치 제안이나 경쟁 차별화요소에 퀄리티가 포함되는 경우 | 프로젝트 팀의 경험이 적은 경우 | |
IBM, 시스코, AT&T, 마이크로소프트처럼 크고 복잡한 회사들이 프로세스를 간소화함으로써 변화에 더욱 신속하게 대응하고자 할 때 | 개발상의 변경이나 리스크에 덜 민감한 기업 | |
고객 및 외부 관계자와 정기적으로 긴밀한 협업을 수행하는 프로젝트 팀 | 제한적인 시간과 자원 탓에 협업이 자유롭지 못한 고객을 둔 기업 | |
프로젝트가 완벽하게 수행될 때까지 결과물을 기다리는 것보다 결과물에 대해 빠른 피드백이 필요한 팀 | 요구사항이 간단한 프로젝트 | |
타임라인이 긴 프로젝트 |
출처
SK하이닉스도 애자일 도입…"시장 변화에 효과적 대응"
'DevOps. > 팀, 프로젝트' 카테고리의 다른 글
IT 프로젝트가 실패하는 이유와 해결 방법 (0) | 2023.05.18 |
---|---|
아웃소싱 계약 노하우 | 분쟁 대비는 이렇게 (0) | 2023.05.16 |
IT 프로젝트(팀) 생산성을 최적화하는 방법 (0) | 2023.05.04 |
성공적인 원격 프로젝트 관리 노하우 | 원격 프로젝트 관리를 저해하는 요소와 해결 가능한 솔루션 (0) | 2023.05.04 |
(사기 저하 없이) IT 성과를 개선하는 방법 (0) | 2023.02.13 |
흔한 KPI 실수들 | 지표 믿다 발등 찍힌다 (0) | 2023.02.07 |
프로젝트 팀 성과 측정을 위한 KPI 설정·활용 가이드 (0) | 2023.02.06 |
프로젝트 실패를 암시하는 불길한 징조 (3) | 2023.02.06 |