폭포수 Vs 애자일 방식 프로젝트
#3 슬기로운 PM 생활 - 실패하지 않는 프로젝트 관리
프로젝트를 시작할 때 가장 먼저 고민되는 부분은 어떤 방식으로 프로젝트를 관리할 지에 대해 선택하는 것입니다. 기존에 많은 프로젝트는 폭포수(Water-fall) 방식으로 분석하고 설계하고 개발, 테스트 그리고 종료하는 형태로 진행하는 방식입니다. 최근에는 애자일(Agile) 방식의 프로젝트로 작은 범위의 분석/설계/개발/테스트를 반복하는 형태로 사이클을 돌면서 프로젝트를 완료해 나가는 방식입니다. 최근 디지털 전환이나 디지털 트랜스포메이션 프로젝트에서는 애자일 방식을 선택하여 진행하는 경우가 많습니다.
프로젝트 관리 방법론을 이야기하기 전에 프로젝트 관리의 정의에 대해 먼저 알아보겠습니다. (건축과 IT 프로젝트의 구조는 거의 비슷한 구조이므로 동일 자격증 (PMP)를 공유하고 있습니다.
프로젝트 관리 [Project Management, PM]
어떠한 프로젝트를 진행할 때, 보다 효율적으로 프로젝트를 관리하여 성공적으로 프로젝트를 수행하게 하는 일. 프로젝트가 계획되는 시점에서 선정되어 프로젝트의 시작에서 끝까지 일정관리, 자금관리, 인력관리 등 모든 부분이 이에 포함된다. 건설업에서는 CM(Construction Management)으로도 불린다. 큰 프로젝트인 경우 여러 개의 하부 프로젝트가 있을 수 있는 데 이때의 PM을 ‘프로그램 경영(Program Management)’이라고 한다.
출처. 네이버 지식백과 프로젝트 관리 [Project Management] (한경 경제용어사전)
폭포수(Water-fall) 방식 프로젝트
폭포수 또는 워터폴 방식의 프로젝트 방법론은 기존에 가장 많이 사용하던 프로젝트 방법론입니다. 프로젝트를 진행하면서 폭포수와 같이 한번 지나가면 돌아가지 못하는 방식이 폭포수(Water-Fall) 방식의 프로젝트 관리 방법입니다.
일반적인 프로젝트 관리 방식 / 폭포수 (Water-Fall) 방식폭포수 방식 프로젝트 정의는 다음과 같습니다.
폭포 방식의 프로젝트 방법론은 제품의 수명 주기의 각 단계가 순차적으로 일어나 폭포처럼 진행이 꾸준히 아래쪽으로 흐르는 모델입니다.
폭포수 모델을 누가 만들지는 않았지만 그보다는 특정 생산 단계가 완료되면(예를 들어 건물의 기초를 다지는 것과 같이) 되돌아가서 변화를 만드는 것이 엄청나게 비싸거나 비실용적인 다른 산업의 기업 소프트웨어 개발자들에 의해 이어지면서 비로소 문서화되었다. IT 프로젝트에서 모든 요구사항 수집 및 설계 작업은 코딩이 발생하기 전에 수행되는 형태입니다. 관련 자격으로는 영국 정부가 만든 PRINCE2와 PMI PMP가 있습니다.
일반적으로 워터폴 방식에는 프로젝트 시작 단계, 계획 단계, 실행 단계 및 마감 단계 전에 수행해야 하는 작업을 다루는 단계가 있습니다. IT 프로젝트에서는 프로젝트 시작-분석-설계-개발-테스트-배포-프로젝트 종료 등의 주요 작업 단계에서 검수 과정을 거치면서 프로젝트를 진행하는 방식입니다. 또한, 작업, 예외, 보고, 위험 및 문제를 관리하는 일련의 프로세스에 대한 관리가 필요합니다.
애자일(Agile) 방식 프로젝트
애자일 방식의 프로젝트 방법론은 디지털 전환 프로젝트를 할 때 많이 사용되는 프로젝트 관리 방식으로 반복적으로 순환하면서 프로젝트 산출물/제품의 품질을 높여 가는 관리 방법입니다.
애자일 프로젝트 관리 방식 / 애자일(Agile) 방식애자일(Agile) 방식 프로젝트의 정의는 다음과 같습니다.
애자일(Agile) 방법론은 초기에 광범위한 계획과 설계를 수행하는 대신, 정해진 시간(Sprint/Scrum) 동안 제품의 연속적인 반복 작업을 수행하는 기획자, 디자이너, 개발자 및 테스터를 포함하는 교차 기능 팀을 사용하여 시간이 지남에 따라 요구사항을 변경할 수 있습니다. 각 반복의 목표는 이해 관계자(Stakeholer)들에게 시연할 수 있는 작동 제품을 생산하는 것이다. 피드백은 다음 또는 미래의 반복에 통합될 수 있습니다.
작업(Tasks)은 비즈니스 사용자(EndUser) 가치에 따라 정확한 중요도, 난의도, 우선순위로 관리되는 백로그(Backlog)로 구성됩니다. 이러한 팀은 자체적으로 조직되며, 비즈니스 오너(Owner, 제품 담당자), 프로젝트 PM, 분석/설계자, 개발자 등을 포함합니다. 효율적인 대면 소통과 짧은 피드백 루프(Daily Scrum)가 중요합니다.
애자일 방법론 정의는 2001년 유타주에서 모인 17명의 소프트웨어 개발자들에 의해 도입되었다.
애자일 소프트웨어 개발 선언 (Agile Manifesto)
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
공정과 도구보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
애자일(Agile) 12가지 주요 원칙으로 구성된다.
1. 고객 만족이 가장 중요하다.
[귀사는 유용한 기능 또는 제품을 지속적으로 제공함으로써 즉각적인 고객 만족을 달성할 수 있습니다.
2. 변화는 불가피하다.
[그렇기 때문에 애자일 사용 시 변화하는 환경에 적응하는 것이 중요합니다.]
3. 실제로 작동하는 소프트웨어를 제공한다.
[그리고 발전된 모습을 보여주기 위해 자주 하는 것입니다.]
4. 애자일 개발 방법론에서는 일상적인 협력이 필수 요소이다.
[개발자와 사업가들 간의 소통이 있어야 합니다.]
5. 팀원들이 동기부여를 해야 한다.
[그들은 기꺼이 도전에 직면하고 변화에 적응해야 합니다.]
6. 모두가 공감할 수 있는 가장 좋은 방법 중 하나는 직접 대면하여 소통하는 것이다.
7. 기능이나 제품이 잘 작동하면 진행 상황을 측정할 수 있어야 한다.
8. 작업 흐름은 일정하게 유지되어야 한다. 팀이 움직이는 속도는 항상 동일해야 한다.
[따라서 프로젝트를 완료하는 데 걸리는 시간을 정확하게 예측할 수 있습니다.]
9. 우수한 설계뿐만 아니라 기술적 세부 사항에 대한 주의도 매우 중요하다.
10. 더 많이 하라는 것은 아니다.
[최대한 빨리 끝내야 한다는 것입니다.]
11. 자기 관리를 할 수 있는 팀이 최고이다.
[그들은 프로젝트의 성공을 위해 필수적인 책임감을 가지고 있습니다.]
12. 귀하의 팀은 정기적으로 피드백을 받아야 한다.
[최상의 제품 품질을 보장하기 위해 변화하는 규칙에 항상 적응해야 합니다.]
출처. https://agilemanifesto.org/iso/ko/manifesto.html
폭포수(Water-Fall) 방식 Vs. 애자일(Agile) 방식
CIO 매거진과 Forbes 해외 사이트에 실린 폭포수와 애자일 방식 프로젝트를 비교 글이 있어 참고로 같이 포함합니다. 국내 해외의 비교 관점이 다르고 같이 고려할 필요가 있기에 같이 올립니다. (이미지 클릭을 하면 큰 이미지를 볼 수 있습니다.)
애자일 Vs 폭포수 방식 비교 (출처. CIO Korea, https://www.ciokorea.com/news/166830 )
애자일 Vs 폭포수 방식 비교 (출처. https://www.forbes.com/advisor/business/agile-vs-waterfall-methodology/ )프로젝트 타임라인에 대한 유연성, 비즈니스 유저의 프로젝트 참여 여부, 유연성, 예산 등에 대해 비교되어 있기에 우리 프로젝트에 적합한 방식을 고려할 때 같이 고려하는 것이 필요합니다.
우리 프로젝트에 적합한 프로젝트는 뭘까?
프로젝트에서 시작하기 전에 프로젝트 관리 방식을 먼저 선정을 해야 됩니다. 하지만 남들(다른 회사) 한다고 따라 하는 건 정말 리스크가 큰 행동입니다. 쉽게 생각한다면 프로젝트에 실제 비즈니스 유저가 적극 참여하여 프로젝트를 한다면 애자일 방식이 맞겠지만 업체에게 맡기고 프로젝트 최종 산출물만 확인하는 형태면 워터폴이 더 적합할 수 있습니다. 사내 인력 중심의 프로젝트가 애자일에 조금 더 적합할 수 있습니다.
애자일 방식은 스프린트 방식으로 돌면서 제품의 기능 범위와 품질을 높여 가는 방식이므로 프로젝트 일정에 대한 유연성이 더 필요하고 기간이 바뀌고 투입 인력이 바뀐다면 예산에 대한 여유가 필요하고 조직적으로 이를 인정하고 변화할 수 있어야 됩니다. 조직적으로도 많은 노력이 필요합니다. 1~4주 주기의 스프린트(Sprint)와 날마다 스크럼(Scrum) 미팅을 진행하면서 체크하는 노력이 필요합니다. 기존 조직을 그대로 유지하고 기존의 생각을 바꾸지 않는(변화관리 없는) 상태에서 방법론을 바꾸면 조직적으로 부담을 줄 수 있습니다.
대규모 외주 턴키 방식의 경우 워터폴 방식의 프로젝트가 더 적합할 수 있습니다. 국내/외 프로젝트에서 계약하는 방식을 보면 선수금/중도금/잔금 등을 처리할 때 프로젝트의 Kick-Off 미팅 시 선수금, 설계 후 중간보고 후 중도금, 프로젝트 종료 보고 후 잔금을 주는 형태에서는 폭포수 방식의 프로젝트 방식이 조금 더 근접할 수 있습니다.
※ 슬기로운 PM 생활 - 실패하지 않는 프로젝트 관리
#1 RFP(제안요청서) 쓰는데 자격이 필요하다. https://brunch.co.kr/@df79991e83ed416/22
#2 프로젝트에서 가장 중요한 것은 작업분류체계(WBS) https://brunch.co.kr/@df79991e83ed416/26
#3 폭포수 Vs 애자일 방식 프로젝트 https://brunch.co.kr/@df79991e83ed416/25
#4 등산과 비슷한 프로젝트 여정 https://brunch.co.kr/@df79991e83ed416/28
#5 인테리어업체 사장과 IT PM의 공통점 https://brunch.co.kr/@df79991e83ed416/29
#6 프로젝트에서 중요한 것은 구축 업체 선정과 인력 구성 https://brunch.co.kr/@df79991e83ed416/32
#7 소 잃고 외양간 고치지 말자 - 실패하는 프로젝트의 전조 현상 https://brunch.co.kr/@df79991e83ed416/24
※ 글이 도움되시면 브런치 작가 "구독"과 "좋아요" 부탁드립니다.
글의 공유 및 인용은 가능하며 반드시 출처를 밝혀 주세요.
