애자일 선언문

소프트웨어를 개발하면서, 그리고 또한 다른 사람의 개발을 도와주면서 소프트웨어를 개발하는 더 나은 방법들을 찾아나가고 있다. 이 작업을 통해 다음과 같은 가치를 추구하게 되었다. 프로세스나 도구 보다는 개인과 상호 작용을, 포괄적인 문서보다는 작동하는 소프트웨어를, 계약에 대한 협상보다는 고객과의 협력을, 계획을 고수하기 보다는 변화에 대응 을 더욱 가치 있게 여긴다.

애자일 방법론

애자일 선언문이 나온 이후로 다양한 애자일 방법론이 등장하게 된다. 하지만 그 기반에는 공통적으로 ‘신뢰성 높은 소프트웨어를 빨리 개발하자.’는 가치를 공유하고 있다. 아래는 애자일 개발 방법의 이름과 그 방법론을 정의한 사람의 목록이다.

1. 스크럼(Scrum), 켄 슈와버/제프 서덜랜드
2. 적응형 소프트웨어 개발 방법론(ASD), 짐 하 이스미스
3. 기능 주도 개발방법론(FDD), 피터 코드/제프 드루카
4. 동적 시스템 개발 방법론(DSDM), 데 인 포크너 외
5. 크리스탈 패밀리(Crystal Family), 앨리스테어 코번
6. 익스트림 프로그래밍(eXtreme Programing, XP), 켄트 벡/에릭 감마
7. 린(Lean) 소프트웨어 개발방법론, 메리 포펜딕/톰 포펜딕
8. 애자일 UP(Agile Unified Process, AUP), 스콧 앰블러

이 중에서 특히 세계적으로 널리 채택된 애자일 방법론은 스크럼과 익스트림 프로그래밍 (XP)이다. 초기에는 XP를 주로 사용했지만 스크럼이 점점 많은 인기를 끌면서 현재는 스크럼과 XP 를 같이 사용하는 게 일반적인 추세이다. 그 외, 동적 시스템 개발 방법론은 문서화가 잘된 애자일 방법론으로서 주로 유럽 회사의 컨소시엄에서 시작한 방법론이며 린 소프트웨어 개발 방법론은 1980년대 도요타 시스템의 린 생산방식을 소프트웨어 개발 에 적용하자는 운동으로 최근 스크럼과 함께 많이 사용되는 방식이다.

애자일 방법론의 특징

다양한 애자일 방법론을 공통된 부문만을 모아보면 ‘애자일 개발’이라 부르는 소프트웨어 개발 방식이 가지는 특징을 찾을 수 있다. 애자일 소프트웨어 개발은 반복적이고 점진적인 개발을 기본 스타일로 가진다. 그리고 이런 스타일의 개발방식을 효과적으로 진행하기 위해 자기 조직화나 교차 기능팀 등의 기법들을 활용하고 있다.

이런 방법론이 제시하는 실천법은 애자일 선언문의 가치와 원칙을 실현하는 과정에서 나온 것이다. 방법론이 지향하는 바를 제대로 이해하기 위해서는 애자일 선언문의 가치와 원칙을 먼저 숙지할 필요가 있다.

애자일 방법론과 전통 방법론의 차이

폭포수 방법론과 애자일 방법론 간의 주요 차이점을 통해서 애자일의 특징에 대해 자세히 알아보자.

(1) 고객중심의 애자일

폭포수 방법론은 프로젝트를 시작하기 전에 프로젝트 기간 전체에 대한 일정 계획을 수립하며, 이 계획에 따라 프로젝트를 진행한다. 애자일 방법론은 계획을 수립하되 불확실한 프로젝트 기간 전체를 감안하여 무리하거나 현실성 없는 계획을 수립하는 것이 아니라 현재 시점에 고객에게 중요하거나 확정된 내용을 중심적으로 수립한다. 프로젝트 상황에 따라 프로젝트 계획은 변경될 수 있다는 사실을 인정하고 진행한다. 그래서 계획보다는 고객이 중요하게 생각하는 기능을 먼저 개발하는 것을 원칙으로 한다.

(2) 작은 릴리즈를 가지는 애자일

형태적으로 보았을 때, 폭포수 방법론이 프로젝트가 종료되는 시점에 한꺼번에 모든 기능을 릴리즈 한다고 한다면 애자일 방법론은 이터레이션이라는 일정 기간 단위로 작은 규모 크기의 릴리즈를 반복한다. 이렇게 하면 고객은 요구사항이 제대로 반영되 고 있는지 조기에 확인할 수 있어서 개발이 모두 끝난 다음에야 비로소 요구사항에 맞지 않다고 이야기하고, 결국 재개발하게 되는 경우를 방지 할 수 있다.

(3) 동작하는 SW 중심인 애자일

폭포수 방법론에서는 계획된 단계별로 지정된 산출물이 작성되었는지 여부를 확인함으로써 프로젝트가 제대로 진행되고 있는지 확인한다. 애자일 방법론에서는 소프트웨어가 제대로 동작하는지, 얼마나 요구사항에 맞게 개발되었는지가 중요하다. 이러한 특징으로 인해 ‘애자일을 적용해서 개발을 진행하면 문서를 만들지 않아도 된다.’는 오해를 받기도 한다. 하지만 사실 문서를 만들지 않는 것이 아니라 상황에 맞는 다양한 형태로 산출물을 만들 수 있다는 좀 더 유연한 의미로 받아들일 필요가 있다.