📚 폭포수 (Waterfall)
정의
폭포수 모델은 소프트웨어 개발 단계가 위에서 부터 아래로 순차적으로 진행된다. 마치 폭포에서 물이 떨어지는 것 같다고 하여 폭포수라고 불린다.
폭포수 모델은 한 단계씩 진행함에 따라 다시 이전 단계로 가지 않고 계속 진행한다. 그렇기 때문에 다음 단계를 진행하기 전에 완벽하게 요구사항을 반영하여 개발했다는 것을 전제로 한다.
진행
요구사항 분석 → 설계 → 구현 → 검증(테스트) → 유지보수
장점
- 프로젝트를 시작하기 전 전체적인 요구사항과 디자인들이 완성되어 있으므로 프로젝트의 범위, 비용, 타임라인 등 전체적인 과정의 이해가 쉽다.
- 단계적으로 진행되기 때문에 현재 단계에 대한 이해가 빠르고 쉽다.
단점
- 수직적으로 진행되기 때문에 개발 도중에 요구사항이 변경될 경우 수정사항을 반영하여 처음부터 진행해야 한다.
- 고객 요구사항에 대한 즉각적인 피드백이 어렵다.
- 실제 작동하는 소프트웨어는 개발 후반부에 확인할 수 있다.
📚 등장배경
초기 개발 방법과 불확실성
초기 소프트웨어 개발 방법은 계획 중심의 프로세스였다.
하지만, 90년대 이후 소프트웨어 분야가 넓어지면서 사용자들이 일반 대중들로 바뀌기 시작했다. 모든 사람들이 소프트웨어 사용자가 되면서 트렌드가 급격하게 변화하는 시대가 되었다.
이로써 비즈니스 사이클(제품 수명)이 짧아졌고, SW 개발의 불확실성이 높아졌다.
새로운 개발 방법
SW 개발의 불확실성이 높아짐에 따라 전통적인 개발 방법 적용이 어려웠고 사람들은 자신만의 새로운 SW 개발 방법을 적용했다.
창의성이나 혁신을 계획하는 것이 이상하다고 생각했기 때문이다.
ex) 보수적인 회사에서 자기들이 생각하기에 혁신적인 일을 미리 계획했지만 다른 사람들이 보기에는 '뻔히 예상가는 그 회사같은 것' 이라고 생각할 수 있다.
따라서 경량 방법론 주의자(lightweight methodologies)들은 해보면서 고쳐나가는 방식의 방법론을 적용했다.
이는 규칙이 적고 가볍게 대응을 잘하는 방법을 의미하며, 아주 잘하는 단계에 이르면 겉으로 보기엔 미리 큰 그림을 만들어 놓고 하는 것처럼 보인다.
ex) 즉흥연기를 잘하는 사람을 보면 대본대로 하는 것 처럼 보인다.
이러한 경량 방법론 주의자 17명이 모여 자신들이 사용하는 개발 방법론을 공유하고, 공통점을 추려서 애자일 SW 개발 선언문을 만들었다.
📚 애자일 (Agile)
정의
애자일이란 특정 개발 방법론을 말하는 것이 아니고 애자일(Agile: 기민한, 좋은 것을 빠르고 낭비없게 만드는 것)한 개발을 가능하게 하는 다양한 방법론을 일컫는 말이다.
핵심
1. 협력
소프트웨어를 개발한 사람들끼리의 직무 역할을 넘어선 협력을 의미한다.
- 좋은 것은 함께 적용
- 스스로 느낀 좋은 통찰을 협력을 통해 다른 사람에게도 전해줄 수 있다.
- 예상하지 못했던 팀의 기대 효과를 가져올 수 있다.팀원이 2배의 속도로 개발할 수 있는 방법을 발견했다!
협력이 약하다면? 혼자 좋은 보상과 칭찬, 다른 사람의 코드와 이질적이어서 시스템 문제 발생 가능성
협력이 강하다면? 다른 팀워들과 공유하여 빠른 개발이 가능하고 더 나은 개선을 찾을 수 있다. 팀 전체 개선이 일어나는 긍정적 효과 발생
- 안 좋은 것은 함께 해결
- 문제가 발생하는 부분을 찾기 쉽다.
- 예상치 못한 문제를 협력으로 해결할 수 있다.팀원이 생각지도 못한 실수를 했는데 해결 방법을 모른다!
서로 다른 사람과 협력하면 새로운 방안을 찾고 빠르게 해결할 수 있다.
2. 피드백
피드백은 학습의 가장 큰 전제조건이다. 내가 어떻게 했는가를 확인하며 학습해야 한다.
SW 개발의 불확실성이 높을 수록 모르는 것을 빨리 배워나가야 하기 때문에 학습의 중요도는 올라간다.
이처럼 일을 잘하는 사람은 피드백을 찾는 능력(feedback seeking)이 뛰어나다. 더 자주 더 많은 사람들에게 피드백을 구하고 발전시켜 나가기 때문이다.
- 내부적 피드백: 내가 만든 것이 어떻게 됐는지 확인해보는 것
- 외부적 피드백: 내가 만든 것을 고객이나 다른 부서가 사용해보고 나온 피드백을 통해 또 다른 것을 배우는 것
전통적인 방법론과의 차이점
전통적인 방법론과 애자일 방법론의 차이는 SW 개발 도중 불확실성이 높아질 경우 나타난다.
- 전통적인 방법론: 계획을 더 잘 세울 것을 후회하며 계획대로 진행한다.
- 애자일 방법론: 계획을 변경하며 수정사항을 반영한다.
폭포수 모델은 요구분석단계에서 한 번에 모든 요구사항을 정확하게 전달하는 것이 원칙이다. 하지만 요즘같이 잦은 요구사항의 변경이나 큰 프로젝트를 맡아 요구분석단계를 완벽하게 하기 어려운 경우 적용하기 불가능하다.
즉, 애자일 방법론은 개발 과정에서 시스템의 변경사항을 유연하게 대응할 수 있도록 방법론을 제공하며 이런 한계점을 극복할 수 있게 해준다.
📚 스크럼 (Scrum)
스크럼은 애자일을 통한 가장 많이 사용하는 상호, 점진적 개발 방법론이다.
진행
1. 제품 기능 목록 작성 
제품에서 요구하는 기능과 우선순위를 매긴 요구사항 목록(제품 백로그, Product Backlog)을 작성한다.
개발 중에 수정이 가능하기는 하지만, 일반적으로 한 주기가 끝나기 전에는 수정하지 않는 것이 원칙이다.
2. 스프린트(Sprint) 계획 회의 
제품 책임자(Product Owner)가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율한다. 이 과정에서 선정된 제품 백로그가 이번 스프린트의 목표가 된다.
스프린트의 목표에 도달하기 위한 스프린트 백로그(Sprint Backlog)를 작성한다.
- 세부적으로 어떤 것을 구현해야 하는지
- 작업자
- 예상 작업 시간
3. 스프린트 수행 
작은 단위의 개발 업무를 단기간 내에 전력질주하여 개발하는 것을 의미한다.
전체 프로젝트 계획 기간 중에서 반복 주기를 정해 스프린트를 진행한다.
보통 계획 회의부터 제품 리뷰가 진행되는 날짜 까지가 1스프린트이다.
스프린트 도중에는 목표와 내용이 바뀌지 않아야 하는 것이 원칙이다.
ex) 스프린트 도중 생긴 Hotfix는 다음 스프린트의 백로그가 된다. Kanban의 경우에는 즉각적인 Hotfix가 가능하다.
4. 일일 스크럼 회의(Daily Scrum Meeting)
매일 정해진 장소와 시간에 모든 팀원이 참석하여 짧게 진행 상황을 점검한다.
한 사람씩 어제 한 일, 오늘 할 일, 문제점 및 어려운 점 등을 얘기한다.
5. 제품완성 및 스프린트 검토 회의
매회의 스프린트가 종료될 때마다, 스프린트 리뷰를 통해 만들어진 제품을 학습하고 이해한다.
이후 스프린트 회고를 통해 개선점을 찾고 피드백을 진행한다. 이 때, 팀의 단점보다는 강점과 장점을 찾아 더 극대화하는데 초점을 둔다.
장점
- 스프린트마다 생산되는 실행 가능한 제품을 통해 사용자와 의견을 나눌 수 있다.
- 회의를 통해 팀원들간 신속한 협조와 조율이 가능하다.
- 자신의 일정을 직접 발표함으로써 업무 집중 환경이 조성된다.
- 프로젝트 진행 현황을 통해 신속하게 목표와 결과 추정이 가능하며 변화 시도가 용이하다.
단점
- 스프린트마다 제품을 만들어야 하기 때문에 추가 작업시간이 필요하다.
- 짧은 회의 시간을 지키기 힘들고, 그만큼 작업 시간이 줄어든다.
- 프로젝트 관리에 중점을 두기 때문에 프로세스 품질 평가에는 미약하다.
❓ 언제 사용해야 할까?
폭포수
- 고객의 요구사항이 단순하고 변경 가능성이 높지않음
- 프로젝트의 규모와 난이도가 높지않음
- 각 단계 종료 후 나올 산출물의 결과가 명확함
애자일
- 정확한 목표를 위한 프로세스를 정립하지 못한 조직
- 쉽고 빠르게 애자일 모델을 적용해볼 수 있음 - 전통적인 방법론을 도입해 진행하고 있지만, 효율적인 결과물을 내지 못하는 조직
- 애자일 모델의 도입으로 조직의 문화가 바뀌고 효율성 개선 가능
[참고]
