애자일 개발 모델 (Agile Development Models)

애자일 개발 모델 (Agile Development Models)

이전에는 반복적인 폭포수 모델이 프로젝트를 완료하는 데 매우 인기가 있었다. 그러나 요즘은 소프트웨어 개발에 사용할 때 여러 가지 문제점이 발생한다. 이러한 어려움은 프로젝트 개발 중에 고객 변경 요청을 처리하고 변경 사항을 통합하는 데 필요한 높은 비용과 시간이 필요하게 된다. 이러한 폭포수 모델의 단점을 극복하기 위해, 1990년대 중반에 애자일 소프트웨어 개발 모델(Agile)이 제안되었다.

 

Agile은 프로젝트가 빠르게 변경 요청에 대응할 수 있도록 설계되었다. 따라서 Agile의 주요 목표는 빠른 프로젝트 완료를 용이하게 하는 것이다. 이 작업을 수행하기 위해서는 민첩성이 필요합니다. 민첩성은 프로세스를 프로젝트에 맞게 조정하고, 특정 프로젝트에 필수적이지 않은 활동을 제거함으로써 달성된다. 또한 시간과 노력의 낭비를 줄인다.

 

Agile은 몇가지의 개발 프로세스 가리킨다. 이러한 프로세스는 몇 가지 기본적인 특성을 공유하지만 서로 약간의 미묘한 차이점이 있다.

• Crystal : 크리스탈 Agile 방법론은 팀원 간의 효과적인 커뮤니케이션과 협력을 촉진하는 데 중점을 둔다. 또한 성공적인 개발 프로세스에 필수적인 인간적 요소를 고려한다. 이 방법론은 요구사항이 자주 변경되는 불확실성이 높은 프로젝트에 특히 유용하다.
• Atern : 이 방법론은 요구사항 변경 가능성이 중간정도 이거나 높은 프로젝트에 맞게 조정됩니다. 명확한 역할과 책임은 짧은 시간 내에 작동하는 소프트웨어를 제공하는 데 초점을 두며, 거버넌스는 이 방법론을 차별화하고 팀과 프로젝트에 효과적인 접근 방법을 제공한다.
• Feature-driven development: 이 방법론은 기능 목록을 작성하고 모델 평가를 수행하며, 기능별 설계 방법을 구현하는 일련의 기술을 활용하여 목표를 달성한다. 이 방법론은 최종 제품이 고객 요구 사항과 일치하고 시간 내에 제공되도록 보장하는 데 특히 효과적이다.
• Scrum: 이 방법론은 복잡한 프로젝트를 해결하고 성공적으로 완료하기 위한 프레임워크로 작용한다. 즉 Agile 개발 방법론을 위한 프로젝트 관리 방법이다. 프로세스를 감독하는 Scrum 마스터와 우선순위를 설정하는 제품 소유자가 이 방법론을 이끌고, 소프트웨어를 제공하는 책임이 있는 개발 팀이 또 다른 중요한 역할을 한다.
• Extreme programming (XP): 페어 프로그래밍, 지속적 통합 및 테스트 주도 개발과 같은 구체적인 기술을 사용하여 프로젝트 목표를 달성한다. XP는 빈번한 변경이 필요하고 불확실성이 높은 프로젝트에 이상적이다. 이는 새로운 요구사항과 피드백에 대한 빠른 적응을 가능하게 하기 때문이다.
• Lean development: 린 제조의 원칙에 뿌리를 두고 있으며, 불필요한 단계와 활동을 식별하고 제거함으로써 공정을 간소화하는 것을 목표로 한다. 이는 지속적인 개선, 시각적 관리, 가치 스트림 매핑과 같은 관행을 통해 달성되며, 이는 개선 영역을 식별하고 그에 따른 변경사항을 구현하는 데 도움이 된다.
• Unified process: UP는 특정 프로젝트의 요구사항에 맞게 맞춤화될 수 있는 방법론이다. 폭포수 모델과 애자일 방법론의 요소를 모두 결합하여 개발에 대한 반복적이고 점진적인 접근을 가능하게 한다. 즉, UP은 일련의 반복으로 특징지어지며, 각각의 반복으로 인해 작동하는 제품이 증가하여 고객에게 지속적으로 개선되고 가치를 제공할 수 있다.

위에서 설명한 모든 Agile 방법론들은 같은 핵심 가치와 원칙을 공유하지만 구현과 구체적인 실천 방법에서 차이가 있을 수 있다. Agile 개발은 팀원 간의 높은 수준의 협력과 커뮤니케이션, 그리고 변화하는 요구사항과 고객 피드백에 대한 적극적인 대응 능력을 필요로 한다.

 

Agile 모델에서는 요구사항이 작은 부분으로 분해되어 점진적으로 개발된다. 애자일 모델은 반복적인 개발 방법을 채택한다. 각 작은 부분은 한 번에 하나씩 개발된다. 각 반복 작업은 작고 쉽게 관리 가능하도록 의도되어 있으며, 몇 주 안에 완료될 수 있다. 한 번에 하나의 반복 작업이 계획되고 개발되며 고객에게 배포된다. 장기적인 계획은 수립되지 않는다.

 

Agile 모델은 반복적이고 점진적인 프로세스 모델의 결합이다.

애자일 SDLC 모델의 단계는 다음과 같습니다:

• 요구사항 수집 및 분석: 이 단계에서는 고객 요구사항을 수집하고 분석하여 프로젝트 목표와 관련된 요구사항을 도출
• 요구사항 기능 정의: 이 단계에서는 요구사항을 작은 기능 단위로 분할하고 이를 우선순위에 따라 정렬한다.
• 반복적인 개발: 이 단계에서는 작은 기능 단위로 구현 및 테스트 진행. 개발자, 테스터 및 고객의 적극적으로 협력 필요
• 반복 검토 및 피드백: 이 단계에서는 이전 단계에서 개발된 기능을 검토 및 고객 피드백 수집하여 프로젝트를 조정
• 반복적으로 배포: 이 단계에서는 이전 단계에서 검토 및 수정된 기능을 배포.

이러한 단계는 반복적으로 수행되며, 최종 제품에 이르기까지 여러 번 반복됩니다.

 

각 반복을 완료하는 데 걸리는 시간을 Time Box라고 한다. Time-box는 고객에게 반복을 제공하는 데 필요한 최대 시간을 말한다. 따라서 반복의 종료일은 변경되지 않는다. 그러나 개발팀은 시간 내에 제공하기 위해 필요에 따라 Time-box 동안 제공되는 기능을 줄일 수 있다. Agile 모델의 핵심 원칙은 각 Time-box 이후에 고객에게 증가된 기능을 제공하는 것이다.

Agile 모델의 원칙

• 각 Agile 프로젝트에서는 개발 과정에서 고객과의 밀접한 연락을 유지하고 다양한 요구사항을 명확히 이해하기 위해 일반적으로 팀에 고객 담당자가 포함된다. 각 이터레이션의 끝에서 이해관계자 및 고객 담당자는 진행 상황을 검토하고 요구사항을 재평가한다.
• Agile 모델은 포괄적인 문서 작성보다는 실제 작동하는 소프트웨어 배포에 의존한다.
• 몇 주 간격으로 고객 담당자에게 소프트웨어의 증분 버전을 자주 제공한다.
• 고객의 요구사항 변경 요청을 권장하고 효율적으로 통합한다.
• Agile 방법론은 팀 구성원들 간의 커뮤니케이션 강화가 더욱 중요하게 강조된다. 개발 팀 구성원 간의 향상된 커뮤니케이션은 공식 문서 교환보다는 대면 커뮤니케이션을 통해 이루어질 수 있다.
• 개발 팀 규모는 작게 유지하는 것이 좋으며 (5~9명), 이는 팀원들이 의미 있는 대화를 나누며 협력적인 작업 환경을 갖출 수 있도록 도와준다.
• 애자일 개발 프로세스에서는 일반적으로 페어 프로그래밍을 사용한다. 페어 프로그래밍은 두 명의 프로그래가 한 대의 컴퓨터에서 함께 작업하는 것을 말한다. 한 명은 코딩을 하고, 다른 한 명은 코딩하는 동안 코드를 검토한다. 이 두 명의 프로그래머는 1시간마다 역할을 교대한다.

장점

• Pair programming을 통해 작업하면, 프로그래머가 혼자 작업하는 것보다 간결한 프로그램을 만들어내고, 오류가 적게 발생한다.
• 전체 프로젝트의 개발 시간을 줄여준다.
• Agile 개발은 팀원 간의 대면 커뮤니케이션을 강조하여 프로젝트 목표에 대한 더 나은 협업과 이해로 이어진다.
• 고객 담당자는 각 반복 후 업데이트된 소프트웨어 제품에 대한 아이디어를 얻는다. 그래서, 필요에 따라 어떤 요구사항도 쉽게 바꿀 수 있다.
• Agile 개발은 고객을 개발 프로세스의 중심에 두고 최종 제품이 고객의 요구를 충족하도록 보장한다.

단점

• 문서화를 최소화 하기 때문에, 각 단계에서 중요한 결정이 내려지면 다른 팀원들이 잘못 이해할 가능성이 있다.
• Agile 개발 모델은 종종 짧은 스프린트에서 작업하기 때문에 프로젝트 일정 및 결과물을 계획하고 예측하는 것이 어려울 수 있다. 이는 프로젝트 지연을 야기할 수 있으며 프로젝트에 필요한 비용 및 자원을 정확하게 추정하기 어렵게 만들 수 있다.
• Agile 개발 모델은 요구사항이 변화에 따라 적응하고 반복적인 환경에서 일해야하기 때문에 팀 멤버들에게 높은 수준의 전문성이 필요하다. 이는 Agile 개발 관행에 익숙하지 않은 팀에게는 어려울 수 있으며, 프로젝트에서 지연과 어려움을 야기할 수 있다.
• 적절한 문서가 없기 때문에 프로젝트가 완료되고 개발자가 다른 프로젝트에 할당되면 개발된 프로젝트의 유지보수가 문제가 될 수 있다.