애자일은 고객의 요구에 민첩하게 대응하고 그때그때 주어지는 문제를 풀어 나가는 방법론을 의미한다. 따라서 가볍고 비교적 변화를 수용하기 쉬운 방법론이며 이스트림 프로그래밍, 스크럼, 크리스털과 같은 방법론이 있다.
애자일의 기본 가치
1. 프로세스와 도구 중심이 아닌 개개인과의 상호 소통을 중시한다
2. 문서 중심이 아닌, 실행 가능한 소프트웨어를 중시한다
3. 계약과 협상 중심이 아닌, 고객과의 협력을 중시한다
4. 계획 중심이 아닌, 변화에 대한 민첩한 대응을 중시한다
애자일 원칙
1. 최우선적인 목표는 고객을 만족시키기 위해 가치 있는 소프트웨어를 빨리, 지속적으로 제공하는 것이다
2. 개발 후반에 새로 추가되는 요구사항도 기꺼이 받아 들인다. 애자일 프로세스는 고객의 경쟁력을 위해 요구 사항의 변경을 받아 들인다.
3. 동작 가능한 소프트웨어를 짧으면 2주, 길면 2개월 간격으로 자주 고객에게 전달한다. 이때 간격을 짧을수록 좋다.
4. 프로젝트가 진행되는 동안에 업무 담당자와 개발자는 매일 서로 의견을 주고 받으며 함께 참여한다
5. 정보 전달을 위한 전화, 팩스, 인터넷 등 많은 매체 수단이 있으나 가장 효과적인 의사소통 방법은 역시 직접 만나 얼굴을 보면서 대화하는 것이다.
6. 진척 사항의 척도를 나타내는 방법은 여러 도구로 표현할 수 있으나 가장 좋은 방법은 실행 가능한 소프트웨어를 보여주는 것이다
7. 자율적 사고과 자유로운 분위기의 프로젝트 팀에서 최고의 아키텍처, 요구 사항, 설계가 나온다
8. 프로젝트의 효율성을 향상시키기 위해 개발 팀 스스로 정기적인 미팅을 진행해 자신들의 행동을 되돌아 보고 조율, 수정한다
애자일 개발 방법
애자일 개발 방법은 반복적인 개발을 통한 잦은 출시를 목표로 한다. 실행 가능한 프로토타입을 만들어서 사용자에게 확인 받고, 좀 더 빠른 시간 안에 일부이지만 소프트웨어를 사용할 수 있게 하는 것을 중요하게 생각한다.
스크럼(scrum)
스크럼 개발 프로세스는 소프트웨어 개발보다는 팀의 개선과 프로젝트 관리를 위한 애자일 방법론이다. 또 한 구체적인 프로세스를 명확히 제시하지 않는다.
스크럼 방식의 진행 과정
종합하자면 다음과 같은 진행 순서를 가진다
| 단계 | 수행 목록 | 내용 |
| 1. | 제품 기능 목록 작성 | 요구 사항 목록에 우선순위를 매겨 제품 기능 목록 작성 |
| 2 | 스프린트 계획 회의 | 스프린트 구련 목록 작성 |
| 스프린트 개발 시간 추정 | ||
| 3 | 스프린트 수행 | 스프린트 개발 |
| 일일 스크럼 회의 | ||
| 스프린트 현황판 변경 | ||
| 소멸 차트 표시 | ||
| 4 | 스프린트 개발 완료 | 실행 가능한 최종 제품 생산 |
| 5 | 스프린트 완료 후 | 스프린트 검토 회의 |
| 스프린트 회고 | ||
| 두 번째 스프린트 계획 회의 |
1. 제품 기능 목록(product backlog) 작성
제품 기능 목록은 일반적인 개발 방법의 요구 사항에서 기능 목록과 같다고 보면 된다. 이 요구사항들은 우선순위가 정해져 있으며 고객측 대표인 제품 책임자가 이를 결정한다. 한번 결정된 기능 목록은 개발 중에도 수정이 가능 하지만, 일반적으로 한 주기가 끝날때 까지는 제품 기능 목록을 수정하지 않는다.
| 순위 | 요구 사항 목록 | 요구 사항 내역 | 작업 소요 기간 | 직업 년, 월 |
실제 원고를 쓸때는 제품 기능 목록(원고의 각 장)을 10~40일 분량의 스프린트 구현 목록(sprint backlog)단위로 잘라서 스프린트(sprint)를 진행하여 원고를 쓴다. 이때 스프린트 기간이 같을 필요는 없다.
2. 사용자 스토리(user story)작성
사용자 스토리는 메모지 한 장에 쓰인 사용자 요구 사항이다. 구현할 기능이 사용자 관점에서 사용자 언어로 작성되 있다. 사용자 스토리는 다음과 같은 특징이 있다.
1. 제품 기능 목록에 정의된 사용자 관점에서의 기능이다.
2. 사용자에게 가치를 평가 받을 수 있도록 기능을 표현한 것이다.
3. 보통 작은 인덱스 카드를 사용해 필요한 것만 짧게 표현한다.
4. 고객의 요구 사항을 문서화한 것이 아닌 표현을 한것이다
5. 유스케이스보다 규모가 작다.
6. 사용자 스토리는 반복을 마치면 사라지지만 유스케이스는 개발 기나 동안 지속된다.
7. 사용자와 충분히 대화하여 세부 사항을 구체적으로 서술한다
8. 테스트를 통해 스토리가 완료된 것을 확인한다
9. 다른 스토리에 종속되지 않고 독립적이며 협상이 가능해야 한다
10. 추정, 측정 가능해야 한다
11. 사용자 스토리는 스토리가 큰 것보다는 많은 것이 좋다
12. 테스트가 가능해야 좋은 사용자 스토리 이다.
3. 스토리 포인트(story point) 산정
각각의 사용자 스토리는 우선순위, 수행하는데 걸리는 기간을 산정해야 한다. 이때 상대적인 개발 기간을 스토리 포인트라고 한다. 이때 스토리 포인트의 산정은 통상적으로 개발자들이 주도적으로 정한다. 우선순위를 매기는 일은 주로 업무 분석가가 한다.
4. 스프린트(sprint)
스프린트는 '전력질주'라는 의미이다. 따라서 작은 단위릐 개발 업무를 단기간에 전력질주하여 개발한다는 의미를 담고 있다. 소프트웨어 공학에서 원고를 10~40일에 한 장씩 반복해서 원고를 완성 한다면 스크럼에서는 한 장의 단위(10~40일)을 스프린트라 한다.
스크럼에서 반복 주기의 기간은 스프린트 계획 회의를 통해 결정 한다. 보통 2~4주 이며 애자일 방식에 대한 경험, 요구 사항 변화의 정도, 개발 팀의 역락을 통해 디테일한 기간을 정한다.
스프린트 주기가 결정 되면, 개발 팀은 팀원의 역량에 맞게 스프린트에 배전된 작업을 중간에 멈추지 않고 끝내야 한다. 그러면 결정된 스프린트의 목표와 내용이 개발 도중에 바뀌지 않아야 하며 그 누구도 팀원들의 동의 없이 바꿀 수 없다는 원칙을 지켜야 한다.
스크럼 마스터는 이때 외부에서 오는 개발 방해 요소를 차단해야 한다. 하나의 스프린트가 완료 되면 사용자에게 시연을 해야 하고 사용자는 피트백을 제공해야 한다. 만약 주어진 기간 내에 개발을 완료하지 못한다고 해도 하나의 스프린트는 정해진 일정이 끝나면 끝난다.
스크럼의 한 주기가 끝나면 실행 가능한 제품(shippable product)이 만들어 진다. 이 제품을 통해 목표가 완료되었는지 확인할 수 있다. 또 한 제품의 완성도를 단순 구현으로 할것인지, 버그 하나 없이 완벽할 정도의 높은 수준으로 할 것인지는 회의를 통해 결정된다.
5. 스프린트 구현 목록(spring backlog)
스프린트 구현 목록은 각각의 스프린트 주기에서 개발할 작업 목록을 의미한다. 작업 목록에는 다음과 같은 정보를 포함 한다
| 작업 목록 | 세부 작업 항목 | 예상 작업 시간 | 작업자 |
스프린트 구현 목록은 스프린트 계획 회의에서 결정 하며, 이작업 목록 하나하나가 개발 완료되면 스프린트 주기는 완료 된다.
6. 소멸 차트
소멸 차트는 시간이 지남에 따라 소멸되고 남은 것을 표현 하낟. 소멸 차트는 계획 대비 작업이 어떻게 진행되고 있는지를 날짜별로 남은 작업량으로 나타낸다. 소멸 차트를 보면 계획 대비 작업량이 실제 얼마나 줄고 있는지를 정량적으로 알 수 있고 기울기를 통해 작업 수행 속도를 알 수 있다.
1. 가로축: 시간 축으로 스프린트 반복 주기 날짜 수
2. 세로축: 완료된 작업의 추정 일수(스토리 포인트로 표현)
3. 계획 그래프: 처음 계획을 세웠을 떄 날짜 별로 남은 작업략(점선)
4. 실제 그래프: 작업을 수행하면서 날짜 별로 실제 남은 작업략(실선)
7. 스프린트 계획 회의(sprint planning meeting)
스프린트 계획은 스프린트 계획 회의를 통해 세운다. 스프린트 계획은 각 스프린트에 대한 목표를 세우는 일과 제품 기능 목록에서 어떤 항목을 스프린트에서 진행할지 선택하는 것이다. 그리고 선택된 각 항목에 대해 개발자는 배정하고 세부적인 작업 단위로 계획을 수립한다.
스프린트 계획 회의는 크게 두가지로 나위어져 있다.
1. 전체적인 스프린트 계획 회의:
스프린트 계획 회의 시작 단계에서는 사용자의 대변인 정되 되는 제품 책임자를 통해 사용자가 원하는 것이 무엇인지를 파악하는 데 중점을 둔다. 이를 위해 스크럼 마스터는 제품 기능 목록을 검토하면서 어떤 항목을 가장 높은 순위로 놓았는지에 관심을 갖고, 그 배경과 목표에 대해 팀원들과 토의하며 제품 책임자의 의도를 파악한다.
2. 세부적인 스프린트 계획 회의:
우선순위가 높은 항목을 어떻게 구현할 것인지 작업 계획을 세운다. 먼저 우선순위가 매겨진 사용자 요구 사항 목록인 제품 기능 목록에서 개발 항목을 결정하고 스프린트 구현 목록을 작성한다. 또 팀원들은 정해진 작업을 수행하는 데 소요되는 시간을 추정한다.
8. 일일 스크럼 회의(daily scrum meeting)
일일 스크럼 회의는 다음과 같은 특징이 있다.
1. 매일한다
2. 서서한다
3. 약속된 시간에 한다
4. 짧게(15분 정도)한다
5. 진행 상황만 점검한다
6. 스프린트 작업 목록을 잘 개발하고 있는지 확인한다
7. 모든 팀원이 참석한다
8. 한 사람씩 어제 한 일과 오늘 할 일을 예기한다
9. 한 사람 씩 문제점, 어려운 점을 예기한다
10. 매일 완료된 세부 작업 항목을 완료 상태로 옮겨 스프린트 현황판을 업데이트 한다.
11. 개별 팀원에 대한 진척 상태를 확인한다.
12. 그날의 남은 작업량을 소멸 차트에 표시한다.
일일 스트럼 회의에서 스크럼 마스터의 역할은 다음과 같다
1. 팀원들이 개발하는 데 방해되는 요소를 찾아 문제를 해결한다.
2. 개발자 개개인이 수행하고 있는 일의 진행 상황을 확인한다.
3. 소멸 차트에 그날의 남은 작업량을 표시한다.
9. 스프린트 현황판
개발 팀의 개발 현황(진척도, 남은 작업, 진행 속도, 완료된 작업)을 나타낸다.
10. 최종 제품(finished workd)
모든 스프린트 주기가 끝나면 제품 기능 목록에서 개발하려고 했던 제품이 완성 된다.
11. 스프린트 검토 회의(sprint review)
스프린트 검토 회의에서는 하나의 스프린트 반복 주기가 끝났을 때 생성되는 실행 가능한 제품에 대해 검토한다. 스프린트 목표를 달성 했는지 작업 진행과 결과물을 확인하고, 전체 흐름을 확인해 비즈니스 가치를 점검하는 제 중점을 둔다.
스크럼 팀은 스프린트 동안 작업한 결과를 참석자들에게 시연하고 요구 사항에 얼마나 부합하는지 검토한다. 그리고 개선할 점 등에 관해 피드백을 받는다. 이때, 스크럼 마스터는 스프린트 동안 잘된 덤, 아쉬운 점, 개선할 사항 등을 찾기 위한 회고를 신행할 수 있다. 검토는 가능한 4시간 안에 끝내야 한다.
12. 스프린트 회고(sprint retrospective)
그동안 스프린트에서 수행한 활동과 개발한 것을 되돌아 보고, 개선점, 정한 규칙 준수여부 등을 검토한다. 여기서 팀의 강점을 찾아 극대화 하는데에 집중하며 문제점에 대한 해결 방안은 기록 정도만 한다. 그리고 추정 속도와 실제 속도를 비교하고 차이가 크다면 그 이유를 분석한다. 하지만 프로세스 품질을 측정하지 않는다.
13. 배포 목록(release backing)
배포는 사용자에게 시스템 일부를 제공하는 것이다. 그리고 배포 목록은 제품 기능 목록의 항목 중에서 이번 배포 본에 포함하기로 결정한 항목을 말한다. 따라서 배포 목록을 작성하면 이번 배포 본의 개발 범위와 일정을 수립할 수 있다. 또 사용자에게 전달되는 배포 본의 기능 내역과 시기, 스프린트 주기, 배포 일정을 결정하게 된다.
EX).책을 출판 하는데 원고를 장 별로 넘기기로 했다면 배포 목록은 다음과 같은 항목을 가지고 있다
| 장 | 내역 | 작업 기간 | 스프린트 주기 |
| 1장 | n일 | 스프린트 1 | |
| 총 남은 기간 | n일 | ||
| 배포 스프린트 | 총 1스프린트 | ||
| 배포 날짜 | yyyy년mm월dd일 | ||