Agile 방법론
Waterfall 워터폴
- 요구분석 → 설계 → 디자인 → 코딩 → 개발 순으로 순차적으로 이어지는 흐름
| 장점 | 단점 |
|---|---|
| * 오랜 기간 사용되어 적용 사례 많음 * 단계별로 정형화된 접근방식을 사용하기 때문에 기술적인 위험 요소가 적음 * 정해진 순서대로 각 파트의 업무가 분장되고 관리되기 때문에 프로세스 상의 마일스톤을 정하는 것이 비교적 쉬운 편 |
* 실제로 각 단의 경계를 명확히 구분하고, 앞선 파트의 업무가 완전히 끝난 후 다음 단계를 시작하는 것이 거의 불가능 * 거의 완성 단계에 있을 때에서야 고객이 피드백을 주기 시작하고, 이미 지나온 단계에 수정이 필요한 상황 발생 |
Agile (= 기민한, 날렵한)
- 전체적인 플랜을 짜고 문서를 통해 주도해 나가던 과거의 워터폴 방법의 한계를 해결하기 위해 고안
- 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어 내며 필요할 때마다 요구사항을 더하고 수정하여 커다란 소프트웨어를 개발해 나가는 방식
- 프로토 타입이 계속해서 생산됨으로 고객이 개발과정에 참여할 수 있는 여지가 커짐
- 고객이 기능이 실제로 구동되는 모습을 확인하고, 수정요청을 하거나 다음 단계로 넘어가는 긴밀한 관계 형성
- Less Document-Oriented - 문서를 통한 개발 비지향
- Code-Oriented - 실질적인 코딩을 통한 방법론
| 애자일 4가지 특성 |
|---|
| 개인과 개인 간의 상호작용이 프로세스 및 툴보다 우선 |
| 작동하는 소프트웨어가 포괄적인 문서보다 우선 |
| 고객과의 협업이 계약 협상보다 우선 |
| 변화에 대응하는 것이 계획을 따르는 것보다 우선 |
애자일 vs. 워터폴
| 워터폴 모델 (Waterfall Model) | 애자일 모델 (Agile Model) |
|---|---|
| 초기에 미리 정의된 요구사항 미리 요구사항을 파악하고 프로젝트 전체에 대한 분석이 가능 |
프로젝트 과정에 걸쳐 생기는 요구사항 미리 모든 요구사항을 알 수 없다는 가정하에 시간적 변화를 인지하고 지속적으로 요구사항을 수렴 |
| 큰 릴리즈 정형화된 프로세스에 따라 주기 별 릴리스, 업데이트가 비교적 느림 |
작고 빠른 릴리즈 고객이 원하는 것을 파악하여 가능한 빨리 니즈를 충족 시키는 것을 중요시 |
| 계획중심 프로젝트에 대하여 완벽한 계획을 수립하고 진행 |
학습 중심 최소한의 지식으로 시작하여 단계를 거듭, 학습 |
| 적은 의사소통 문서중심의 방법론으로 문서에 근거하여 프로젝트를 수행: 문서 중심 |
많은 의사소통 프로젝트 팀 간, 고객 간의 많은 의사소통으로 진행되는 프로젝트: 사람 중심 |
| 단계별 개발 초석부터 차근차근 단계를 거쳐 튼튼한 기반의 개발 (하드웨어 적합) |
기능별 개발 고객의 니즈를 빠르게 반영하여 개발하는 과정을 짧은 주기로 반복 |
| 단계별 산출물 전달 계획 중심적 방법론으로 정해진 단계가 완성됨에 따른 산출물 점검 |
지속적인 산출물 전달 프로젝트 진행 중 잦은 산출물 공유로 수정사항에 빠르게 대처 |
| 마지막 통합 초기 계획이 완전하다는 가정하에 중간 통합 없이 최종 프로세스 수행 후 통합 후 문제점 도출 및 해결 |
잦은 통합 기능별 완료 시기에 맞춰 잦은 통합과 문제점 도출 및 해결 |