애자일 방법론
#
Find similar titles
- 최초 작성자
- 최근 업데이트
Structured data
- Category
- Algorithm
Table of Contents
애자일 방법론 #
애자일 방법론이란? #
- 애자일 방법론 이란, ‘Agile = 기민한, 날렵한’ 이란 뜻으로 좋은 것을 빠르게 취하고, 낭비 없게 만드는 다양한 방법론을 통칭해 일컫는 말이다. 앞을 예측하며 개발하지 않고, 일정한 주기를 가지고 계속 검토해 나가며 필요할 때마다 요구사항을 더하고 수정하여 커다랗게 살을 붙이면서 개발해 프로세스 모델 방식이다. 미리 정해진 몇 개의 단계에 따라 엄격한 순서대로 이루어지는 일직선의 과정인 폭포수의 프로세스와는 비교가 많이 되는 반대의 개념이다.
애자일 방법론의 진행 과정 #
- 애자일 방법론은 계획 → 설계(디자인) → 개발(발전) → 테스트 → 검토(피드백) 순으로 반복적으로 진행된다. 계획을 세운 후 다음 단계까지 기다려서 절차대로 진행하는 폭포수 모델과 달리 먼저 진행 후 분석, 시험, 피드백을 통하여 개선하여 나가는 진행 모델이다.
그림 1. 애자일 모델 도식화 (출처)
- 계획 및 분석 : 고객과 사용자가 원하는 바를 파악하여 타당성을 조사하고 SW 기능과 제약조건을 정의하는 명세서 작성, 대상이 되는 문제 영역과 사용자가 원하는 task를 이해하는 단계
- 설계(디자인) : 기획 의도에 맞는 설계 및 디자인 추가 및 수정하는 단계
- 개발(발전) : 설계단계에서 만들어진 설계서를 바탕으로 프로그램을 작성, 코딩, 디버깅, 단위/통합테스트 수행
- 테스트 : 발생할 수 있는 실행 프로그램 오류를 발견, 수정하는 단계
- 검토(피드백) : 기획 의도를 파악하고 시험 결과와 기획에 따라 수정할 부분을 제시하는 단계
애자일 방법론의 특징 #
- 고객과 개발자의 지속적인 소통을 통하여 변화하는 요구사항을 신속하게 수용한다.
- 개발자 개인의 가치보다는 팀의 목적을 우선시하며 고객의 의견을 가장 우선시한다.
- 팀원들과의 주기적인 회의 및 제품 시현을 통한 방지를 점검한다.
- 진행하면서 프로그램을 시행해보고 고객으로부터 피드백을 받는다.
- 내부 구조 형성을 통한 비용 절감에 힘쓰는 동시에 프로그램 품질 향상을 위해 노력한다.
애자일 방법론의 장점, 단점 #
장점 #
- 프로젝트 계획에 걸리는 시간을 최소화할 수 있다.
- 점진적으로 테스트할 수 있어서 버그를 쉽고 빠르게 발견할 수 있다.
- 계획 혹은 기능에 대한 수정과 변경에 유연하다.
- 고객 요구사항에 대한 즉각적인 피드백에 유연하며 프로토타입 모델을 빠르게 출시할 수 있다.
- 빠듯한 기한의 프로젝트를 빠르게 출시할 수 있다.
단점 #
- 확정되지 않은 계획 및 요구사항으로 인한 반복적인 유지보수 작업이 많다.
- 고객의 요구사항 및 계획이 크게 변경되면 모델이 무너질 수 있다.
- 개인이 아닌 팀이 중심이 되다 보니 공통으로 해야 할 작업이 많을 수 있다. (회의, 로그 등)
- 반복적인 업무로 속도는 빠를 수 있으나 미흡한 기능들에 대한 대처가 필요하다.
- 확정되지 않은 계획으로 개발 진행 시 이해하지 못하고 진행하는 부분이 많을 수 있다.
주요 애자일 방법론 #
Scrum #
- 스크럼(Scrum)은 프로젝트 관리를 위한 상호, 점진적 개발방법론이며, 뚱딴지일 방법론의 중심이 될 수 있는 효율적인 협업 방법이다. 스크럼(Scrum)은 고객의 요구사항을 충족시키는 데 초점을 맞추기 위해, 목표를 짧은 주기로 점진적이며 경험적으로 시스템을 지속해서 개발(전달)하는 관리 프레임워크(기법)이며 소프트웨어 개발 프로젝트들뿐만 아니라 소프트웨어 유지보수 팀이나 일반적인 프로젝트 관리에서도 적용될 수 있다.
Scrum의 5가지 추구가치 #
- 용기 : 팀의 목표가 올바른 길로 가기 위해 팀원 간 갈등을 두려워하지 말며 도전을 위한 용기를 가진다.
- 집중(전념) : 팀의 목표와 약속을 지키기 위해 모든 노력과 기술은 성공을 위해 집중하여야 한다.
- 확약 : 팀의 목표 달성을 위해 개인이 공약한 목표 달성을 위해 팀에 헌신하며 약속을 지켜야 한다.
- 존중 : 자신과 팀원들에게 경의를 표해야 한다. 개인의 다름을 이해해야 한다.
- 정직 : 자신에게 불리하더라고 팀을 위해 프로젝트에 대한 모든 내용을 투명하게 공개해야 한다.
XP(eXtreme Programming) #
- XP(eXtreme Programming)는 사용자의 요구사항을 한꺼번에 받는 방식이 아닌 반복형 모델의 개발 주기를 극단적으로 짧게 함으로써 프로그래머가 설계, 구현, 시험 활동을 전체 SW 개발 기간에 걸쳐 조금씩 자주 시행하도록 하는 방법이다.
XP의 특징 #
- 짧은 개발 주기를 가진다.
- 프로토타입이 일찍 자주 만들어진다.
- 개발계획이 프로젝트를 진행하는 동안 계속 변화된다.
XP의 4원칙 #
| 기본원칙 | 설명 |
|---|---|
| 의사소통 | 고객과 개발자와의 의사소통을 중요시 |
| 단순성 | 지금 해야 할 일에 대해서 가장 효율적인 것이 최선 |
| 피드백 | 즉각적인 피드백을 통해 빠르게 의사결정. XP는 항상 코드를 실행할 수 있는 상태로 유지 |
| 용기 | 개발자들이 자신감 있게 변화를 수용할 수 있도록 환경 조성. Spike, Small Release 등으로 고객 요구사항에 대응하는 용기가 필요 |
XP의 12가지 기본원리 #
| 기본원리 | 설명 |
|---|---|
| Planning Game | 개발계획 수립 고객과 다양한 스토리카드를 통한 개발계획 작성 |
| Small Release | 짧은 배포 주기 매우 짧은 주기로 모듈 업데이트 |
| Metaphor | 문장 형태로 시스템 아키텍처 기술 공통의 Naming System 개발 고객과 개발자 간 의사소통 언어 |
| Pair Programming | 개발자 2명의 공동 작업 |
| Continuous Integration | 지속적인 통합 작업이 끝날 때마다 지속해서 통합 및 테스트 |
| Simple Design | 단순 설계 현재의 비즈니스 가치에 집중 내일을 고려하는 디자인은 최대한 배제 Refactoring을 통해 개선 |
| Test | 항상 단위 테스트를 작성 테스트 수행 후 검증 코드로 작성 |
| Refactoring | 기능변화 없이 중복제거, 단순화, 유연성 추가 |
| 주 40시간 | 주 40시간 |
| On-Site Customer | 고객 상주 프로젝트팀에 고객이 상주하여 즉각적인 의사소통과 피드백 품질향상의 필수요소 |
| Coding Standard | 코드 표준을 통한 효과적인 의사소통 |
