뉴스레터 3호 기획기사를 맡아주신 분은 10층 서비스개발부 탁우현부장님입니다. 

사내에도 몇 팀은 이미 이것을 적용중이라고 들었습니다, “Agile 방법론" 그 탄생배경부터 현 개발방식의 문제점, Agile개발 4원칙까지 알차고 재밌게 담고 있습니다. 



 Agile하게 개발하라!







Agile[각주:1] 관련 커뮤니티, 기관, 기업, 개인들이 모여서 함께 발전해 나가자는 취지로 결성된 Agile Korea는 2011년에 이어 두번째로 “Agile Korea conference 2012”를 9월달에 개최하여 성황리에 행사를 끝마쳤다. Agile이 무엇이길래 겪어 보지 않은 사람들은 회의적이나 한번 겪어 본 사람들은 맹신자가 될까? 


Agile Korea 바로가기


요즘 대세는 Agile

정보통신산업진흥원 SW 공학센터는 최근 국내 IT 기업 개발자 77명을 대상으로 조사한 결과, 애자일(Agile) 개발방법론이 폭포수 개발방법론, 객체지향 개발방법론 등 기존의 타 개발방법론에 비해 개발직무의 동기유발성이 높은 것으로 나타났다고 밝혔다. 아마도 짧은 개발주기와 참여자간 활발한 의사소통 및 피드백을 통해 직무파악이 쉽고, 책임감 있게 업무를 할 수 있기 때문일 것이다. 


왜 생겨났을까?

요즘 프로젝트는 사업형태가 불명확하고 요구사항 조차 모호한 프로젝트가 많다. 또한 신규 프로젝트가 아니라 기존 사업을 성장시키거나 운영 시스템을 지속적으로 개선해야 하는 경우가 많다.

* 무언가를 처음부터 개발하지 않으므로 체계적인 요구사항이 없다.

* 사업 이슈에 따라 구현하거나 보완해야할 일이 자주 생긴다.

* 목표나 목적이 초반에 뚜렷하지 않아 Rolling wave planning이 필요하다.

* 해당 기술에 경험이 없어 Prototype 이 필요하며 점진적으로 개발해야 한다.


요즘은 위와 같은 상황이 대부분이다. 이런 경우 전형적인 폭포수(Waterfall)개발 방법론[각주:2]은 문제가 있다. 왜냐하면 폭포수 개발방법론에서는 계획/분석 단계에서 요구사항을 확정하지 않으면 다음 단계로 넘어갈 수 없으며 설계/구현 단계에서 요구사항이 변경되면 처음부터 다시 시작해야 하기 때문이다. (이 때문에 고객과 언성을 높이게 된다)


과거 IT 시장에서는 SI시장이 대부분이었으며 개발 범위가 명확한 신규 구축 프로젝트가 많아서 폭포수 개발 방법론이 최적의 방법이었다. 하지만 지금은 시장의 변화에 유연하게 대응하고 사업을 신속하게 성장하기 위한 노하우가 필요하게 되었다.




기존 개발 방법론

대표적인 개발 방법론인 Waterfall 이나 뭐라고 확정 지을 수 없는 우리가 흔히 하는 개발 단계에서 겪는 문제점은 무엇일까?

자주 못하는 회의
조금 열정적인 고객의 경우 개발 진행 상황을 체크하기 위해 2주에 한번씩 정기회의를 하거나 개발 완료 시점에는 매주 정기회의를 하는 경우가 많이 있다. 그나마 매주 하는 것은 다행이며 개발 완료하고 테스트할 때 보자고 하는 고객들도 있다.

팀간 소통 문제
기획팀: 제가 원한 디자인은 이런 것이 아니에요. 이렇게 누르면 이렇게 보여야 해요
디자인팀: 제 생각엔 이렇게 하면 디자인이 더 잘 나와서 그랬는데…. ㅠ
개발팀 : 이건 구현이 안된다구요!!

프로젝트를 하면서 매번 겪는 문제다. 고객이 말을 바꾸는 것은 어느정도 예방책이 있지만 내 뜻은 그것이 아니라고 하는 경우에는 방도가 없다. 아니라는데 어쩔거야!

시장 변화에 무딘 일방적 소통
프로젝트에 참여하는 선임급 인력이 아무리 능력이 좋다 하더라도 모든 내용을 파악하고 분석 설계하는 것은 쉽지 않다. 분석/설계를 잘 하였다 하더라도 프로젝트 진행중에 시장변화로 인한 요구사항이 변경되어야 한다면 요구사항 변경을 원천봉쇄하는것이 PM의 업무가 되고 만다. 결국 고객은 불만을 표출하고 그 PM은 짤린다.

문서만 만들다가 시간 다 간다
구현단계에서의 시행착오를 줄이기 위해 회의나 이를 통해 발견된 내용을 문서화하는 일을 한다. 하지만 오히려 문서화 작업으로 프로젝트가 지연되는 경우가 더 많다. 물론 이미 잘 알려진 프로젝트나 기존 프로젝트를 보완하는 경우는 문서로 정리하는 것이 더 유용하지만 일반적으로 불필요한 문서작업으로 아까운 시간이 다 지나간다.


Agile 개발 방법론 [Agile 기본 4원칙]

본문그럼 Agile은 기존 개발 방법론과 무엇이 다를까? 그 차이점을 한 번 보자

문서화 보다는 소통을
문서화 작업을 최소화하고 문서작업을 하지 않음으로써 생기는 문제를 대화를 통해 해결한다. 매일 10~20분 정도 만나서 이야기하면 무엇을 어떻게 해야하는지가 명확해져 동기부여가 된다.
또한 개발자, 기획자, 디자인, 고객 등 프로젝트관련 사람들이 함께 있으므로 배가 산으로 가는 경우가 없다.

즉시 피드백
빠른 피드백과 대처를 통해 효과적인 의사결정을 한다. 의사결정을 위해 정기 회의때까지 기다릴 필요 없다 현장에서 바로 결정된다.

간단 명료하게(Simple)
필요한 기능만 구현하며 불필요한 부가기능이나 복잡한 알고리즘은 배제한다. 언제든지 내가 만든 코드를 버려도 아깝지 않아야 변경요청을 받아 줄 수 있다.

자신감
고객의 요구사항에 능동적으로 대응할 자신감이 필요하다. 자신감을 높이기 위한 구체적인 실천요소들이 있지만 구체적인 사항은 지면 관계상 생략한다.


무조건 Agile로 개발하자?

애자일에서 추구하는 것은 더 나은 프로젝트 관리 및 성공을 위한 열쇠를 사용하려는 것이지 무조건 애자일 방식으로 프로젝트를 하라는 것은 아니다. 현재 진행중인 프로젝트에 적합한 개발 방법론을 사용하고 있다면 무리하게 적용할 필요는 없다. 하지만 아래 몇 가지는 현 프로젝트에 적용한다면 많은 효과를 볼 것이라 생각한다.

* 매일 10~20분간 가벼운 미팅하기

* 클라이언트와 자주 미팅하기 (1주일에 2번 이상)

* 조금씩 개발하고 중간중간 실행 결과를 눈으로 확인하기


애자일 개발 헌장에는 아래와 같이 정의되어 있다.

 



기획 문서
보다 눈에 보여지는 결과

프로세스와 개발 보다 사람과 의사소통

계약과 협상 보다 고객과의 협업

계획에 대한 맹종 보다 변화에 대한 대응

끝으로, 문서에 있는 내용이 클라이언트의 마음을 모두 대변한다고 생각하지 말자. 흔히 문서대로 만들었으니 내가 할 일은 다 했다고 주장하는 경우가 있다. 생산된 제품이 요구사항일치성[각주:3]과 사용적합성[각주:4]이 결여되었다면 그 제품은 무용지물이다. 


프로젝트란 클라이언트와 협업(빠른 피드백 교환)을 통해 클라이언트가 요구하는 문서가 아니라 클라이언트가 원하는 제품을 만드는 것임을 잊지 말자.

다음에 또 기회가 된다면 Agile 개발 프로세스에 대해 상세히 살펴 보도록 하자.


  1. Agile(애자일) : 사전적 의미 - 재빠른, 날렵한, 기민한 [본문으로]
  2. 폭포수 개발방법론: 분석-설계-구현-시험-운영의 순서로 S/W를 개발하는 전형적인 개발방법론으로써 각 개발 단계에서 그 결과를 철저히 검증/승인과정을 거친 후 다음 단계로 넘어가는 방법론 [본문으로]
  3. 요구사항 일치성(Conformance to Requirement) : 제공하기로 한 것을 제공해야 한다는 것 [본문으로]
  4. 사용 적합성(Fitness for Use) : 고객의 실질적인 필요사항을 충족시켜야 한다는 것 [본문으로]
저작자 표시
신고
Posted by 유엔젤 테크니컬라이터 손대리
comments powered by Disqus

댓글을 달아 주세요