Overview of Waterfall and Agile

Waterfall 방법론

정의: 각 단계를 순차적으로 완료하는 선형적 접근 방식으로, 한 단계가 완료된 후에야 다음 단계로 넘어갈 수 있습니다.

역사: 1970년대에 개발되어 물리적 엔지니어링 분야(제조, 건설 등)에서 처음 사용되었으며, 이후 소프트웨어 엔지니어링에도 적용되었습니다.

단계:

  • 시작: 프로젝트 목표, 예산, 자원 등을 정의하고 승인을 받습니다.
  • 계획: 세부 프로젝트 계획, 일정 및 항목별 예산을 작성합니다.
  • 실행: 작업 모니터링, 팀 노력 관리 및 장애물 해결.
  • 종료: 모든 작업 완료 확인, 이해 관계자의 승인 획득 및 학습 내용 문서화.

특징:

  • 순차적 단계: 각 단계는 이전 단계의 완료 후에 시작됩니다.
  • 고정된 요구사항: 프로젝트가 시작된 후 변경이 어렵고 비용이 많이 듭니다.
  • 명확한 산출물: 초기 기대치와 목표가 명확하게 설정됩니다.

예시: 타이트한 예산으로 이벤트를 케이터링할 때. 손님 수를 확인하고, 메뉴를 정의하고 승인받으며, 재료를 주문하고 모든 준비를 완료합니다. 이 접근 방식은 변경의 위험을 최소화하고 자원의 효율적인 사용을 보장합니다.

장점:

  • 명확한 구조와 진행 상황 추적.
  • 고정된 요구사항으로 관리가 용이함.

단점:

  • 변경에 유연하지 않음.
  • 프로젝트 진행 중 조정이 어려움.

Agile 방법론

정의: 유연성과 적응성을 강조하는 반복적 접근 방식으로, 지속적인 개선과 고객 피드백을 중시합니다.

역사: 1990년대에 소프트웨어의 빠른 제공 요구에 대응하여 개념이 등장했으며, 2001년에 공식적으로 Agile이라는 이름이 붙여졌습니다.

단계:

  • 시작: 프로젝트 목표 설정 및 초기 요구사항 수집.
  • 계획: 반복적 계획 개발, 주로 스프린트라는 짧은 주기로 작업.
  • 실행: 작업이 겹치고, 팀의 진행 상황을 모니터링하며 고객 피드백을 반영하여 조정.
  • 종료: 과정을 정기적으로 검토하고 개선.

특징:

  • 반복적 사이클: 작업이 겹치며, 지속적인 피드백을 통해 조정.
  • 유연한 요구사항: 계획은 고객 피드백과 변화하는 필요에 따라 조정됨.
  • 지속적 제공: 프로젝트의 일부를 점진적으로 전달.

예시: 웹사이트 구축 프로젝트. 메인 홈페이지를 먼저 개발하고, 고객 피드백을 받은 후 다른 부분(예: 블로그, 온라인 예약 시스템)을 구축합니다. 이 접근 방식은 초기 피드백을 받아 조정하고 노력을 줄일 수 있습니다.

장점:

  • 높은 유연성과 적응성.
  • 지속적인 고객 피드백으로 프로젝트를 개선.

단점:

  • 지속적인 의사소통과 협업 필요.
  • 최종 비용과 일정 예측이 어려움.

적절한 방법론 선택

  • Waterfall: 요구사항이 명확하고 순차적인 작업이 필요한 프로젝트에 적합. 변경이 비싸거나 어려운 경우 이상적입니다.
  • Agile: 요구사항이 불확실하고 변화가 예상되는 프로젝트에 적합. 고객 피드백과 적응이 중요한 경우 이상적입니다.

Google에서의 적용

Google에서는 프로젝트 요구와 팀 역학에 따라 Waterfall과 Agile의 요소를 결합한 하이브리드 접근 방식을 사용합니다. 이를 통해 각 방법론의 장점을 활용하여 최상의 프로젝트 결과를 달성할 수 있습니다.

Waterfall과 Agile 방법론을 이해하면 프로젝트 관리 효과를 높이고, 향후 직무 인터뷰에서도 프로젝트 관리의 전반적인 이해를 보여줄 수 있습니다.