정처기 필기를 준비하면서 접했던 애자일 방법론에 대해 포스팅해보려고 한다.
어느날 클린코드책 표지를 봤는데 거기에도 애자일 단어가 있더라. 전혀 몰랐다. 하여튼 생각보다 자주 보이는 애자일 방법론에 대해 알아보자.
애자일 방법론의 등장 배경
변화하는 요구사항에 대한 대응 부족
소프트웨어 개발 프로젝트는 오랜 기간에 걸쳐 진행되는 경우가 많으며, 이 과정에서 시장의 요구사항이나 기술의 변화로 인해 초기 요구사항이 변경될 수 있다. 폭포수 모델과 같은 전통적 방법론은 이러한 중간 변경사항을 수용하는 데 한계가 있었다.
고객과의 소통 부족
전통적인 방법론에서는 개발 초기 단계에서만 고객의 요구사항을 집중적으로 수집하고, 그 이후에는 고객과의 소통이 상대적으로 줄어들었다. 따라서 최종 제품이 고객의 현재 요구사항을 반영하지 못하는 경우가 많았다.
프로젝트의 비효율성
폭포수 모델에서는 각 단계가 선형적으로 진행되며, 이전 단계가 완전히 끝나야만 다음 단계로 넘어갈 수 있었다. 기존의 방식에서는 소프트웨어 개발의 유연성을 제한하고, 시간과 자원의 낭비를 초래할 수 있는 문제점이 있었다.
팀워크와 협업의 중요성 간과
전통적인 방법론들은 문서 작성과 프로세스 준수에 중점을 두며, 이는 팀의 창의성과 문제 해결 능력을 제한하는 결과를 낳았다.
2001년, 소프트웨어 개발에 관련된 17명의 전문가들이 모여 "애자일 소프트웨어 개발 선언문"을 발표했다. 이 선언문은 소프트웨어 개발 과정에서 가장 중요하게 여겨야 할 네 가지 핵심 가치를 제시하며, 소프트웨어 개발의 새로운 패러다임으로서 애자일 방법론을 정립했다.
애자일 방법론의 핵심 가치
- 개인과 상호 작용을 프로세스와 도구보다 중요하게 여긴다.
- 작동하는 소프트웨어를 포괄적인 문서보다 중요하게 여긴다.
- 고객과의 협력을 계약 협상보다 중요하게 여긴다.
- 계획을 따르기보다 변화에 대응하는 것을 중요하게 여긴다.
애자일 방법론은 개발 프로세스를 더 유연하고, 고객 중심적이며, 팀 협업에 초점을 맞춘 방식으로 전환하려는 목표를 가지고 있다.
애자일 방법론의 주요 기법
-
스크럼 (Scrum)
스크럼은 소규모 팀이 짧은 사이클(일반적으로 2-4주)인 스프린트를 통해 특정 제품 기능을 개발하는 반복적인 방식이다. 스크럼 프로세스는 일일 스크럼 회의, 스프린트 계획 회의, 스프린트 리뷰 및 스프린트 회고 등의 활동으로 구성되며, 빠른 피드백 반영과 변화에 유연한 대응을 가능하게 한다. -
익스트림 프로그래밍 (Extreme Programming, XP)
XP는 고객의 만족을 최우선으로 하는 소프트웨어 개발 방법론으로, 페어 프로그래밍, 지속적인 통합, 테스트 주도 개발(TDD), 리팩토링 및 고객 피드백의 지속적인 통합 등을 강조한다. 이를 통해 소프트웨어 품질을 향상시키고, 개발 과정에서 발생할 수 있는 리스크를 줄인다. -
칸반 (Kanban)
칸반은 작업 항목의 시각적 관리를 통해 생산성을 향상시키는 방법론으로, "할 일", "진행 중", "완료" 등의 칼럼을 포함하는 칸반 보드를 사용하여 작업의 흐름을 관리한다. 칸반은 작업의 우선순위 설정, 작업 흐름의 시각화, 진행 중인 작업의 양 제한 등을 통해 효율적인 작업 진행을 돕는다. -
린 소프트웨어 개발 (Lean Software Development)
린 소프트웨어 개발은 낭비를 최소화하고 가치 창출을 극대화하는 것에 중점을 둔다. 원가 절감, 시간 단축, 고객 가치 증대를 목표로 하며, 가치 흐름 매핑, 불필요한 기능 제거, 지속적인 개선 등의 원칙을 따른다. -
피처 드리븐 개발 (Feature Driven Development, FDD)
FDD는 프로젝트를 구성하는 작은 기능(피처) 단위로 개발을 진행하는 방법론이다. 개발 과정은 모델링, 기능 목록 작성, 기능별 계획 및 구축, 그리고 정기적인 빌드 및 통합으로 이루어진다. FDD는 각 피처의 설계와 구현에 초점을 맞추며, 팀의 협업과 역할 분담을 강조하는 특징이 있다.
