애자일 (AGILE) 개발 방법
- 일상생활/Knowledge
- 2011. 6. 22. 11:17
< 애자일이란? >
애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 "애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다.
- 소프트웨어 개발 생산성과 품질 향상을 위하여 개발자의 잠재력 발휘와 개발팀의 협업 최적화를 중심으로 하는 개발 방법론.
- 소프트웨어 개발 팀원들을 고무하는, 협력적 개발 접근 방법
- “Agile”이란 개발과정에서의 시스템의 변경사항을 유연하게 또는 기민하게 대응할 수 있도록 방법론을 제공한다는 것을 의미함.
< 왜? 쓰는가? >
<다른 개발 방법>
1). 전통적인 폭포수 모델의 의 한계
-전통적인 폭포수 모델의 요구분석단계에서 사용자가 개발자에게 한 번에 모든 요구사항을 정확하게 전달하는 것을 가정하고 있으나, 현실적으로 불가능함.
- SW의 비가시성으로 사용자의 요구사항이 프로젝트 진행 시 지속적으로 변경
2). 개발환경의 변화
- 개발환경의 개선:고급개발자의 양산, 컴퓨팅환경의 발전
- 신속한 개발을 지원하는 GUI환경의 모델링 및 개발 도구의 발전
- 테스트 및 디버그 자동화 도구의 등장
- CBD,MDA등의 신속성을 제공하는 개발방법론 등장
-점차 짧아지는 정보시스템의 수명주시
3) 기업 경영환경의 변화
-경영전략이 빈번히 그리고 짧아지는 RTE기업의 등장
-사용자 요구사항의 지속적인 변화
4) 소프트웨어 구축 비용의 낭비
- 자주 사용하는 기능은 전체 기능의 20%밖에 되지 않더라~ 나머지에서 64%는 전혀사용하지 않더라~ 낭비생김
-> 즉 탐욕은 모든 프로젝트 실패의 원인이더라! 이러한 탐욕은 의욕 저하를 만듬
<애자일 방법론의 핵심 가치>
핵심가치 ( 제일 중요함! )
용기,자신감
단순성
의사소통
피드백
존중
자발적 헌신
집중
정리하면,
고객 참여 -> 계약 협상에 앞서 고객과의 협력
프로세스보다 사람 -> 프로세스나 도구에 앞서 개인과 상호 협력
변경을 포용 -> 계획 준수에 앞서 변화에 대한 대응
단순함을 유지 ->
소프트웨어 중심->포괄적인 문서화에 앞서 작동하는 소프트 웨어
반복적 릴리스 ->
<애자일과 전통적인 개발방법론의 다른 차이점,특징>핵심가치 ( 제일 중요함! )
용기,자신감
단순성
의사소통
피드백
존중
자발적 헌신
집중
정리하면,
고객 참여 -> 계약 협상에 앞서 고객과의 협력
프로세스보다 사람 -> 프로세스나 도구에 앞서 개인과 상호 협력
변경을 포용 -> 계획 준수에 앞서 변화에 대한 대응
단순함을 유지 ->
소프트웨어 중심->포괄적인 문서화에 앞서 작동하는 소프트 웨어
반복적 릴리스 ->
표 출저: http://cafe.naver.com/itleader.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=245&
< 애자일의 종류 >
익스트림 프로그래밍(Extreme Programing, XP)
-> 의사소통, 단순성, 피드백, 자신감
애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역할을 하였다. 이 방법은 고객과 함께 2주 정도의 반복개발을 하고, 테스트와 우선 개발을 특징으로 하는 명시적인 기술과 방법을 가지고 있다.
ex) 짝 프로그래밍
ex) 짝 프로그래밍
Scrum
-> 백로그와 스프린트
30일마다 동작 가능한 제품을 제공하는 스플린트를 중심으로 하고 있다. 매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론이다
[출처] 애자일 개발 프로세스|작성자 폭풍우
익스트림 모델링
- 익스트림 모델링은 UML을 이용한 모델링 중심 방법론이다.
다만, 여타 모델링 방법들과는 달리, 언제나 실행할 수 있고 검증할 수 있는 모델을 작성하는 공정을 반복해서, 최종적으로는 모델로부터 자동적으로 제품을 생성하게 한다.
크리스털 패밀리
이 방식은 프로젝트의 규모와 영향의 크기에 따라서 여러종류의 방법론을 제공한다. 그중에서 가장 소규모 팀에 적용하는 크리스털 클리어는 익스트림 프로그래밍 만큼 엄격하지도 않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론이다.
FDD( Feature-Driven Development )
-> 기능 중심 개발
feature마다 2주정도의 반복 개발을 실시한다. Peter Coad가 제창하는 방법론으로써, UML을 이용한 설계 기법과도 밀접한 관련을 가진다.
< Agile Process의 적용분야 >
-소규모의 타임 박스화 된 서브 프로젝트나 반복주기(Iteration)에 적합 (3~12주)
-사용자나 개발자가 정확한 요구사한 도출이 힘들 때
-대규모의 프로젝트보다는 기업내 단위시스템에 적합
-프로토타이핑, 속성개발(RAD)을 할 수 있는 프로젝트에 적합
-소프트웨어 품질 수준이 낮고, 산출물의 범위변경이 불가능하다면 애자일 기법은 활용하기 힘듦
< Agile Process의 향후전망 >
가. 부정적인 측면
- 방법론 그 자체로서 적용하기에는 프로세스 정립은 부족함
- 대형프로젝트에서 적용하기에 적합하지 않음
- 감리에 대한 대응의 어려움
- 관리 방법에 대한 가이드라인이 부족함
- 해당 프로세스를 적용하기 위해서 갖추어야할 제약(선수)조건이 실제 가장 중요하면서도 하기 어려운 부분일수 있고, 안되고 있는 부분이기도 함
나.긍정적인 측면
- 방법론 그 자체로서가 아니라, 일부 기법 또는 사상을 선택하여 쓰기에 매우 좋음.
- 중.소형프로젝트에서 적용하기에 적합하며, 대형 프로젝트라 할지라도 특정 TASK에 대해 이 프로세스를 채택하는 것이 바람직한 영역이 있음
-아키텍처설계 및 프로토타이핑 수립과 같은 태스크 수행시 적합하다고 봄
