[Reference] 애자일 방법론
애자일 방법론이란?
- 애자일 방법론 이란, ‘Agile = 기민한, 날렵한’ 이란 뜻으로 좋은 것을 빠르게 취하고, 낭비 없게 만드는 다양한 방법론을 통칭해 일컫는 말이다. 앞을 예측하며 개발하지 않고, 일정한 주기를 가지고 계속 검토해 나가며 필요할 때마다 요구사항을 더하고 수정하여 커다랗게 살을 붙이면서 개발해 프로세스 모델 방식이다. 미리 정해진 몇 개의 단계에 따라 엄격한 순서대로 이루어지는 일직선의 과정인 폭포수의 프로세스와는 비교가 많이되는 반대의 개념이다.
애자일 방법론의 진행 과정
- 애자일 방법론은 계획 → 설계(디자인) → 개발(발전) → 테스트 → 검토(피드백) 순으로 반복적으로 진행된다. 계획을 세운 후 다음 단계까지 기다려서 절차대로 진행하는 폭포수 모델과 달리 먼저 진행 후 분석, 시험, 피드백을 통하여 개선하여 나가는 진행 모델이다.
- 계획 및 분석 : 고객과 사용자가 원하는 바를 파악하여 타당성을 조사하고 SW 기능과 제약조건을 정의하는 명세서 작성, 대상이 되는 문제 영역과 사용자가 원하는 task를 이해하는 단계
- 설계(디자인) : 기획의도에 맞는 설계 및 디자인 추가 및 수정하는 단계
- 개발(발전) : 설계단계에서 만들어진 설계서를 바탕으로 프로그램을 작성, 코딩, 디버깅, 단위/통합테스트 수행
- 테스트 : 발생 가능한 실행 프로그램 오류를 발견, 수정하는 단계
- 검토(피드백) : 기획의도를 파악하고 시험결과와 기획의 따라 수정할 부분을 제시하는 단계
애자일 방법론의 특징
- 고객과 개발자의 지속적인 소통을 통하여 변화하는 요구사항을 신속하게 수용한다.
- 개발자 개인의 가치보다는 팀의 목적을 우선시하며 고객의 의견을 가장 우선시한다.
- 팀원들과의 주기적인 회의 및 제품 시현을 통한 방지를 점검한다.
- 진행하면서 프로그램을 시행해보고 고객으로부터 피드백을 받는다.
- 내부 구조 형성을 통한 비용절감에 힘쓰는 동시에 프로그램 품질 향상을 위해 노력한다.
애자일 방법론의 장점, 단점
장점
- 프로젝트 계획에 걸리는 시간을 최소화할 수 있다.
- 점진적으로 테스트할 수 있어서 버그를 쉽고 빠르게 발견할 수 있다.
- 계획 혹은 기능에 대한 수정과 변경에 유연하다.
- 고객 요구사항에 대한 즉각적인 피드백에 유연하며 프로토타입 모델을 빠르게 출시할 수 있다.
- 빠듯한 기한의 프로젝트를 빠르게 출시할 수 있다.
단점
- 확정되지 않은 계획 및 요구사항으로 인한 반복적인 유지보수 작업이 많다.
- 고객의 요구사항 및 계획이 크게 변경될 경우 모델이 무너질 수 있다.
- 개인이 아닌 팀이 중심이 되다 보니 공통으로 해야 할 작업들이 많을 수 있다. (회의, 로그 등)
- 반복적인 업무로 속도는 빠를 수 있으나 미흡한 기능들에 대한 대처가 필요하다.
- 확정되지 않은 계획으로 개발 진행 시 이해하지 못하고 진행하는 부분이 많을 수 있다.
애자일 프레임워크 도구
1. Scrum
정의
- 개발 주기마다 적용할 기능이나 개선에 대한 목록 작성 (Backlog 작성)
- 신규 기능, 기존 로직 개선점 ( 즉 할일 ) 등에 우선 순위 부여
- 개발 주기는 30일 정도로 조절하고, 개발 주기마다 실제 동작하는 결과 제공
- 일일 15분 정도의 회의
- 항상 팀 단위로 사고
- 원할한 의사소통
추가 사항
- 조직을 작게 만들며, 자기조직적인 팀(스스로 지원해서 조직되는 팀)이면 더 좋음.
- 개발 사항은 1~2시간 단위로 가능한 작은 단위로 만드는 것이 좋음.
- Sprint 결과를 리포트, 회고
Scrum 프로세스 요소
제품 백로그 ( Product backlog ) 요구사항 목록
스프린트( Sprint ) Iteration 주기
스프린트 계획 회의 ( Sprint Planning Meeting ) Iteration 안에서 백로그로부터 대상 선정, 개발, 사용자 테스트 시점을 협의 결과물에 대한 Iteration 완료시 모습 결정하고, 수행에 필요한 각종 요구사항을 Scrum Master 에게 보고하여 지원받도록 함.
스프린트 백로그 ( Sprint Backlog ) 스프린트 계획회의를 통해 정리된 작업의 목록
일일 스크럼 회의 ( Daily Scrum Meeting ) 스프린트 백로그에서 오늘 완료한 목록을 팀원들과 공유하고 목록에서 삭제하는 절차
실행 가능한 제품 개발 ( Shippable Product ) 일일 스크럼 회의를 통해 완료되는 목록을 만들기 위해 작업 목록의 크기는 최장 4시간 내로 완료가능한 수준으로 세분화.
제품 책임자 ( Product Owner ) 프로젝트 관리자, Product Backlog 를 정의하며, 우선순위를 결정하는 사람 이해관계자로부터 프로젝트 지원을 받아내는 역할도 큼.
스크럼 마스터 ( Scrum Master ) 스크럼 팀원들에 대한 코칭의 역할이 강조됨.
실무자(개발자)의 구체적 적용 방법
매일 아침 10~15분 가량 익일과 금일에 대한 각자의 진행 업무에 대한 스탠딩 미팅을 한다. 이는 Project Owner 가 주도한다. HotFix, 우선순위 변경, 문제 사항 확인, Bottleneck 확인 등을 한다. 변경된 요구사항 등도 확인한다.
포스트잇으로 Backlog ( task ) 를 관리한다. 화이트 보드에 TODO, Doing, Done 섹션으로 나눈다. (다른 형태 혹은 세분화된 형태도 가능) 일을 작은 조각으로 나누고, 포스트잇에 각 항목을 기입하여 벽에 붙인다. 포스트잇들을 상태에 따라 섹션에 부착한다. 각 포스트잇에는 일정(Man day)를 기입하라. 해당 항목을 완료하는 데 소요된 평균 시간을 측정하고 기입하라.
화이트 보드의 한편에는 스프린트 목표에 대한 그래프와 예외사항 섹션을 작성한다. 전체적인 일정 관리를 알기 위해 시간(x축), Manday(y축) 을 구성하는 그래프를 추가한다. 계획에 없던 추가된 일과, 다음으로 미뤄야 하는 일 등에 대한 섹션을 두어 예외사항을 관리한다.
2. Kanban
3. XP(익스트림 프로그래밍 , eXtreme Programing)
정의
- 10~12개 정도의 구체적인 실천 방법(Practice)을 정의
- 짧은 주기로 여러번 고객에게 납품 반복
- 개발문서 보다는 소스코드를, 조직적인 개발 보다는 개개인의 책임과 용기를 중시
- 다만 대규모 프로젝트엔 적용하기 어렵고, 개인의 습관-실력에 따라 프로젝트 품질차이 발생
실무자(개발자)의 구체적 적용 방법
- User Stories, 유저 스토리 (요구사항 정리)
- 사용자 요구사항 / UML의 유스케이스와 같은 목적(요구사항 수집, 의사소통 도구)
- 릴리즈 계획을 작성하기 위한 단위
- 기능단위로 필요한 내용을 간단하게 기재, 필요시 간단한 테스트 사항도 표기 가능
- 시스템을 사용하는 고객이 필요한 것이 무엇인지를 기술 → 인수테스트시 사용
- Release Planning, 릴리즈 계획 잡기
- 전체 프로젝트에 대한 배포 계획을 생성
- Iteration, 반복
- 하나의 반복을 1에서 3주 정도로 나누고 반복들을 프로젝트 전반에 균일하게 유지
- XP의 반복은 프로세스의 평가와 계획을 단순하고 신뢰성 있게 만드는 핵심 항목 → 반복 계획 미팅
- 사용자 요구사항 변경, 기술적인 문제 등 상황에 따라 릴리즈 및 반복 계획 수정 가능
- Acceptance Test, 인수 테스트
- 릴리즈 전의 인수 테스트. 고객이 실제 사용자 환경에서 사용자의 입장으로 테스트를 수행
- Small Release, 소규모 릴리즈
- 작은 배포는 XP 주기의 마지막 단계
- 소규모로 빈번하게 배포하면 고객에게 여러 가지 이득을 조기 제공
- 프로그램은 빠른 피드백을 제공 받음
