애자일 방법론이란 유저의 요구 사항과 피드백을 기반으로 진행되는 반복적, 점진적 소프트웨어 개발 방법론이다.
전통적인 Waterfall Model의 반대급부로 설명되며, 근래의 보편화된 개발 방식이다.
특징
Agile을 한 문장으로 정리하려 하면 상당히 추상적이고 복잡해진다.
단어를 하나씩 풀어서 살펴보자.
Iterative
소프트웨어 개발 사이클은 일반적으로 아래의 단계를 따른다.
- 유저의 요구 사항 분석 (Requirements analysis)
- 코드 구조를 설계 (Design)
- 실제 코드로 구현 (Implement)
- 테스트 (Testing)
- Maintenance (유지보수)
전통적으로 사용되던 WaterFall Process에선 위 과정을 한번씩 진행한다.
직관적으로 이해하기 쉽고, 관리자 측면에서 진행도를 조율하기 적절하다.
다만 몇가지 치명적인 문제가 있다.
먼저, 만약 문제가 생겨서 이전 단계로 돌아가야 할 때 큰 비용이 발생한다.
예시로 구현을 절반 정도 마친 상태에서 설계에 부족한 부분을 감지했다면?
이미 일정의 절반을 지나친 시점인데 설계를 다시하고 이에 맞춰서 코드를 고쳐야 한다.
이러한 cost 문제 때문에 자연스레 WaterFall process에선 loop back을 꺼리게 된다.
그런데 loop back을 하지 않기 때문에 또 다른 문제가 발생한다.
요구 사항이 변경되는 상황에서 이를 반영하기 어려워지고, 모든 기능을 철저히 설계해야 하기 때문에 설계 과정이 복잡하고 길어진다. 완성 단계에선 추가적인 피드백이 발생하더라도 반영하기 까다롭다.
단적으로 말해서 유연하지 못하다.
특히 요구사항과 환경이 급변하는 근래의 시장에서 이러한 경직성은 치명적이다.
애자일 방법론에선 위 개발 사이클을 반복하면서 점진적으로 소프트웨어를 완성한다.
한번의 사이클은 스프린트라 부르며 약 2~3주 정도의 주간동안 짧게 실행된다.
한번의 스프린트 동안 모든 요구 사항을 처리할 필요는 없고, 점진적으로 처리하면 된다.
이렇게 되면 소프트웨어도 점진적으로 완성되게 된다.
위와 같은 Iterative 개발에서 얻는 장점은 무엇일까?
물론 유연성이다.
특히 유저의 피드백을 받는 단계를 추가할 수 있기에, 요구 사항에 대한 반영이 아주 강하게 실현된다.
스프린트의 반복을 통해 기능 단위로 시스템을 확장하는 것이 Agile 방법론의 핵심이라 볼 수 있다.
Use-Case Driven
애자일 방법론은 유저 요구사항과 피드백을 중심으로 실행된다.
기능 개발의 단위를 Use Case (사용자 시나리오)로 잡고 실제 사용 흐름을 기준으로 구현한다.
이에 따른 장점은 다음과 같다.
1. 오버 엔지니어링 방지
고객의 실제 사용 사례를 기반으로 진행하기 때문에, 불필요한 기능이 개발되는 상황을 방지한다.
2. 테스트 케이스 도출 용이
User scenario를 기반으로 테스트 케이스를 생성할 수 있다.
TDD 방법론을 도입할 때 매우 도움이 된다.
3. 고객과의 협업
소프트웨어에 고객의 요구 사항을 강하게 반영할 수 있다.
Architecture-Centric
시스템이 커질수록 단단한 구조가 뒷받침해줘야 유지보수와 확장성에서 문제가 안생긴다.
Agile에선 처음부터 전체 아키텍처를 완벽히 설계하지 않는다.
다만, 중요한 아키텍처적 결정은 가급적 초기부터 고려한다.
가령 계층 구조, 모듈화, 의존성 관리, 확장성 고려 등의 사항은 초기에 미리 설계한다.
실행 방법
BackLog
백로그는 구현할 기능의 목록이다.
각 스프린트 마다 백로그의 항목 중 선택하여 구현에 나선다.
보통 사안의 중요도와 시급함에 따라 선택된다.
백로그에 남은 급하지 않은 사항에 대해선 스프린트 중간의 정비 기간에 처리하기도 한다.
Sprint
Agile의 주된 사이클. 약 2~3주 동안 짧게 진행된다.
진행과정 프로세스는 대략 8단계로 분류된다
1. 기획
- 사업성 반영
- Product Owner(이하 PO) 주도로 진행
- 기획문서(PRD) 작성 -> 팀 전체 확인 -> 컨펌 여부 결정
- 컨펌 후에는 상세 기획에 들어간다
2. 디자인
- 디자인 시안 작성
- PO는 디자이너와 꾸준히 소통한다
3. 개발
- 기능을 Task 단위로 세분화 한다 (원자성 명제)
- 분배하여 개발을 진행
- 버전 관리 도구(Git), 단위 테스트(TDD), Task 관리 툴(JIRA) 사용이 권장된다.
- 서버, 클라이언트 등 각 사이드의 개발 진행
4. 데모
- 기능 데모
- 피드백을 받는다
5. 피드백 반영
- 짧은 수정 시간을 가진다
6. QA(Quality Assurance)
- 모든 기능을 나열한다
- 기능은 세분화되어야 한다 (원자성 명제)
- 기대한 구현 모습(기대 효과)를 작성한다
- 실현 여부를 파악한다
- 실패한 기능은 추후 재시도 한다
7. 실서버 배포
- 결과를 배포한다
- 모니터링
8. 회고
- 스프린트에 대한 내부 평가를 진행
- 시비를 가리는 목적이 아님에 유의
각 스프린트에는 주제와 구현의 목표점을 잡고 진행한다.
스프린트는 여러 개가 동시에 진행될 수 있다.
가령 n번 스프린트가 데모 단계 일 때, (n+1) 번 스프린트의 기획을 시작할 수도 있다.
각 스프린트의 주된 진행자가 개발자, 기획자 로 다르기 때문에 가능하다.
스크럼
스크럼은 매일 10~15분 정도 짧게 진행되는 팀 회의다.
각 팀원들이 간단하게 서로의 진행 상황을 공유하려는 목적을 가진다
업무는 혼자 진행하는 업무, 팀원과 함께 하는 업무로 구분할 수 있다.
후자의 경우, 반드시 팀차원의 협업과 스케쥴 조율이 필요하다.
스크럼에선 이를 위한 지속적인 소통을 목적으로 한다.
주요 안건
- 개발 과정에서 생긴 이슈 공유, 제안
- 현재 작업 현황
- 오늘의 개발 계획
- 협업해야 하는 사항
스크럼은 개발자 간 스크럼 혹은 전체 팀원 스크럼을 진행할 수 있다.
유용한 툴
JIRA
Agile 기반 Task 관리 툴
하나의 작업, 기능을 티켓으로 관리한다.
티켓은 각 스프린트에 유동적으로 배치할 수 있다.
스프린트에 속하지 않은 티켓은 백로그로 분류된다.
티켓 간의 연결 기능을 지원하여, 자신이 할 일과 관련된 정보를 쉽게 확인할 수 있다.
GitHub Actions
GitHub 저장소에 자동화 워크플로우(CI/CD)를 설정할 수 있게 해주는 기능이다
코드를 Push/PR 할 때 자동으로 테스트, 빌드, 배포 등을 수행한다.
GitHub 서버 또는 자체 호스팅 머신에서 실행 가능하다
참조
이XX 교수님의 소프트웨어공학 강의
