워터폴 방법론: 포괄적인 가이드

Atlassian 작성자: Atlassian
주제 찾아보기

프로젝트 관리 분야에서 오랫동안 일해 왔다면 워터폴 방법론을 접해 봤을 것입니다. 1970년대 구식 소프트웨어 개발 방식입니다.

워터폴 프로세스에서는 각 프로젝트 단계를 완료해야 다음 단계로 넘어갈 수 있습니다. 상당히 엄격한 선형 프로세스입니다. 이 방은 프로세스 시작 전에 이루어진 모든 요구 사항과 생각에 크게 의존합니다.

들어본 적 없더라도 걱정하지 마세요. 워터폴 방법을 세분화하여 작동 방식을 살펴보겠습니다.

워터폴 방법론이란?

워터폴 방법론은 잘 정립된 프로젝트 관리 워크플로입니다. 폭포와 같이 각 프로세스 단계는 다섯 단계(요구 사항, 설계, 구현, 확인, 유지 관리)를 거쳐 순차적으로 하향 진행됩니다.

방법론의 이름은 컴퓨터 과학자 윈스턴 로이스의 1970년 소프트웨어 개발 연구 논문에서 유래했습니다. 로이스는 이 모델에 “워터폴”이라는 이름을 붙인 적은 없지만 선형적이고 엄격한 프로젝트 관리 시스템을 만든 공로를 인정받습니다.

애자일 방법론 같은 다른 방법과 달리 워터폴은 유연성을 허용하지 않습니다. 다음 단계를 시작하기 전에 반드시 한 단계를 완료해야 합니다. 팀은 문제를 해결하기 전까지는 앞으로 나아갈 수 없습니다. 게다가 프로젝트 관리 소개 가이드에서 설명했듯이 한번 다음 프로젝트 단계로 넘어가면 팀에서는 버그 또는 기술적 부채를 해결할 수 없습니다.

워터폴 방법론의 단계

워터폴 방법론은 요구 사항, 설계, 구현, 확인, 유지 관리의 다섯 단계로 구성됩니다. 워터폴 개발의 다섯 단계를 하나씩 살펴보고 다음 단계로 진행하기 전에 각 단계를 완료하는 것이 중요한 이유를 알아보겠습니다.

요구 사항

요구 사항 단계에는 시스템이 해야 할 일이 나와 있습니다. 이 단계에서는 비즈니스 의무부터 사용자 요구에 이르는 프로젝트 범위를 결정합니다. 전체 프로젝트를 높은 시점에서 개략적으로 확인할 수 있습니다. 요구 사항은 다음 사항을 명시해야 합니다.

  • 프로젝트에 필요한 리소스.
  • 각 팀원이 각 단계에서 수행할 작업.
  • 각 단계의 소요 시간을 요약한 전체 프로젝트의 타임라인.
  • 프로세스의 각 단계에 대한 세부 정보.

하지만 Old Dominion University의 컴퓨터 과학 교수 Steven Zeil에 따르면 요구 사항은 "매우 추상적인 사항부터 상세한 수학적 사양에 이르기까지 다양할 수 있습니다.” 요구 사항이 구현을 정확하게 설명하지 못할 수도 있기 때문입니다. 이 문제는 개발 단계에서 해결해야 합니다.

디자인

모든 요구 사항을 수집하고 나면 설계 단계로 넘어갑니다. 여기서 설계자는 요구 사항을 충족하는 솔루션을 개발합니다. 이 단계에서 설계자는 다음을 수행합니다.

  • 일정 및 프로젝트 마일스톤을 만듭니다.
  • 정확한 결과물을 결정합니다.
  • 결과물을 위한 설계 및/또는 블루프린트를 만듭니다.

결과물은 소프트웨어를 포함할 수도 있고 실제 제품으로 구성될 수도 있습니다. 예를 들어 설계자는 소프트웨어의 경우 시스템 아키텍처 및 사용 사례를 결정합니다. 물리적 제품의 경우는 정확한 생산 사양을 파악합니다.

구현

설계가 확정되고 승인되고 나면 구현을 시작합니다. 설계 팀은 개발자가 구축할 수 있도록 사양을 넘겨줍니다.

이 단계를 달성하기 위해 개발자는 다음을 수행합니다.

  • 구현 계획을 만듭니다.
  • 빌드에 필요한 모든 데이터 또는 연구를 수집합니다.
  • 팀원들끼리 특정 작업을 할당하고 리소스를 배분합니다.

설계 중 구현이 안 되는 부분을 이 단계에서 발견할 수도 있습니다. 큰 이슈라면 설계 단계로 되돌아가야 합니다.

검증

개발자가 설계를 코딩하고 나면 이제 품질 보증을 수행해야 합니다. 좋은 사용자 경험을 보장하려면 모든 사용 사례를 테스트하는 것이 중요합니다. 버그가 있는 제품을 고객한테 릴리스해서는 안 되기 때문입니다.

또한 QA는 다음을 수행합니다.

  • 테스트 사례를 작성합니다.
  • 수정해야 할 버그와 오류를 문서화합니다.
  • 한 번에 한 측면을 테스트합니다.
  • 추적할 QA 메트릭을 결정합니다.
  • 다양한 사용 사례 시나리오와 환경을 다룹니다.

유지 관리

제품 릴리스 이후 개발 팀이 버그를 수정해야 할 수도 있습니다. 이슈가 발생하면 고객이 지원 담당자에게 알립니다. 그러면 그 요청을 해결하고 새 제품 버전을 릴리스하는 일은 팀의 책임입니다.

보시다시피 각 단계는 이전 단계에 따라 달라집니다. 단계 간 또는 단계 내에서 큰 오류를 허용하지 않습니다.

예를 들어 확인 단계에서 이해 관계자가 요구 사항을 추가하려는 경우 전체 프로젝트를 재검토해야 합니다. 이것은 전체 프로젝트를 버리고 다시 시작한다는 의미일 수도 있습니다.

워터폴 방법론의 이점

워터폴 방법론은 몇 가지 이점 덕분에 고정된 결과에 의존하는 프로젝트에서도 오래 지속하는 워크플로가 됐습니다. 2020년 설문조사에 따르면 프로젝트 전문가 중 56%가 전년도에 전통 모델 또는 워터폴 모델을 사용한 적이 있습니다.

워터폴 계획의 몇 가지 이점은 다음과 같습니다.

  • 명확한 프로젝트 구조: 워터폴은 엄격한 계획을 통해 혼란의 여지를 거의 남기지 않습니다. 팀이 지향하는 최종 목표가 분명하게 보입니다.
  • 비용 책정: 엄격한 계획을 통해 프로젝트에 드는 시간과 비용을 미리 파악할 수 있습니다.
  • 보다 쉬운 추적: 교차 부서 작업이 적어 진행률을 더 신속하게 평가할 수 있습니다. Jira Software에 있는 Gantt 차트에서 전체 프로젝트를 관리할 수도 있습니다.
  • 복제 가능 프로세스: 프로젝트가 성공하면 요구 사항이 비슷한 다른 프로젝트에 프로세스를 다시 사용할 수 있습니다.
  • 포괄적인 프로젝트 문서화: 워터폴 방법론은 블루프린트와 과거 프로젝트 기록을 제공하므로 프로젝트의 포괄적인 개요를 확인할 수 있습니다.
  • 위험 관리 개선: 사전 계획이 풍부하여 위험이 줄어듭니다. 개발자는 코드를 작성하기 전에 설계 문제를 찾아낼 수 있습니다.
  • 책임과 의무 강화: 각 프로세스 단계 내에서 팀이 책임을 집니다. 각 단계에는 명확한 목표, 마일스톤 및 타임라인이 있습니다.
  • 비전문 인력을 위한 보다 정확한 실행: 워터폴 방법을 사용하면 경험이 적은 팀원도 프로세스에 참여할 수 있습니다.
  • 추가 요구 사항으로 인한 지연 감소: 팀이 요구 사항을 미리 알고 있기 때문에 이해 관계자나 고객으로부터 추가 요청을 받을 가능성이 없습니다.

워터폴 방법론의 한계

워터폴에 한계가 없는 것은 아닙니다. 그래서 많은 제품 팀이 애자일 방법론을 선택합니다.

워터폴 방법은 예측 가능한 프로젝트에서는 훌륭하게 작동하지만 변수와 미지수가 많은 프로젝트에서는 실패합니다. 워터폴 계획의 또 다른 한계는 다음과 같습니다.

  • 긴 전달 시간: 단계별 프로세스는 애자일이나 린 같은 반복 프로세스와 달리 유연하지 않아 최종 제품 전달이 평소보다 오래 걸릴 수 있습니다.
  • 혁신의 유연성 제한: 이 모델을 사용하는 프로젝트에 예상치 못한 상황이 발생하면 파멸로 이어질 수 있습니다. 한 가지 이슈로 인해 프로젝트가 두 단계나 물러설 수도 있습니다.
  • 클라이언트 피드백 기회 제한: 요구 사항 단계가 완료되면 프로젝트는 클라이언트의 손을 떠납니다.
  • 수많은 기능 요청: 프로젝트 실행 중에 클라이언트의 발언권이 거의 없기 때문에 출시 이후에 기존 코드에 새 기능 추가와 같은 변경 요청이 많이 발생할 수 있습니다. 그러면 유지 관리 이슈가 더 많이 발생하고 출시 시간이 길어질 수 있습니다.
  • 기한 지연: 한 단계에서 중대한 이슈가 발생하면 모든 게 멈춰 버립니다. 팀이 문제를 해결하기 전까지는 앞으로 나아갈 수 없습니다. 이슈를 해결하려면 이전 단계로 돌아가야 할 수도 있습니다.

아래는 워터폴 접근 방식을 사용하는 프로젝트의 그림입니다. 그림과 같이 프로젝트는 엄격한 시간 블록으로 나뉘어 있습니다. 이 경직성 때문에 향후 반복 작업을 할 기회가 없을 수도 있으므로 개발자, 제품 매니저, 이해 관계자는 각 타임 블록에 할당할 시간을 최대한 요청하려고 하는 환경이 조성됩니다.

워터폴 릴리스 예제 | Atlassian 애자일 코치

워터폴 방법과 애자일 프로젝트 관리의 차이점은 무엇입니까?

애자일 프로젝트 관리와 워터폴 방법론의 최종 목표는 같습니다. 바로 명확한 프로젝트 실행입니다. 워터폴 계획은 팀을 단계별로 분리하지만 애자일은 여러 프로젝트 단계에 걸쳐 교차 부서 작업이 가능합니다. 팀은 경직된 단계 대신 계획, 실행, 평가 주기를 반복하며 작업합니다.

"애자일 매니페스토"는 워터폴 모델과 비교하여 애자일의 이점을 설명합니다.

  • 공정과 도구보다 개인 및 상호 작용
  • 포괄적 문서보다 작동하는 소프트웨어
  • 계약 협상보다 고객과의 협력
  • 계획을 따르기보다 변화에 대응

애자일 프로젝트 관리를 지원하고 워터폴과 같은 최종 목표를 제공하는 도구를 찾고 있다면 Jira Software를 고려하세요. 애자일 프로젝트에 가장 적합하며 다음을 지원합니다.

  • 작업 추적: 간트 차트, Advanced Roadmaps, 타임라인 및 기타 다양한 도구를 사용하면 프로젝트 전반의 진행률을 쉽게 추적할 수 있습니다.
  • 팀 정렬: 추적 기능을 사용하면 비즈니스 팀 간에 원활하게 계획을 세우고 모두가 같은 목표를 향해 정렬할 수 있습니다.
  • 프로젝트 및 워크플로 관리: Jira Software를 사용하면 애자일 워크플로에 사용할 수 있는 프로젝트 관리 템플릿을 이용할 수 있습니다.
  • 모든 단계에서 계획: 또 다른 Atlassian 제품인 Jira Product Discovery는 발견에서부터 제공에 이르는 모든 단계에서 제품 기능을 계획하고 우선 순위를 지정할 수 있는 제품 로드맵을 제공합니다.

Atlassian의 애자일 도구는 제품 개발 수명 주기에 도움이 됩니다. 추적 목적으로 애자일 메트릭도 사용할 수 있습니다. Jira Work Management를 사용하면 애자일 프로세스를 추진할 수 있습니다. 입력 양식을 사용하여 내부 팀이 수행하는 작업을 추적하고 반복 가능한 요청 프로세스를 제공합니다.

이러한 Jira 제품은 앱 내에 기본적으로 통합되어 있으며, 팀이 더 빠르게 일할 수 있도록 팀을 통합해 줍니다.

프로젝트 관리에 애자일 방법론 사용

워터폴 방법론은 프로젝트 관리 분야에서 오랜 역사를 가지고 있지만 오늘날의 소프트웨어 개발자들에게는 적합하지 않은 경우가 많습니다. 애자일 방법론은 더 높은 유연성을 제공합니다.

대부분의 팀이 애자일 프로세스를 선호하는 이유는 다음과 같습니다.

  • 변화에 대한 적응성: 문제가 발생하면 팀이 즉석에서 더 효과적으로 대응할 수 있습니다. 워터폴은 융통성이 적어서 문제를 처리하기 어렵게 만듭니다.
  • 지속적인 피드백 루프: 지속적 개선을 위해서는 피드백 루프가 필요합니다. 애자일을 사용하면 프로세스 중에 이해 관계자로부터 피드백을 수집하고 그에 따라 반복할 수 있습니다.
  • 커뮤니케이션 강화: 팀이 애자일 프로세스를 통해 협업합니다. 워터폴에서는 팀 간에 수많은 핸드오프가 이루어집니다. 이는 효과적인 커뮤니케이션을 방해합니다.


애자일 방법론에서는 Jira Software와 같은 프로젝트 관리 도구가 유용합니다. 또한 애자일 프로젝트에 프로젝트 관리 템플릿을 사용할 수도 있습니다. 팀은 하나의 도구에서 프로젝트를 계획하고 공동 작업하고 제공하고 보고할 수 있습니다. 이를 바탕으로 어떤 프로젝트에서든 모든 팀원이 정렬되고 프로젝트 관리를 간소화할 수 있습니다.

워터폴 방법론: 자주 묻는 질문

워터폴 방법론에 가장 적합한 대상은 누구입니까?

워터폴 방법론은 다음과 같은 프로젝트를 진행하는 프로젝트 매니저에게 가장 적합합니다.

  • 덜 복잡한 목표: 워터폴은 요구 사항이 복잡하지 않은 프로젝트에 가장 적합합니다.
  • 예측 가능한 결과: 워터폴은 복제 가능하고 검증된 프로젝트에 가장 적합합니다.
  • 프로젝트 범위 초과 가능성이 낮음: 고객이 마지막에 갑자기 요구 사항을 제시하지 않을 가능성이 높은 프로젝트가 워터폴에 적합합니다.

워터폴 방법론에 가장 적합한 대상은 누구입니까?

애자일 방법론은 다음과 같이 반복적인 사고방식을 가진 민첩한 팀에 적합합니다.

  • 다기능 팀: 서로 다른 기술을 가진 사람들로 구성된 팀으로, 프로젝트의 다양한 측면을 위해 함께 노력합니다. 유연성을 발휘할 수 있는 협업 유형입니다.
  • 자기 조직화 팀: 많은 협업이 필요로 하지 않는 자율적인 팀입니다. 프로젝트의 모호성을 수용하면서 훌륭하게 문제를 해결합니다. 이 사고방식은 결과보다 책임을 더 중시합니다.
  • 스타트업 및 중소기업: "빠르게 움직이고 시행착오를 거치겠다는" 사고방식이 도움이 됩니다. 그래서 빠르게 실패하고 배우고 발전할 수 있습니다.

마지막으로, 애자일은 고객의 의견을 통해 반복할 수 있는 고객 중심 프로젝트에 적합합니다.

프로젝트 관리 접근법을 구현하기 전에 어떤 요소를 고려해야 합니까?

프로젝트 관리에 도입할 적절한 방법론을 결정할 때 고려해야 할 네 가지 주요 요소는 프로젝트 복잡성, 조직 목표, 팀 전문성, 이해 관계자 참여입니다.

각각 자세히 살펴보겠습니다.

  • 프로젝트 복잡성: 워터폴은 더 크고 복잡한 프로젝트를 더 작은 기대치와 목표로 세분화하는 데 도움이 됩니다. 하지만 융통성이 적어 예측할 수 없는 일 또는 변화에 잘 대처하지 못합니다. 변수가 많은 복잡한 프로젝트에는 애자일이 더 효과적입니다.
  • 조직 목표: 조직이 달성하려는 목표가 무엇입니까? 혁신하는 것입니까, 아니면 현 상태를 유지하는 것입니까? 조직에서 사일로를 무너뜨리고자 한다면 애자일 방식이 가장 좋습니다. 그러면 팀이 더 자율적으로 협업할 수 있게 됩니다.
  • 팀 전문성: 애자일은 다기능 팀이 여러 기술을 갖추고 있는 경우에 매우 유용한 방법입니다. 팀원들이 하나의 기술에 크게 의존한다면 워터폴이 더 나을 수도 있습니다.
  • 이해 관계자 참여: 이해 관계자가 더 적극적으로 참여하는 경우 지속적인 피드백과 반복이 가능한 애자일이 가장 도움이 될 것입니다.
다음 단계
스크럼의 속도