'Agile의 의미'와 '기민한 계획 수립'
('What it means to be agile' & 'Agile Planning')



(아래의 첨부 파일를 받으시길 권합니다.
위의 미리보기에서는 에니메이션이나 슬라이드 노트를 볼 수 없습니다.)


GDC 2007에서 있었던 Agile Game Development Tutorial의 일부인 'Agile의 의미'와 '기민한 계획 수립'의 한글 번역입니다:
(강연자인 Mike Cohn의 허가를 받고 번역하였습니다.)

마지막으로 여러분의 소감, 비판, 경험 혹은 계획을 Trackback이나 댓글로 달아주시면 정말 감사하겠습니다.
:

포스팅이 늦었지만, 남기룡 님의 팀에서 현황판(War Room)을 개량했다고 합니다:

사용자 삽입 이미지

자세한 설명은 위의 Link에 있습니다.



아실 분들을 다 아시지만, 제 Blog만 보실 분들을 위해서 써둡니다.

마지막으로 "심심할 때마다 괴롭히도록 한다." 원츄!


P.S. 제가 실감한 이 일정판의 가장 큰 장점은, 사장님이 와서 일일히, '그거 들어갔나?' 혹은 '그 문제는 어떻게 되었어?'라고 묻는 경우가 줄어든다는 겁니다. (웃음) 물론 반대로 저도 작업자들에게 일일히 묻는 경우가 줄어들죠.

:

애자일 게임 개발: 현실 세계의 혼돈을 다루는 법
(Agile Game Development: Dealing With Chaos In The Real World)



(가급적 아래의 압축 파일을 받으시길 권합니다.
위의 슬라이드에는 '슬라이드 노트'와 에니메이션이 없습니다.)

영어원문: http://www.gamesfromwithin.com/articles/0411/000047.html


MIGS 2004에서, Noel Llopis가 발표한 "애자일 게임 개발: 현실 세계의 혼돈을 다루는 법"의 슬라이드 한글판입니다.

주요 내용은 다음과 같습니다:
  • 왜 Agile Game Development이 필요한가?
  • Agile Development와 게임 개발
  • Scrum과 게임 개발
  • XP와 게임 개발
2004년의 내용이라, 그 뒤에 발표된 내용들과 다른 점들이 있습니다. 특히 어떤 기준으로 Scrum팀을 조직하는가에 대한 부분은 슬라이드 노트에 적은 자료를 참고하시기 바랍니다.

:

애자일 소프트웨어 개발에는 여러가지 기법들이 있습니다. 여기서 언급되는 XP와 Scrum은 그것들 중 하나죠. 다음 글에서는 애자일 게임 개발에서 언급되지 않았던 다른 몇가지 기법들을 소개합니다:


애자일 소프트웨어 개발

애자일 소프트웨어 개발은 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의 특징은 다음과 같다:

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

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


Dynamic Systems Development Method

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

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

출처: http://www.ibm.com/developerworks/kr/library/ws-agile1/index.html
원문: http://www.ibm.com/developerworks/webservices/library/ws-agile1

위의 글은 발췌본이니, 가능하시다면 전문을 한 번 읽어보시길 권해드립니다.

:

Yahoo Group의 Scrum Development에 올라왔던 글. (Agile Game Develoment blog에서 재인용.)

Scrum은 다음의 두 경우 모두에 매우 효과적입니다:
  1. 일정이 고정되어 있지만 개발 범위는 유동적이거나,
  2. 개발 범위가 고정되어-하지만 늘상 그렇듯 늘어나죠-있고 일정이 유동적일 때.
하지만 만약 일정과 개발 범위 모두 고정되어 있다면,

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

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



웃기면서도 굉장히 진지한 조언이군요. 적용할 때, 염두에 두어야 할 듯 합니다. (웃음)
:

애자일 게임 개발을 이용한 게임 기획
(Game Design in Agile Development)


GDC 2007의 "애자일 게임 개발을 이용한 게임 기획(Game Design in Agile Development)"입니다.

다루고 있는 내용은 다음과 같습니다: 애자일 게임 개발을 적용할 때,
  • 게임 기획자들이 입는 혜택
  • 달라지는 점들
  • 주의해야 할 난관들

대부분의 애자일 관련 자료들이 프로젝트 관리나 프로그래밍을 다루고 있다는 점에서, 현재까지는 게임 기획에 관한 유일한 자료입니다.

이것으로 '(좋은 것 같긴 한데) 그래서 애자일을 어떻게 내 업무에 적용할까?'라는 기획자의 고민이 조금이나마 줄었으면 좋겠습니다.


..

(아래의 PPT를 받으시길 권합니다.
아래의 PPT에는 중요한 슬라이드 노트와 애니메이션이 포함되어 있습니다.)



Rory Mcguire의 허가를 받고 번역하였으며, 원문(의 축약판)은 이곳에서 받으실 수 있습니다.

마지막으로 여러분의 의견을 Trackback이나 댓글로 남겨주시면, 다른 분들과 의견을 공유하고, 다음 번역에 더 큰 도움이 될 듯 합니다.

감사합니다.

===============================================================================================
갱신 이력
  • 2007년 06월 12일
    • 맞춤법 교정.
  • 2007년 06월 04일
    • p.9, p.32: 슬라이드 노트 추가
    • p.11, p.47: 맞춤법 교정.
===============================================================================================
:

GDC 2006에서 발표된 "바쁠수록 돌아가라: 테스트-주도 개발을 이용해 더 좋은 게임 만들기(Backwards Is Forward: Making Better Games With TDD)"영문 슬라이드, 소스 코드 예제 및 노트입니다.
(단, 슬라이드는 GDC 2006보다 조금 더 보강된 Game Connect 2006의 "Test Driven Development For Games: What, Why And How"로 교체합니다.)

이전의 실전 애자일 게임 개발보다 테스트-주도 개발를 더 자세하게 다루고 있습니다.




마지막으로 이 강연 슬라이드나 노트(혹은 둘 다)를 번역하실 분을 찾습니다!

제가 번역할까 했으나, 소스 코드 등 보다 실무적인 내용인 내용을 다루고 있어서, 프로그래머이신 분이 번역해주시는 게 효과적일 듯 합니다. (저는 프로그래머가 아닌지라, 사실 Scrum에 많은 관심을 갖고 있습니다.)

관심이 있으신 분은 답글을 달아주시거나, 오른쪽 상단에 있는 제 Email로 연락주십시요.

여러분의 많은 참여를 기다립니다!

:

실전 애자일 게임 개발
(Agile Game Development From The Trenches)


===================================================================================================
갱신 이력
  • 2007년 06월 02일: p. 33~35쪽의 슬라이드 노트를 추가했습니다.
===================================================================================================


이번에는 "실전 애자일 게임 개발"입니다. Noel LlopisMontreal International Game Summit 2006에서 발표한 내용을 번역했습니다.

주요 내용은 Agile 기법들 중의 하나인 XP를 다루고 있습니다. Clinton Keith가 주로 다룬 Scrum이 프로젝트 관리에 가깝다면, XP는 좀더 프로그래밍에 가깝습니다. 실전이라는 표현답게, 비교적 구체적인 실천 사항들(practices)을 이야기합니다. (from the trenches를 직역하면 '(최전선의) 참호로부터'가 됩니다.)

(가급적 아래의 압축 파일을 받으시길 권합니다.
위의 슬라이드에는 '슬라이드 노트'가 없습니다.)



한편 Noel Llopis의 허가를 받고 번역했으며, 원본의 출처는 이곳입니다.

마지막으로 마음껏 퍼가시되, 가능하다면 trackback을 남겨주시면 서로 관심사나 정보를 공유하는데 도움이 되지 않을까 싶습니다.
:


Microsoft의 소프트웨어 개발 방법
(21 Rules of Thumb - How Microsoft develops its Software)



목차:

제1부: 일정 맞추기
   1. 아는 체 하지 마라.
   2. 상황을 파악한 다음에 움직여라.
   3. 제품-일정-비용의 삼각형을 기억하라.
   4. 어둠 속으로 돌진하지 마라.
   5. 무결점 이정표를 사용하라.
   6. 팀워크를 유지하라.
   7. 일정에는 조삼모사가 없다.
   8. 일정이 밀리면, 전열을 가다듬으라.
   9. 밑바닥 기술이 중요하다.
  10. 설계할 때는 설계만 한다.
  11. 만들어야 출시할 수 있다.
  12. 호환성은 카누 만들 때나 필요하다.

제2부: 위대한 소프트웨어
  13. 고객을 감동시켜라.
  14. 통일성이라는 한 가지 명제만 기억하라.
  15. 설계 사상을 명확하게 잡아라.
  16. 비교하라.
  17. 균형을 맞춰라
  18. 발전시켜라.
  19. 제품을 층층이 쌓아라.
  20. 공유할 비전을 정하라.

제3부: 출시
  21. 팀을 항상 출시 모드로 유지하라.

전문


Agile이라 불리던, 실용주의라 불리던, 혹은 경험에서 우러나온 어림짐작(Rule of thumb)이건, 성공적인 소프트웨어를 만드는 건 똑같다는 생각이 듭니다. 위의 21가지 중에서 Agile에서도 강조되는 것들을 골라보면 다음과 같습니다:
   6. 팀워크를 유지하라.
   7. 일정에는 조삼모사가 없다.
  11. 만들어야 출시할 수 있다.
  13. 고객을 감동시켜라.
  18. 발전시켜라.
  19. 제품을 층층이 쌓아라.
  21. 팀을 항상 출시 모드로 유지하라.

:

마이크로소프트웨어(2007년 3월호)에 실린 Agile에 대한 특집입니다. 이미 애자일 이야기오픈마루 블로그를통해서 보신 분들도 있겠지만, 아닐 분들을 위해서 올려둡니다.


변화를 꿈꾸는 개발 방법론 애자일(Agile)
  1. 애자일이란 무엇인가? (강석천)
  2. 오픈마루 개발 환경에서 본 애자일 (강규영)
  3. 애자일의 미래 (김창준)

: