애자일 방법론이란 구체적인 개발 프로세스가 아닌 개발 지침, 철학에 가깝다.
변화를 수용하고 협업과 제품의 빠른 인도를 강조하는 반복적 개발 방법이며 문서화 보다 코드, 프로그램, 소프트웨어 자체를 중요시한다.
요구사항의 변화는 불가피하며 이에 대응하는 것이 현실적이며 기존의 개발 프로세스는 설계 시간이 길며 재작업 시 오버헤드가 크다.
환경의 빠른 변화를 대응하는 것이 중요하다.
- 공정과 도구보다 개인과 상호작용을
- 포괄적인 문서보다 작동하는 소프트웨어를
- 계약 협상보다 고객과의 협력을
- 계획을 따르기보다 변화에 대응하기를
요구사항이 바뀌기 쉬운 중소형 비즈니스 시스템이나 전자 상거래 응용에 적합하다.
- 익스트림 프로그래밍 (Extreme Programming, XP)
- 짝 프로그래밍 (Pair Programming)
- 테스트 주도 개발 (Test Driven Development, TDD)
- 스크럼 (Scrum)
- 좋은 실천 지침들을 적극적으로 적용
- XP의 실천 지침
- 작고 빈번한 릴리즈 - 빠른 피드백과 지속적인 개선
- 고객도 개발 팀의 일원
- 프로세스 중심이 아닌 사람 중심의 작업
- 짝 프로그래밍
- 단순한 설계와 테스트 주도 개발
- 리팩토링을 통한 코드 품질 개선
- 두 사람이 짝이 되어 한 사람이 코딩, 한사람이 검사를 수행
- 30분마다 역할 교체
- 장점
- 코드에 대한 책임 공유
- 비형식적 검토 수행
- 코드 개선을 위한 리팩토링 장려
- 생산성 - 두 사람이 짝을 이뤄 개발하지만 각각 개발하는 경우에 비해 생산성이 떨어지지 않음
- 테스트 케이스를 먼저 작성하고 이를 통과하는 코드를 개발
- 테스크 별로 테스트 케이스를 만듦
- 요구사항 > 스토리 카드 > task
- 요구사항은 스토리카드로 표현되고 스토리 카드는 테스크들로 분해됨
- 요구사항 - 코드 관계가 명확해짐
- 통합 테스트를 강조하며 통합 과정에서 기존 스프트웨어에 오류 유입 방지
- 애자일 개발 과정에서 관리에 초점을 둔 프로젝트 관리 프레임워크/소프트웨어 개발 프로세스 프레임워크
- 계획 - 스프린트의 반복
- 프로젝트 계획 -> 제품 백로그: 우선순위가 부여된 요구사항 목록
- 스프린트 사이클
- 3 ~ 9 명의 스크럼 팀에서 제품의 증분을 개발하는 작은 프로젝트를 수행해 한 달 이내로 개발
- 스프린트 계획 -> 스프린트 백로그: 제품 백로그에서 이번 스프린트 사이클에 개발할 요구사항 목록을 선택
- 일일 스크럼 회의
- 진행중인 스프린트 사이클이 종료되기 전에 스프린트 리뷰, 회고 수행
- 스크럼 팀의 구성
- 개발 팀
- 제품 책임자: 제품 백로그 작성 및 관리
- 스크럼 마스터: 프로젝트 관리자, 회의 주관, 외부 소통 창고 역할