[애자일] 애자일 개발 방법론

개발을 하는 주체들이 이해하고 효율적으로 사용할 수 있는 방법론이 대두하기 시작하고 있다. 이를 실용주의 방법론(Practical Methodology)이라고 한다.

■ 실용주의 방법론 특징

1. 변화를 수용한다.
2. 개발 과정을 짧은 조각(Iteration)으로 나눠서 반복적(Interative)으로 개발한다.
3. 소프트웨어 결함이 있음을 전제로 한다.
4. 문서 작업을 최소화한다.
5. 협업과 커뮤니케이션에 많은 비중을 할애한다.
6. 자동화 도구를 사용한다.

실용주의 방법론에서 소프트웨어 개발 프로세스는 애자일을 바탕으로 구성되는데, 구성원 간의 협업(Collaboration)을 중요시하는 사상을 가지고 있다.

애자일 방법론에는 XP(Extrem Programming), AUP(Agile Unified Process, Scrum, Lean 등 여러가지 구체적인 방법로늘이 있는데 근래에는 스크럽이 가장 인기있고 많이 사용되고 있다.

■ 스크럼(Scrum)

스크럼은 기본적으로 반복과 점진적(Iterative and Incremental) 개발 방법에 기초한다.

※ 용어 정리

스프린트 

스크럼은 몇 개의 이터레이션으로 구성되는데, 이 이터레이션을 스프린트라고 부르며 각 스프린트는 1~4주 정도의 기간을 갖는다. 스프린트는 일종의 타임 박스의 개념을 가지며 한번 정해진 스프린트의 기간은 변경될 수 없다는 것을 전제로 한다.

제품 백로그 (Product Backlog)

고객의 요건으로부터 작성, "대략적인 할 일 목록", 구현 단계에서는 SRS(요구사항 정의서)나 TRS(기술요구사항 정의서)에 정의된 기능이나 구현 요구사항이 제품 백로그의 항목으로 적절하다.

백로그 항목을 팀 미팅을 통해서 이번 스프린트에 수행할 항목으로 선택하고 우선순위를 통해서 선택이 된다. 이러한 항목들은 구체적으로 구현하기 위해서 Task로 쪼게 진다. Task 목록을 리스트를 스프린트 백로그(Sprint Backlog)라고 부른다.

스크럼 미팅 (Daily Scrum)

스프린트 중에 매일 아침 팀원들은 10~20분 정도의 일일 미팅을 하는데 이 시간 동안, 팀원들은 어제 한일과 오늘 한 일에 대해서 간략하게 보고하고, 현재 Task에 대한 문제점을 공유한다. 이것이 스크럼 미팅이다.

스프린트가 끝나면 소프트웨어를 릴리즈하고, 이후에 프로젝트의 이해 당사자(Stake hlder/고객)과 미팅을 갖고 , 스프린트 구현 내용을 간단히 데모로 소개 및 피드백을 받아서 제품 백로그에 업데이트 한 뒤 다시 스프린트를 준비한다.

리뷰가 끝난 후에는 팀원끼리 스프린트에 대한 회고(Retrospective)의 시간을 갖는데, 잘되었던 점과 잘못된 점을 토론하여 스크럼 운영 프로세스에 반영하여 팀의 스크럼 운영 방식을 성숙화 시킨다.

■ 에픽(Epric) 과 사용자 스토리 (User Story)

근래의 스크럼 방법론은 에픽과 사용자 스토리라는 개념을 사용한다.

사용자 스토리 (User Story)

요구 사항, 예를들어, '나는 사용자로서 사진을 업로드 하고 싶다.' 라는 식으로 액터(Actor, 사용자)와 액터의 행위를 서술하는 형태가 된다. 기존의 유스 케이스 다이어그램의 액터와 유스 케이스의 개념과 유사하다.

* Task : 사용자 스토리를 구현 하기 위해 하위 태스크로 나눠지는데 이를 Task라고 정의한다.

• 사진 업로드 모듈 개발
• 사진을 디스크에 저장하는 모듈 개발
• 사진 메타 정보를 데이터베이스에 저장하는 모듈 개발

에픽 (Erpic)

위의 사용자 스토리를 사용할 경우, 수백 가지의 사용자 스토리가 정의될 수 있는데, 이러한 사용자 스토리를 큰 단위로 묶어 놓은 것을 에픽 이라고 한다. 예를들어, '사진 업로드', '사진 리스트'

■ 스프린트 계획

스프린트는 보통 1~4주 정도로 정의되는데 고객의 요구 사항 변경이나 작업에 대한 변경도, 예측된 작업 일정이 충분한지와 같이 불확실성이 높을수록 주기를 짧게 잡는 것이 좋고, 그렇지 않은 경우 길게 잡는 것이 좋다. 일반적으로 2주 정도가 가장 효과 적이다.

◆ 스프린트 계획 절차

• 제품 백로그의 항목을 구체적인 태스크로 분할
• 각 태스크를 프로젝트 리더인 스크럼 마스터가 적절한 사람에게 배분
• 배분된 사람이 태스크의 수행 시간을 예측하도록 함

태스크는 명확한 종결 조건을 가지고 있어야 한다. 정해진 종결 조건을 정의하게 되면 태스크를 관리하기가 용이하다.

■ WBS(Work Breakdown Structure)

전통적인 스크럼 방식은 백로그에 앞으로 해야 할 일만을 정의한다. 이를 통해서 앞으로 해야 할 일과 완료된 일에 대한 추적성을 부여할 수 있지만, 앞으로 해야 할 일과 진행되고 있는 일이 언제 시작해서 언제 끝날 것인지에 대한 관리가 어렵다. 이를 해결 하기 위해 태스크별로, 시작일과 종료일을 지정하는 일종의 WBS의 개념을 사용해서 진행하는 일과 앞으로 해야 하는 일의 일정을 추적할 수 있다.

■ 스크럼 보드 (Agile Board or Scrum Board)

• 해야 할일 (To Do or Backlog) , 진행 중인 일 (In Progress), 완료된 일 (Done or Completed)로 나눠서 각 일(이슈)을 포스트 잇으로 만든 후, 진행 단계에 따라서 각 단계로 포스트잇을 이동해서 붙이는 방법