애자일(Agile)
업데이트:
카테고리: CS, Software Engineering
애자일 Agile
나는 애자일이 무슨 프로그래밍 언어인 줄 알았다. 그러나 그게 아니라 어떤 개발 방법론 같은 것이었다.
등장 배경
초기에 소프트웨어 개발은 소수의 개발자에 의한 계획 중심의 프로세스 였다. 예를 들면, 프로젝트 시작부터 최종단계까지 전부 계획하고 진행하는 것이다.
그러나 점차 기술이 발전하면서, 많은 사랃믈이 소프트웨어를 개발하게 되었고, 트렌드가 급격히 변하면서 비지니스 사이클이 짧아지고, SW개발의 불확실성이 증가했다.
그래서 경량 방법론 주의자들이 “일단 해보고 고치자”라는 방식을 사용해 개발을 했고, 자신들의 개발론들의 공통점을 추려 애자일이라는 용어에 의미가 담기게 되었다고 한다.
애자일이란?
애자일의 핵심 단어는 협력과 피드백이고, 이것을 더 자주, 일찍, 잘하는게 목표다.
협력
말 그대로, 내가 느낀 것을 동료들에게 공유하거나, 모르는 것을 공유해 더 빠르고 효율적으로 개발에 나서는 것이다.
피드백
내가 어떻게 하고 있는지 항상 피드백하며 일을 진행해야한다. 소프트웨어의 불확실성이 높을 수록 스스로가 더 많이 배워야하기 때문이다. 그리고 결과물을 갖고 고객들의 평가를 받아 피드백을해 더 좋은 결과물을 만들도록 해야한다.
불확실성
팀에서 예상했던 것과 다른 결과물이 나올 수 있다. 이런 것을 불확실성이라 얘기한다. 애자일 방법론은 그때 그때 문제가 발생하거나 수정해야할 일이 생기면, 그 즉시 수정하고 더 좋은 방법론을 찾는 것을 주장한다.
이런 방법론은 개발 과정에 있어서 시스템 변경사항을 유연하거나 기민하게 대응할 수 있도록 해준다.
진행 방법 (스크럼 형식)
- 제품 기능 목록 작성
고객의 요구에 따른 개발할 제품에 대한 목록 작성한다. 일반적으론 한 주기가 끝날 때까지는 제품 기능 목록을 수정하지 않는다.
개발자와 고객 사이의 지속적 커뮤니케이션을 통해 변화하는 요구사항을 수용한다.
- 스프린트 Backlog
스프린트 각각의 목표에 도달하기 위해 필요한 작업 목록을 작성한다.- 세부적으로 어떤 것을 구현해야 하는지
- 작업자
- 예상 작업 시간
최종적으로 개발이 어떻게 진행되고 있는지 상황 파악 가능해진다.
- 스프린트
한달동안의 큰 계획에서 3~5일 단위로 반복 주기를 정했다면 이것이 스크럼에서 스프린트에 해당한다.
주기가 회의를 통해 결정되면 (보통 2주 ~ 4주) 목표와 내용이 개발 도중에 바뀌지 않아야 하고, 팀원들 동의 없이 바꿀 수 없는 것이 원칙이다.작은 단위의 개발 업무를 단기간 내에 전력질주하여 개발한다. 일단 만들고 본다!!
- 일일 스크럼 회의
모든 팀원이 참석하여 매일하고, 짧게(15분)하고, 진행 상황 점검한다.
한사람씩 어제 한 일, 오늘 할 일, 문제점 및 어려운 점을 이야기한다.
완료된 세부 작업 항목을 스프린트 현황판에서 업데이트 시킨다.팀원들과 주기적인 미팅을 통해 프로젝트를 점검한다.
- 제품완성 및 스프린트 검토 회의
모든 스프린트 주기가 끝나면, 제품 기능 목록에서 작성한 제품이 완성된다. 최종 제품이 나오면 고객들 앞에서 시연을 통한 스프린트 검토 회의 진행한다.- 고객의 요구사항에 얼마나 부합했는가?
- 개선점 및 피드백
주기적으로 제품 시현을 하고 고객으로부터 피드백을 받는다.
- 스프린트 회고
스프린트에서 수행한 활동과 개발한 것을 되돌아보며 개선점이나 규칙 및 표준을 잘 준수했는지 검토한다.
팀의 단점보다는 강점과 장점을 찾아 더 극대화하는데 초점을 둔다
스크럼 장점
- 스프린트마다 생산되는 실행 가능한 제품을 통해 사용자와 의견을 나눌 수 있음
- 회의를 통해 팀원들간 신속한 협조와 조율이 가능
- 자신의 일정을 직접 발표함으로써 업무 집중 환경 조성
- 프로젝트 진행 현황을 통해 신속하게 목표와 결과 추정이 가능하며 변화 시도가 용이함
스크럼 단점
- 추가 작업 시간이 필요함 (스프린트마다 테스트 제품을 만들어야하기 때문)
- 15분이라는 회의 시간을 지키기 힘듬 ( 시간이 초과되면 그만큼 작업 시간이 줄어듬)
- 스크럼은 프로젝트 관리에 무게중심을 두기 때문에 프로세스 품질 평가에는 미약함
요약
스크럼 모델은 애자일 개발 방법론 중 하나이다. 회의를 통해 스프린트 개발 주기를 정한 뒤, 이 주기마다 회의 때 정했던 계획들을 구현해나간다. 하나의 스프린트가 끝날 때마다 검토 회의를 통해, 생산되는 프로토타입으로 사용자들의 피드백을 받으며 더 나은 결과물을 구현해낼 수 있다.