Summry
본 문서에서는 소프트웨어 개발 방법론의 종류를 정리한다.
send me email if you have any questions.
Waterfall model(폭포수 모델)
요구분석 > 설계 > 디자인 > 개발 > 검증의 흐름이 물 흐르듯이 진행된다 해서 ‘워터폴’이라는 이름이 붙여진 모델. 현재까지 가장 많이 사용해 적용 사례가 풍부한 모델이고, 단계별로 정형화된 접근 방식을 사용하여 기술적인 위험요소가 적다는 장점을 가지고 있다.
정해진 순서대로 각 파트의 업무가 관리되기 때문에 프로세스상 방향을 쉽게 정할 수 있다는 것도 장점이다. 그러나 단점은 한 프로세스의 주기가 길고, 빠르게 전환이 어려워 프로세스가 활발히 이루어지기 어렵다는 점이다.
워터폴의 시작은 요구사항부터 시작해서 설계, 구현, 테스트를 거치면 완벽한 소프트웨어가 개발될 것이라고 생각하는 것이다. 하지만 사용자의 요구사항은 빈번하게 변경되고, 완벽한 설계라고 생각했던 구조는 구현하면서 불완전함을 깨닫게 된다. 사용자가 얼마만큼 알아서 완벽한 요구사항을 만들 것이며, 복잡한 서비스를 직접 개발해보지 않고서 얼마나 완벽한 설계가 나올 수 있을 것인가.
Waterfall 이벤트 순서
- 요구 사항 수집 및 문서화
- 설계
- 코드 및 단위 테스트
- 시스템 테스트 수행
- UAT(사용자 수락 테스트) 수행
- 문제 수정
- 완제품 납품
Agile model(애자일 모델)
Agile은 정확히 말하면 어느 특정한 개발 방법론을 지칭하는 것이 아니다. Agile은 ‘기민한, 날렵한’ 이란 뜻으로 좋은 것을 빠르게 취하고, 낭비 없게 만드는 다양한 방법론을 통칭해 일컫는 말이다. 애자일은 함께 얘기하고 함께 고민하면서 문제를 풀어나가는 것을 의미한다. 고객과의 소통을 중요시하는 방법론이 곧 애자일이다.
Agile 은 개발에 대한 반복적인 팀 기반 접근 방식이다. 이 접근 방식은 완전한 기능 구성 요소에서 애플리케이션의 신속한 전달을 강조한다. 작업과 일정을 만드는 대신 모든 시간은 “스프린트”라는 단계로 “타임 박스”된다. 각 스프린트에는 스프린트 시작 시 계획된 실행 중인 결과물 목록과 함께 정의된 기간(보통 몇 주)이 있다. 산출물은 고객이 결정한 비즈니스 가치에 따라 우선 순위가 지정된다. 스프린트에 대해 계획된 모든 작업을 완료할 수 없는 경우 작업의 우선 순위가 다시 지정되고 정보는 향후 스프린트 계획에 사용된다.
작업이 완료되면 프로젝트 팀과 고객이 일일 빌드 및 스프린트 종료 데모를 통해 검토 및 평가할 수 있다. Agile은 프로젝트 전반에 걸쳐, 특히 이러한 검토 중에 매우 높은 수준의 고객 참여에 의존한다.
애자일 소프트웨어 개발팀은 다음과 같은 부분에 가치를 두어야 한다.
- 개인과 개인 간의 상호작용이 프로세스 및 툴보다 우선
- 작동하는 소프트웨어가 포괄적인 문서보다 우선
- 고객과의 협업이 계약 협상보다 우선
- 변화에 대응하는 것이 계획을 따르는 것보다 우선
waterfall vs agile
이 두 가지 모두 사용 가능하고 성숙한 방법론이다. 각각의 장단점을 정리하면
Waterfall 장점
- 개발자와 고객은 개발 수명 주기의 초기에 제공될 항목에 동의한다. 이를 통해 계획 및 설계가 보다 간단해진다.
- 작업의 전체 범위를 미리 알고 있기 때문에 진행 상황을 더 쉽게 측정할 수 있다.
- 개발 노력 전반에 걸쳐 프로젝트의 활성 단계에 따라 팀의 다양한 구성원이 참여하거나 다른 작업을 계속할 수 있다. 예를 들어, 비즈니스 분석가는 개발자가 다른 프로젝트에서 작업하는 동안 수행해야 할 작업에 대해 배우고 문서화할 수 있다. 테스터는 코딩이 진행되는 동안 요구 사항 문서에서 테스트 스크립트를 준비할 수 있다.
- 검토, 승인, 상태 회의 등을 제외하고 요구 사항 단계 이후에는 고객 참석이 엄격하게 요구되지 않는다.
- 설계는 개발 수명 주기의 초기에 완료되기 때문에 이 접근 방식은 외부 시스템과의 통합을 위해 여러 소프트웨어 구성 요소를 설계해야 하는(때로는 병렬로) 프로젝트에 적합하다.
- 마지막으로, 소프트웨어는 모든 소프트웨어 산출물 에 대한 보다 완전한 이해를 바탕으로 완전하고 신중하게 설계할 수 있다. 이렇게 하면 코드 조각이 정의되고 잘 맞을 수도 있고 맞지 않을 수도 있는 응용 프로그램에 추가될 때 발생할 수 있는 개발 현상인 “단편 효과”의 가능성이 적은 더 나은 소프트웨어 디자인을 제공한다.
Waterfall 단점
- 거의 항상 부족한 영역 중 하나는 요구 사항의 효율성이다. 고객에게 의미 있는 방식으로 요구 사항을 수집하고 문서화하는 것이 종종 소프트웨어 개발에서 가장 어려운 부분일 수 있다. 고객은 때때로 세부 사항에 겁을 먹고 이 접근 방식을 사용하려면 프로젝트 초기에 제공된 특정 세부 사항이 필요하다. 또한 고객이 요구 사항 문서에서 애플리케이션을 항상 시각화할 수 있는 것은 아니다. 와이어프레임과 모형이 도움이 될 수 있지만 대부분의 최종 사용자가 이러한 요소를 서면 요구 사항과 함께 사용하여 얻을 수 있는 것에 대한 좋은 그림에 도달하는 데 어려움을 겪는다는 데는 의문의 여지가 없다.
- 순수한 Waterfall 개발의 또 다른 잠재적인 단점은 고객이 제공된 소프트웨어 제품에 불만족할 가능성이다. 모든 인도물은 문서화된 요구 사항을 기반으로 하기 때문에 고객은 거의 완료될 때까지 무엇을 전달할지 알 수 없다. 그때까지는 변경 사항을 구현하기 어렵고 비용이 많이 들 수 있다.
Agile 장점
- 이해관계자 참여
- 애자일은 각 스프린트 이전, 도중, 이후에 이해 관계자와 팀 참여를 위한 다양한 기회를 제공한다. 프로젝트의 모든 단계에 클라이언트를 참여시킴으로써 클라이언트와 프로젝트 팀 간에 높은 수준의 협업이 이루어지며 팀 이 클라이언트의 비전을 진정으로 이해할 수 있는 더 많은 기회를 제공한다.
- 투명도
- 애자일 접근 방식은 클라이언트가 기능의 우선 순위 지정부터 반복 계획 및 검토 세션, 새로운 기능을 포함하는 빈번한 소프트웨어 빌드에 이르기까지 프로젝트 전체에 참여할 수 있는 고유한 기회를 제공한다. 그러나 이것은 고객이 투명성의 추가 이점에 대한 대가로 진행 중인 작업을 보고 있음을 이해해야 한다.
- 조기 및 예측 가능한 배송
- 1-4주의 시간 제한이 있는 고정 일정 스프린트를 사용하여 새로운 기능이 높은 수준의 예측 가능성으로 빠르고 자주 제공한다. 이것은 또한 충분한 비즈니스 가치가 있는 경우 계획보다 일찍 소프트웨어를 출시하거나 베타 테스트할 수 있는 기회를 제공한다.
- 예측 가능한 비용 및 일정
- 각 스프린트는 고정된 기간이기 때문에 비용은 예측 가능하고 고정된 일정 시간 상자에서 팀이 수행할 수 있는 작업량으로 제한된다. 클라이언트는 각 기능의 대략적인 비용을 보다 쉽게 이해할 수 있으므로 기능의 우선 순위와 추가 반복의 필요성에 대한 의사 결정이 향상된다.
- 변경 허용
- 팀은 각 반복 중에 동의한 제품 기능의 하위 집합을 제공하는 데 계속 집중해야 하지만 전체 제품 백로그를 지속적으로 수정하고 우선 순위를 변경할 수 있는 기회가 있다.
- 품질 향상
- 프로젝트를 관리 가능한 단위로 세분화하여 프로젝트 팀은 고품질 개발, 테스트 및 협업에 집중할 수 있다. 또한 빌드를 자주 생성하고 반복할 때마다 테스트 및 검토를 수행하여 결함을 신속하게 찾아 수정하고 예상 불일치를 조기에 식별하여 품질을 향상시킨다.
Agile 단점
- 매우 높은 수준의 고객 참여는 프로젝트에 좋지만 이러한 유형의 참여에 대한 시간이나 관심이 없는 일부 고객에게는 문제가 될 수 있다.
- 애자일은 개발 팀의 구성원이 프로젝트에 완전히 전념할 때 가장 잘 작동한다.
- 애자일은 정해진 시간 안에 배달을 하고 우선순위를 자주 재조정하는 데 초점을 맞추기 때문에 배달을 위해 설정된 일부 항목이 할당된 시간 내에 완료되지 않을 수 있다. 추가 스프린트(처음에 계획한 것 이상)가 필요할 수 있으며, 이는 프로젝트 비용을 추가한다. 또한 고객 참여로 인해 프로젝트 전반에 걸쳐 추가 기능이 요청되는 경우가 많다. 다시 말하지만, 이는 전체 구현 시간과 비용을 추가할 수 있다.
- Agile 프로젝트에서 긴밀한 작업 관계는 팀 구성원이 동일한 물리적 공간에 있을 때 가장 쉽게 관리할 수 있지만 항상 가능한 것은 아니다. 그러나 웹캠, 공동 작업 도구 등과 같이 이 문제를 처리하는 다양한 방법이 있다.
- 애자일 개발의 반복적인 특성은 초기 아키텍처 및 디자인에서 시스템의 전체 범위를 고려하지 않는 경우 빈번한 리팩토링으로 이어질 수 있다. 이 리팩토링이 없으면 시스템의 전반적인 품질이 저하될 수 있다. 이는 대규모 구현이나 높은 수준의 통합을 포함하는 시스템에서 더욱 두드러진다.
Reference
애자일 프로젝트 계획: 빨리 만들고, 빨리 내보내야 하는 이유 - RSH
애자일 방법론이란? - Red Hat
Waterfall vs. Agile: Which is the Right Development Methodology for Your Project? - Mary Lotz
8 Benefits of Agile Software Development - Segue Technologies