애자일 개발방법론

게임개발에 반드시 도입되어야 하는 개발방법론이라고 생각합니다.

게임은 정말 다양한 아이디어와 기술의 집합체라고 생각합니다. 하지만 그만큼 직접 눈으로 보고 플레이하기 전에는 확인해보기 어려운 내용이 많습니다.

 

프롬더레드에서는 애자일 프로세스를 점진적으로 도입하여 추후 모든 프로젝트의 기본 개발 프로세스로 정착해 나갈 예정입니다.

추가로 애자일 프로세스에 대해 잘 정리한 글이 있어 공유 드립니다.

(하지만 애자일이 천하무적은 아닙니다. 제대로 파악하지 않고 덤비면 open the hell gate. 다음 번에는 애자일의 단점과 불편한 진실에 대해서도 공유 드리겠습니다.)

 

애자일 개발방법론 (Agile Development Methodology)

이 글은 한글 번역본입니다.

(출처: http://agilemethodology.org/)

애자일이란?

애자일은 방법론이 아닙니다!

애자일은 기민한, 좋은 것을 빠르고 낭비없게 만든다는 뜻인데요,

애자일 방법론은 전통적 프로젝트 관리 방법인 폭포수 모델,

혹은 순차적인 개발방법을 대체하는 또 다른 방법입니다.

애자일 처리 방법은 반복적인 일과 경험에 의거한 피드백을 통해서

예측 불가능한 일에 대응할 수 있도록 도와줍니다.

(출처: www.livnara.com)

스크럼이란?

스크럼은 애자일 개발 과정의 하나로, 단순함과 융통성 때문에 가장 인기있는 방법론입니다.

이러한 인기 덕분에, 많은 조직들이 “스크럼”을 한다고 하는데요,

사실 “정확한 스크럼”방법론을 이용하는 것은 아닙니다.

스크럼의 정확한 정의는 경험에 의거한 피드백, 팀의 자가적인 관리,

그리고 짧은 반복을 통해서 적합한 제품 테스트에 중점을 두는 개발방법론입니다.

스크럼은 애자일 방법론을 이용하지 않는 조직에게는 맞지 않을 때가 많습니다.

(출처: en.wikipedia.org)

스크럼은 세 가지 역할이 있는데요, 제품 책임자, 팀, 그리고 스크럼 마스터 입니다.

이는 Michale James의 The Scrum Training Series에 설명되어 있습니다.

전통적인 프로젝트 관리자의 역할은 이 세가지로 나누어져 있습니다.

또한, 스크럼은 다섯개의 진행 방법이 있습니다:

제품 백로그(Backlog Grooming), 스프린트 계획(Sprint Planning), 일일 스크럼(Daily Scrum),

스프린트 검토 회의(Sprint Review Meeting), 그리고 스프린트 후행 회의(Sprint Retrospective Meeting)입니다.

스크럼 개발방법론을 시작하는 방법 중 하나는 Scrum Training Series인데요,

(Scrum Training Series: http://scrumtrainingseries.com/)

애자일 방법론을 진행할 수 있는 인기있는 방법들을 다루고 있습니다.

또한, 6페이지의 Scrum Reference Card를 다운 받을 수 있습니다.

(출처: svsg.co)

애자일의 역사

1970년 Winston Royce 박사가 논문(“Managing the Development of Large Software Systems”)에서

애자일에 대해 발표하며, 전통적인 순차적 개발 방법을 비판했습니다.

그는 소프트웨어는 자동차를 조립라인에서 생산하는 것과 다르게 개발되어야한다고 주장했습니다.

자동차는 일련의 차례를 기반으로 생산이 되어서, 각각의 단계가 마무리 되어야만 다음 단계로 넘어갈 수 있습니다.

Royce 박사는 이러한 단계적인 방법을 반대하면서,

개발자들이 먼저 프로젝트의 필요사항들을 수집하고,

모든 아키텍쳐와 디자인을 완료한 후에, 코딩을 작성하는 방법 반복적으로 해야한다고 주장했습니다.

Royce 박사가 특히 전통적 방식에 반대하는 이유는 순차적으로 일을 하게되면,

각각의 단계의 일을 수행하는 사람들 사이에서 소통이 없어지기 때문입니다.

 

(출처: vesti-kareliya.ru)

애자일 개발방법론과 비교해보았을 때, “폭포수 모델” 혹은 순차적 개발 방법이

최적화된 방법과는 거리가 멀다는 것을 알 수 있습니다.

첫 번째로, 전통적 방식은 디자인이나 코딩 전에 프로젝트에 필요한 모든 요인들을 다 파악할 수 있다고 가정합니다.

다시 말하자면, 과연 소프트웨어가 실행되기도 전에 필요한 모든 부분을 개발자 팀에게 알려줄 수 있을까요?

소프트웨어 기능을 실행해보고 나서 더 쉽게 알려줄 수 있지 않을까요?

많은 소프트웨어 개발자들은 지금까지 더 어려운 방식으로 일을 해왔습니다.

프로젝트 과정 끝에 그 개발자 팀은 요구된 소프트웨어를 다 만들었을지도 모르지만,

그 동안 비즈니스 사회는 크게 달라져서 완성 되고 난 시점에서 그 프로젝트는 가치가 떨어졌을 것입니다.

이 경우에서 회사는 많은 돈과 시간을 투자했지만 누구도 원하지 않는 소프트웨어를 만든 것입니다.

이를 해결할 수 있는 방법이 바로 애자일 개발방법론을 사용하는 것입니다.

(출처: designshack.net)

왜 애자일 개발방법론을 써야 할까요?

애자일 개발방법론은 개발 주기를 통해 프로젝트의 방향과 목표를 가늠하도록 도와줍니다.

이는 반복적인 주기(스프린트)를 거쳐서 이루어지는데요,

과정 후에 마지막에 실행 가능한 제품을 발표합니다.

단축된 일의 반복과 제품 기능에 중점을 두기 때문에

애자일 개발방법론은 “반복적”이고 “증가적”이라고 표현됩니다.

폭포수 모델에서 개발자들은 한 번의 기회만으로 프로젝트의 모든 측면을 검토해야합니다.

반면에 애자일 패러다임에서는 일정한 주기를 통해 계속적으로 모든 측면을 재검토 할 수 있습니다.

예를 들어서 2주마다 프로젝트의 목표를 재검토 했을 때 고쳐야 할 점이 있다면,

처음과는 또 다른 방향으로 전환할 기회가 있는 것이죠.

(출처: agilefellow.com)

이러한 “inspect-and-adapt” 개발방법은 개발 비용과 시간을 크게 줄여줍니다.

개발자들은 소프트웨어를 개발하는 동시에 필요한 부분을 수집하기 때문에.

초반에 정보 과다로 인해 분석을 하지 못하는 일은 생기지 않습니다.

애자일 개발방법론은 회사가 적합한 제품을 만드는 것을 도와줍니다.

아직 다 완성되지 않은 소프트웨어가 시장에 출시되는 것을 막고,

제품의 출시를 계속해서 재검토하고 다시 계획을 세우게 만들어

다시 개발을 통해서 그 가치를 최적화할  수 있도록 도와줍니다.

또한 시장 경쟁령을 갖추도록 만들어줍니다.

애자일 방법론을 이용하는 개발은 제품의 시장 적합성을 보존하며,

팀의 일이 헛수고가 되지 않도록 보장합니다.

출처: http://flearning-blog.tistory.com/230 [플러닝 Flearning]

 

 

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

w

%s에 연결하는 중