Agile
agile = 기민한, 날렵함
애자일이란 소프트웨어 개발 방식의 하나로,
작업 계획을 짧은 단위로 세우고 제품을 만들고 고쳐나가는 사이클을 반복함으로써 고객의 요구 변화에 유연하고도 신속하게 대응하는 개발 방법론입니다.
애자일은 기민하다라는 뜻으로 <너무 계획이 없는 방법론>, <너무 체계적인 개발방법론> 둘 사이의 균형을 잡자는 의도로 나온 개발방법론입니다.
폭포수모델
전통적인 개발방법론중 에는 <폭포수모델>이 있습니다. 이런 전통적인 개발방법론들은 대략 다음과 같은 틀을 가집니다.
기획 > 디자인 > 개발 > 테스트 > 배포 > 유지보수
많이 겪어봤던 프로세스입니다..!
이 프로세스는 마감기한을 딱. 정해놓고 그 마감기한 안에 프로젝트를 끝내기 위해 모든 팀원이 자신이 맡은 일을 끝낸 후 다음차례로 넘깁니다. 아무 문제 없이 끝난다면 좋겠지만 현실은 그렇지 않아요.
예를 들면 클라이언트는 프로토타입을 보고 수정을 요청할 수 있고, 배포된 앱의 경우 유저반응이 생각보다 별로일 수 있습니다.
다양한 변수들이 생길 수 있죠.
폭포수 모델은 다양한 제약사항을 가집니다.
1. 초기에 모든 요구사항을 정의해야 하며, 이후 단계에서 변경이 어렵다.
2. 고객은 프로젝트의 마지막 단계에서 결과물을 확인할 수 있으므로 피드백 제공이 어렵다.
3. 모든 요구사항의 개발이 완료될 때 까지 제품을 출시할 수 없다.
4. 오류가 발견되면 초기단계로 돌아가 수정해야한다. 이로인해 프로젝트의 시간과 비용이 증가할 수 있다.
하나 예를 들어봅시다.
기획 > 디자인 > 개발(지금 상황에선 불가능한 기능....)
개발자가 기획 회의에 참여한경우 이런 경우는 어느정도 방지할 수 있지만 그렇지 않은 경우 다시 기획 > 디자인 프로세스를 시작해야겠죠..
이런경우 폭포수 모델은 너무 많은 리스크를 팀원에게 강요합니다.
열심히 개발했더니 그동안 고생한게 모두 물거품이 되어버리기 쉬우며, 몇 달 간의 노력이 들어간 제품을 무르고 기획 > 디자인 프로세스를 다시 시작한다면 그로인해 다가오는 스트레스는...
이런 전통적인 방법들의 단점들을 보완하고자 고안된 것이 "애자일"입니다.
애자일 선언
애자일 방법론은 2001년 발표된 "애자일 선언"을 기반으로 합니다.
<<애자일 선언문>>
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주며 소프트웨어 개발의 더 낳은 방법들을 찾아가고 있다.
이 작업을 통해 우리는 다음을 가치있게 여긴다.
1. 공정과 도구보다 개인과 상호작용을
2. 포괄적인 문서보다 작동하는 소프트웨어를
3. 계약, 협상 보다 고객과의 협력을
4. 계획을 따르기 보다 변화에 대응하기를
가치있게 여긴다. 앞에 나온 것들을 무시한다기 보다 둘 다 가치가 있지만 뒤의 것에 중심을 더 둔다는 것이 타당할 듯 하다.
애자일 소프트웨어 개발 선언문은 2001년 소프트웨어 엔지니어 업계들의 리더들이 모여서 공표한 내용입니다.
위의 내용을 하나하나 뜯어보겠습니다.
1. 공정과 도구보다 개인과 상호작용을
어떤 도구를 쓰는지, 어떤 과정을 갖는지보다 개인과의 상호작용(대화와 협력)을 중요시한다.
2. 포괄적인 문서보다 작동하는 소프트웨어를
문서로만 보이는 소프트웨어가 아니라 실제로 작동하는 소프트웨어를 만들고 보여야 한다. 이는 문서로 보여지는 소프트웨어를 고객과 사용자가 서로 다르게 이해하고 있을 수 있기 때문에 우선 소프트웨어를 만들고 고객과 개발자의 이해를 일치시키는데 중점을 둔다.
3. 계약, 협상보다 고객과의 협력을
개발엔 고객도 참여해야한다는 뜻이다. 고객은 계약을 하고 소프트웨어를 받을 때 까지 기다리기만 하는것이 아닌, 개발 과정에 고객이 참여해 주기적으로 피드백을 주어야 고객, 개발자 모두 만족하는 소프트웨어가 나온다는 것입니다.
실제로 애자일에선 매 *스프린트가 끝날 때 고객과 함께 보고 평가하는 "회고 미팅"을 갖게됩니다.
*스프린트: 반복적인 개발 주기
4. 계획을 따르기 보다 변화에 대응하기를 = "계획은 언제든지 바뀔 수 있다"
요약해보자면...
애자일이란?
- 짧은 주기의 개발 단위(스프린트)를 반복하여 하나의 큰 프로젝트를 완성해 나가는 방식이다.
- 애자일의 핵심은 피드백과 협력이다.(협력과 피드백을 자주, 빨리)
- 애자일은 방법론이 아니다.
- 애자일은 협업과 워크플로우를 바라보는 관점, 문화, 사상이다.
- 이러한 애자일을 계승하여 나온것이 칸반, 스크럼, WBS등이 있다.
이 될 것 같습니다.
애자일의 기본적인 요소들
애자일 개발 방법론에는 여러 구성요소와 용어들이 사용됩니다. 이들을 살펴봅시다.
아래 설명을 전부 보고 이미지를 다시 보면 좋을 듯 합니다.
1. User Story
UserStory는 고객이나 사용자 관점에서 시스템에 필요한 기능이나 요구사항을 간단하게 기술한 것입니다.
이건 철저히 유저중심으로 만들어져야 하는데 보통 아래와 같이 작성됩니다.
- [US-0001] 사용자는 로그인할 수 있어야 하므로, 계정으로 서비스를 이용한다.
- [US-0002] 구매자는 상품을 주문하고 결제할 수 있어야 한다.
- [US-0003] 개발자는 소셜로그인 기능 개발을 위해 관련 API를 사용할 수 있어야 한다.
UserStory는 되도록 누가(who), 무엇을(what), 왜(why) 세가지가 들어가야 합니다.
이는 관련 없는 사람이 보더라도 한 눈에 무엇을 의미하는 내용인지 알 수 있게됩니다.
여기서 또한 이 누가(who)에는 개발자도 포함이 될 수 있다.
- Backlog: 개발해야할 기능 또는 제품에서 요구하는 기능과 우선순위를 말한다.
2. Product Backlog
Product Backlog는 프로젝트에서 구현해야 할 기능, 버그 수정, 개선사항등 리스트를 포함하고 있으며 우선순위가 정렬되어 있어야 합니다. 이는 앞으로 처리해야 할 여러개의 유저 스토리로 구성되어 있습니다. 이는 PO(Product Owner)가 정의한 우선 순위로 정렬됩니다.
우선순위에 대한 권하는 PO의 직권입니다.
3. Sprint Backlog
특정 스프린트 동안 구현될 기능과 작업을 담은 목록입니다. 이 목록은 해당 스프린트 동안 팀이 완료해야 하는 작업을 정의합니다.
이 작업들은 Product Backlog에서 선택된 것일 수 있습니다.
* 쉽게 말하면 Product Backlog는 내가 앞으로 사야할 물건 리스트가 되고, Sprint Backlog는 리스트에서 이번달 월급으로 살 물건이 됩니다.
4. Estimation(견적)
Estimation은 Backlog 항목들이 구현되는데 얼마나 많은 시간과 노력이 필요한지 추정하는 과정입니다.
한국어로는 견적정도의 의미입니다.
5. Retrospective(회고)
Retrospective는 스프린트의 마무리 단계로 팀이 모여 그동안의 작업을 회고하고 개선할 부분을 논의하는 시간입니다.
스프린트마다 회고를 진행하여 프로세스의 지속적인 개선을 목표로 합니다.
6. Sprint
Sprint는 애자일 프로젝트의 한 반복주기를 의미합니다. 일반적으로 2~4주간 지속되며 이 기간동안 팀은 Sprint Backlog의 항목을 완료하는 것을 목표로 합니다.