• 국문판: PDF
  
• 영문판: PDF, CHM 1/2 2/2
  

한 가지 더 말씀드리고 싶은 게 있다면, 애자일 게임 개발은 게임을 만드는 방법이 아니라, 그저 '프로세스'에 지나지 않는다는 것입니다. (중략) 끝내주는 게임을 만드는 최소한의 조건은 [끝내주는 프로세스가 아니라] 끝내주는 팀을 만드는 겁니다. (중략) 더  좋은 프로세스가 더 좋은 게임을 만든다는 걸 말하려는 게 아닙니다. 그저 좋은 팀이 [더 좋은 결과를 낼 수 있도록] 돕는 것뿐이죠.
(The other thing I'd like to mention as well, I'm not apealing this is the way to make games. This is a just a process. ... Really bottom line is a great game makes a great game. ...  It's not about which better process gonna produce a better game. This is just helping great teams.)

invalid-file

invalid-file

애자일 소프트웨어 개발은 90년대 후반에 시작되었다. 이 당시에는 Kent Beck이 소프트웨어 플래닝, 코딩, 디자인, 테스팅의 가치와 원리와 방법론을 통해 Extreme Programming (XP)을 선보였던 때이다. (Extreme Programming: A gentle introduction 참조)

모든 애자일 소프트웨어 개발 방식에는 여러 가치들이 있다:

• 잦은 검사와 적용
• 주기적인 배포
• 협업과 긴밀한 커뮤니케이션
• 반응적 향상
• (점증적인) 요구 사항, 기술, 팀 기능의 탄생
• 권한 부여와 자가 구성
• 인도물이 아닌 현재의 것 다루기
• 용기와 존경

오늘날 다양한 애자일 방식들은 각기 다른 방법들을 강조하고 있다.

2001년 2월, Agile Manifesto가 만들어지면서, 개인과 프로세스와 툴을 통한 인터랙션, 포괄적인 문서를 통한 소프트웨어 작동, 계약 협상을 통한 고객 협업, 플랜을 따르는 것 이상으로 변화에 대응하는 것 등에 가치가 매겨졌다. 이는 오늘날 사용되는 모든 애자일 방식의 토대가 된다.

먼저, 가장 일반적으로 사용되는 애자일 방식을 설명하고자 한다. 이들 중 많은 것들이 SOA 개발에도 유용하다. SOA는 소프트웨어 개발 그 이상이라는 것은 우리도 알고 있다. SOA는 비즈니스와 IT 아키텍처에 관한 것이기도 하다. 따라서 소프트웨어 개발 방식을 생각할 때면 언제나 이것이 SOA에 적합한지를 평가해야 한다. 적합성 평가에 대해서는 다음 시리즈에서 다루도록 하겠다.

Scrum

Scrum은 단순해 보이지만 작업에 영향을 주고 핵심적인 애자일 특징을 지닌 방식을 갖추고 있다. Scrum의 특징은 스스로 방향을 설정한 팀, 매일 매일의 팀 평가, 규정된 프로세스 지양이라는 특징이 있다. 다음은 Scrum의 기본적인 특징이다.

• 스스로 방향을 설정하고 구성한 팀
• 특별한 문제(무엇을 했는가, 무엇을 할 것인가, 문제가 무엇인가) 들을 주제로 한 매일 매일의 미팅
• 30일 주기 반복
• 매번 반복을 시작할 때 고객 위주의 적응성 플래닝
• (각 반복의 끝에) 스테이크홀더에 기능을 선보임

엔터프라이즈의 경우, 프로젝트 간 의존성을 이해하고 관리하는 것이 중요하다. 이것은 Scrum에서 "글로벌 백로그(global backlog)"를 통해 잘 관리되고 있다. 이는 사용자가 가치를 두고 있는 기능적 요구 사항과 비기능적 요구 사항을 엔터프라이즈 관점에서 본 것이다. 글로벌 백로그에서는 전체적인 우선순위가 정해진다. 각 프로젝트는 글로벌 백로그에서 자신들에게 가장 중요한 부분들을 취한다. 프로젝트 간 동기화 역시 Scrum of Scrums"에서 다루고 있다. 팀들간 동기화를 위해서 각 팀의 대표들과 이틀에 한번 또는 매주 미팅을 갖는다.

XP

XP (http://www.extremeprogramming.org와 http://www.xprogramming.com)는 협업, 빠른 소프트웨어 구현, 매우 기술적인 개발 방식을 강조한다. 이것은 주요 관행들(함께 앉기, 전체 팀, 정보가 풍부한 작업 공간, 짝(pair) 프로그래밍, 주간 반복, 여유, 10분 구현, 연속 반복, 테스트 우선 프로그래밍, 점증적인 디자인)과 부차적인 관행들(실제 고객 개입, 점증적인 전개, 뿌리 원인 분석, 공유 코드, 싱글 코드 기반, 협상된 범위 계약, 사용에 따른 비용 지불)로 구성된다.

Crystal

Crystal은 주기적인 인도(delivery), 긴밀한 통신, 반응적인 향상을 강조하는 방법론이다. Crystal의 특징은 다음과 같다:

• economic-cooperative game model
• 우선순위 선별
• 속성
• 원리
• 샘플 기술
• 프로젝트 예제

Crystal에서 우선순위는 프로젝트 결과의 안정성, 개발 효율성, 규율 지키기 등이다. 프로젝트 팀은 7 개의 특징을 지니고 있다. (첫 번째 세 개는 Crystal의 핵심이고, 다른 것들은 안정성을 위해 필요한 것들이다.):

• 잦은 검사와 적용
• 주기적인 배포
• 긴밀한 커뮤니케이션; 개인적인 안정성
• 포커스
• 전문 사용자들로의 쉬운 액세스
• 자동화된 테스팅을 갖춘 기술 환경
• 설정 관리
• 잦은 통합

Dynamic Systems Development Method

The Dynamic Systems Development Method (DSDM)는 시스템을 구현하고 관리하는 제어 프레임웍을 제공한다. 촉박한 시간 제약을 맞추고 반복적인 Rapid Application Development (RAD) 성공을 위한 방법을 제시한다. 이 방식은 개발자 관점의 RAD 뿐만 아니라 효과적인 시스템 개발에 관심이 있는 모든 사람들의 요구들을 포용한다. 아래 리스트는 DSDM의 관리 원리이다:

• 적극적인 사용자 개입이 필요하다.
• DSDM 팀은 결정을 내릴 수 있어야 한다.
• 목표는 제품의 주기적인 인도이다.
• 비즈니스 목적에 맞추는 것은 인도물의 필수 기준이다.
• 반복적이고 점증적인 개발은 정확한 비즈니스 솔루션으로 수렴되어야 한다.
• 개발 시 모든 변경 사항들은 원상으로 되돌릴 수 있어야 한다.
• 요구 사항들은 고급 레벨을 기반으로 우선순위가 정해져야 한다.
• 테스팅이 라이프 사이클에 통합된다.
• 모든 이해 관계자들간 협업이 필요하다.

Scrum은 다음의 두 경우 모두에 매우 효과적입니다:

1. 일정이 고정되어 있지만 개발 범위는 유동적이거나,
   
2. 개발 범위가 고정되어-하지만 늘상 그렇듯 늘어나죠-있고 일정이 유동적일 때.

하지만 만약 일정과 개발 범위 모두 고정되어 있다면,

저는 당신께 폭포수나 RUP(Rational Unified Process)를 권하겠습니다.

최소한 다른 일자리를 알아볼 몇달 간의 시간을 벌어줄테니까요.