애자일(Agile) 개발 방법론에 대한 생각
글. 오상문 sualchi@daum.net
폭포수 모델을 꿈꾸지만 현실적으로 개발은 애자일 개발 프로세스를 닮아간다.
그런데 그게 애자일을 위한 애자일도 아니고 원하던 애자일이 아니라는 게 문제이다.
폭포수 모델은 각 단계를 거치면서 개발이 진행되는데, 현실적으로 100% 완성도를 가진 단계를 거치는 게 아니다.
즉, 이론과는 동떨어진 상태로 폭포수 단계만 따라가다보니 결과는 의도한 것과 달라질 수밖에 없다.
애자일 개발 프로세스에 대한 설명은 위키 백과에 이렇게 나와있다.
애자일 개발 프로세스는 어느 특정 개발 방법론을 가리키는 말은 아니고
"애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해주는
다양한 방법론 전체를 일컫는 말이다.
예전에는 애자일 개발 프로세스는 "경량(Lightweight)" 프로세스로 불렸다.
익스트림 프로그래밍(XP: eXtreme Programming)이 애자일 개발 프로세스의 대표적인 방법이라 볼 수 있다.
<위키백과 중에서>
애자일이 폭포수보다 절대적으로 좋은 모델인지 아닌지 주장하는 것은 별로 중요하지 않다.
왜냐하면 그건 상대적인 것이기 때문이다. 애자일 자체가 폭포수 모델보다 절대적으로 좋은 개발 모델이므로
모든 프로젝트에 꼭 도입해야 한다고 이야기 하기에는 현실적인 문제가 분명히 존재한다.
애자일이 제기하는 문제들은 폭포수 모델의 실패 모델에서 기인한다. 즉, 폭포수 모델로 잘 진행할 수 있는
프로젝트에 굳이 애자일 모델을 도입할 필요는 없다. 그런데, 폭포수 모델로 개발하다 보면 실패하는 케이스를
어렵지 않게 경험하게 된다. 폭포수 모델이라서 실패한게 아니고 다른 원인이 있을 수 있지만, 아무튼 폭포수
모델의 단점 때문에 돌이킬 수 없는 실패 단계로 빠져드는 경우도 어렵지 않게 볼 수 있다. 장기 프로젝트의
경우에는 심각한 문제가 아닐 수 없다.
간단한 애자일 개발 프로세스
*팀: 기획, 디자인, 프로그래머, 관리자, 의뢰인 등...
1. 팀 구성원이 모여서 무엇을 만들 것인지 논의하고, 내용을 열거하듯이 작성하라.
'진행한 일' / '진행 중인 일' / '진행해야 할 일'에 대한 목록을 작성하고 체크하라.
2. 구현할 기능 단위를 나누고 무엇부터 언제까지(대략) 작업할지 선정하라.
애자일 방법론을 적용하려면, 진행 내역을 기록하고 공유할 '위키 시스템'이 필요하다.
즉, 해당 프로젝트에 대한 회의나 진행 상황에 대하여 위키 페이지에 정보를 기록하는 것이다.
심지어 어떤 사항을 요청했다거나 그에 대한 답변까지도 위키 시스템에 계속 누적하여 보관한다.
(이메일을 이용한 대화 방식은 금지하라.)
3. 2주~5주 후에 팀원이 만나서 구현된 부분을 살펴보고 개선할 사안에 대해 토론하라. (이 과정을 반복한다.)
반복하는 기간은 개발하는 기능에 따라 적합한 것을 선정한다.
2주가 적정한지 4주가 적정한지는 프로젝트에 따라 차이가 있을 것이다.
심지어 1주 단위가 될 수도 있고 6주가 될 수도 있을 것이다.
주기를 확정하기 어려우면 2주, 3주, 4주 단위 중에서 일단 선정하고 진행하라.
애자일 방식은 처음부터 뭔가를 완벽하게 구현하고 다음 단계로 넘어가는 방식이 아니다.
진행하면서 개선하고 자사나 진행 팀에 맞게 애자일 방법을 적용하는 것이다.
(좀더 구체화된 애자일 방법론에 대해서는 다른 전문가들의 글을 참고하기 바란다.)
처음에는 작은 프로젝트부터 적용하는 것이 좋을 것이다.
한두 달짜리 프로젝트면, 1주 단위로 점검하면서 진행할 수 있을 것이다.
토론 시간은 15분~1시간 정도가 적당할 것 같은데, 이것도 꼭 정해진 것은 아니다.
15분이면 충분할 수도 있고, 1시간으로도 부족할 수 있다.
작은 프로젝트라도 팀원이 애자일 방법을 체험하면서, 스스로 적합한 애자일 방법론을 찾게 된다면
중장기 프로젝트에 적용해도 좋을 효과를 가져올 수 있지 않을까 생각해 본다.
<이상>
'소프트웨어 개발&환경' 카테고리의 다른 글
i-pin 인증 (0) | 2012.09.21 |
---|---|
공인인증서 저장 위치 관련 정보 (0) | 2012.09.20 |
Process Innovation + Standardization + Field Manual (프로세스 혁신 + 업무 표준화 + 업무 매뉴얼) (0) | 2012.04.24 |
QA부서가 발전하기 위한 팁 10 (0) | 2012.04.03 |
‘스티브 잡스 비지니스 십계명’ 해설판 (by 수알치) (0) | 2012.03.27 |