IT자격증

에자일(Agile) 개발 방법론의 탄생 배경

보통 소프트웨어를 개발하는 과정을 보면 우선 사용자로부터 요구사항수집을 해서 분석을 하고
설계를 하고 개발하고 테스트를 해서 최종 Release 하는 방식으로 전통적인 방식이다.
일명 '폭포수(Waterfall)' 방식이라고 하는데  가장 많이 사용되는 개발방법이다.
이 전통적인 폭포수 개발 기법이 지닌 단점은 지나치게 계획과 절차에 의존한다는 것이다. 각 단계별로 
완료가 되어야 다음 단계로 넘어갈 수 있다. 물론 각 단계에 걸쳐 제어의 증가가 가능하지만, 이미 계획과
절차가 고정되어 있기 때문에 중간에 기능이나 프로세스의 변경사항이 발생하면 이를 반영하기가 어려운
개발방법론중에 하나다 . 즉 프로젝트가 이미 진행 중인 상황에서 프로젝트 범위가 변경될 때 유연성이 극히 떨어진다
또한 빈틈없는 계획과 단계별 엄격한 심사(Gate Review)를 중시하다 보면 당연히 시간과 비용의 낭비가 증가하게 된다.
하나의 오류가 발생하면 이를 해결하기 위해 이전 단계로 거슬러 올라가서 다시 내려와야 하기 때문에 납기일 준수가
쉽지 않게 된다.  소프트웨어 개발 업계에서 관행화된 납기일 지연과 반복되는 야근, 그리고 이에 따른 스트레스로 개발자들의 번아웃(Burn-out)이 빈번하게 발생하는 것도 이와 무관치 않다.
애자일 방식은 이런 단점을 개선할 수 있다는 기대를 받으며 1990년대에 처음 등장하였다.
대표적으로 Microsoft사의 익스플로러 개발에 적용을 해서 성공한 걸로 이름이 알려지기 시작했다. 
Microsoft사는 그 다시 웹브라우저 시장을 장악하고 있던 넷스케이프를 이기기 위해 Internet Explorer 개발
프로젝트를 가동했는데 이때 Agile 방식을 적용했다. 즉 전체 요구사항의 30% 정도 개발된 알파 버전을 공개했고
그 이후 feedback 을 수용해서 50% 정도 개발된 버전을 공개하였다.. 이런 식으로 feedback과 공개를 반복해가면서
프로젝트를 진행해.. 결국 대성공을 거두었다.

에자일 (Agile) 의 정의

Agile 이란 단어의 뜻은 '민첩한' 이라는 뜻이다. 먼가 개발을 민첩하게 한다는 뜻이겠지요..
Agile 방법론이란 짧은 단위로 개발계획을 세워서 개발을 진행해서 Relase 한 후 고객의 Feedback을
받아서 바로 다음 개발계획에 적용나가는 Cycle을 반복함으로써 고객의 요구사항 변화에 신속하고
유연하게 대처할 수 있는 개발 방법론이다.
전통적인 폭포수(Waterfall) 모델은 개발이 다 끝나야 고객에게 시제품을 보여 줄수 있기 때문에
고객의 요구사항 변경에 대응을 바로 못하지만, 에자일(Agile)은 개발단위를 짧게 (보통 1~2주) 잡음
으로써 고객은 바로 시제품을 보고 feedback을 줄 수 있어서 변경사항을 반영하기가 수월하다. 
예를 들면.. 요리사가 레시피를 보고 그대로 요리를 한 후 손님에게 가져다 주는 방식이 폭포수모델
이라고 한다면, 에자일모델은 요리사가 요리를 하면서 중간중간 맛을 보면서 요리를 하는 방식이라고
할수있다.. (적절한 비유인가요?? ㅋㅋ)

에자일(Agile)의 선언

  ① 프로세스/도구보다는  -> 개인과의 소통을 더 중요시
  ② 문서 보다는              -> 동작하는 S/W을 더 중요시
  ③ 계약/협상 보다는       -> 고객과의 협력을 더 중요시 
  ④ 계약준수 보다는        -> 변화에 대응을 더 중요시


에자일(Agile) 개발방법론의 특징

 ① Predictive 하기 보다는 Adaptive 한 방법론  (변화에 반응하는 것이 계획을 준수하는 것보다 우선함)  
 ② 프로세스 중심이 아닌 사람중심의 방법론  (개인간의 의사소통이 프로세스나 도구보다 우선함)
 ③ 동작하는 소프트웨어가 포괄적인 문서보다 우선함.
 ④ 고객과의 협력이 계약협상보다 우선함.


에자일(Agile) 개발방법론의 종류

에자일(Agile) 개발방법론의 단점

에자일 방법론은 현재 대세로 자리 잡고 있는 개발방법론에는 틀림이 없다.
① 하지만 필드에서는 인식이 그렇게 좋은 편은 아니다.. '무한수정방법론' 이라고도 불리울 정도로
    자칫 고객의 요구사항을 계속 반영하다보면은 계속 수정을 할수밖에 없는 상황에 내몰리게 된다
    PM (Projecct Manager)가 적당한 선에서 요구사항을 짤를껀 짤라줘야 하는 , 즉 PM의 역할에 따라
    일의 양이 달라질 수 있다.
② 계획대로 짧은 주기의 작업이 완료될려면 팀원의 능력이 그 만큼 따라주어야 한다. 
    팀내 팀원들의 능력이 같이 않기 때문에 한 팀원의 performance  에 따라 전체 개발기간이 좌우
    될 수있다.. A 팀원의 능력이 1.5 이고 B팀원의 능력이 0.5  이면 전체 능력은 0.5에 맞춰질 수
    있기 때문이다  따라서 팀내의 역량이 부족하다 싶을때에는 매뉴얼화와 그것을 지속적으로 가르쳐줄 수
    있는 시스템이 우선되어야 한다. 그래서 충분히 역량을 발휘하기 좋은 시점이 올때 에자일방식 진행을
    시도하는것이 좋다.