사례 중심으로 알아보는
SCRUM & XP
남기룡
마이에트 엔터테인먼트

Agenda
애자일(Agile)이란?
SCRUM
Extreme Programming(XP)
회고
Mountain Goat Software의 Scrum 관련 이미지를 사용함.

애자일(Agile)이란?

애자일 선언문
프로세스와 도구
프로세스와 도구 보다 개인과 상호작용을
개인과 상호작용을
작동하는
작동하는
포괄적인 문서화
포괄적인 문서화 보다
소프트웨어를
소프트웨어를
계약 협상
계약 협상 보다 고객과의 협력을
고객과의 협력을
계획을 따르는 것
계획을 따르는 것 보다 변화에 응대하기를
변화에 응대하기를

애자일의 가치
의사소통(Communication)
단순성(Simplicity)
피드백(Feedback)
용기(Courage)
존중(Respect)

애자일 방법론
Extreme Programming
SCRUM
Lean Software Development
Dynamic System Development Method
Feature Driven Development
Crystal
Adaptive Software Development

마이에트의 애자일
작년 11월부터 새 프로젝트에 SCRUM을 사용하
기 시작함.
High Moon Studio에서의 사례가 계기(GDC2006)
관리의 효율성을 위한 목적
짧은 근무 시간(주당 35시간)
팀 크기가 커짐에 따라 관리 비용이 늘어남
교육
조금씩 작은 실천사항부터 도입
지속적으로 개선
현재 SCRUM과 XP의 실천사항들을 회사 실정에
맞게 수정하여 사용함.

SCRUM

SCRUM

Roles
Designer
Programmer Product owner
(Director)
The Team
Artist
QA
The ScrumMaster

Scrum Process

Scrum Process 24 hours
Sprint
2-4 weeks
Sprint goal
Combat
Sprint Potentially shippable
Combat
Party backlog product increment
Quest
Guild
Party
Guild Quest
Product
backlog

마이에트의 Scrum
스프린트 기간 : 한달
이터레이션 기간 : 일주일(월~ 금)
스프린트 계획 회의
일일 스크럼
스프린트 회고

팀의 구성
스크럼 팀원 수 : 10명
프로그램팀 중심
디렉터, 그래픽팀장, 아트디렉터가 참여
디렉터가 제품 소유주 역할을 담당

이터레이션
일주일 주기
월요일 일일 회의 때 이번 이터레이션 동안
할 일을 계획
이터레이션 동안 작업의 변경은 최소화
금요일 오후
게임 데모
회고 및 평가

스프린트 계획회의

스프린트 계획회의

작업(Task) 카드
작업 이름
초기 추정치
우선 순위
메모 - 세부 사항
완료 조건(Option)
감수자(Option)
작업자
시작날짜, 종료날짜
남은 일수
+ : 스프린트 중간에 추가된 작업

일정판

일일 스크럼(Daily Scrum)
스탠드 업 미팅
출근 시간(오전 10시)에 시작하여 15분내
에 끝남
회의 내용
어제 한 일
오늘 할 일
업무의 장애물
특정 주제에 대한 이야기가 길어지면 관련
된 멤버만 모여 따로 회의

일일 스크럼(Daily Scrum)

Burndown Chart

스프린트 회고(Retrospective)
게임 데모
그동안의 작업물과 결과를 평가한다.
잘한 것은 서로 칭찬하고 잘못한 것은 서
로 반성한다.
개선사항은 다음 스프린트 때 반영한다.

Extreme Programming

Extreme Programming(XP)란?
Code review
Code review -> Pair Programming
Pair Programming
Test-Driven
Test-Driven
Testing
Testing ->
Development
Development
Design
Design -> Refactoring
Refactoring
Continuous
Continuous
Daily Build
Daily Build ->
Integration
Integration

Extreme Programming

Pair Programming
드라이버와 네비게이터의 관계
각자 작업했을 때 만큼의 개발 속도는 나지
않지만 장기적으로는 이익
코드 품질
지식 공유
높은 집중도
적용
짝 프로그래밍하면 효과적인 작업에 적용.
교육의 목적으로도 사용

Pair Programming

TDD(Test Driven Development)
TDD != Test
장점
단순함과 모듈화
안전망
즉각적인 피드백
문서화
과정
1. 재빨리 테스트를 하나 추가한다.
2. 테스트를 실행시켜 새로 추가한 녀석이 실패하는 걸 확인한다.
3. 코드를 약간 수정한다.
4. 테스트를 실행시켜 모두 성공하는지 확인한다.
5. 중복을 제거하기 위해 리팩터링한다.

Unit Test
UnitTest++ 라이브러리 사용
개발자 : Noel Llopis(게임 개발자)
장점
작으면서도 테스트에 필요한 모든 기능이 있다.
쉽고 간단하다.
이식성이 좋음
빌드 후 실행할 때마다 테스트 수행.
커밋할 때마다 빌드 서버가 테스트하여
리포트 (CruiseControl.NET)

Test Example
TEST(ShieldCanBeDamaged)
{
World world;
world.Create();
Player player;
player.Create(world, vec3(1000,1000,0));
player.SetHealth(1000);
Shield shield;
shield.SetHealth(100);
player.Equip(shield);
player.Damage(200);
CHECK(shield.GetHealth() == 0);
CHECK(player.GetHealth() == 900);
}

Simple Design
가능한 최대한 단순하게 설계
점진적으로 설계한다. - > 리팩토링이 필수
CRC(Class- Responsibility- Collaboration)
카드 사용

QA
프로그래머 중에 QA 책임자를 따로 둔다.
매 이터레이션마다 미해결 버그 개수가 제일 많
은 사람이 담당
버그 관리
빌드 관리
테스트 서버 관리

Continuous Integration
일일 빌드 및 테스트
매 이터레이션마다 안정 버전 배포
커밋시마다 빌드 및 유닛 테스트
CruiseControl.NET
게임 배포는 SVN 사용

Feedback
일일 회의
이슈 트래커(Trac)
그래픽팀, 기획팀의 요구 사항
버그 리포트
작업량이 크면 스크럼의 Task로 이동
게시판
위키위키
단위 테스트

사용하고 있는 도구들
소스 관리 : Subversion
테스트 : UnitTest++
리팩토링 : Visual Assist X
빌드 자동화 : 배치 파일, CruiseControl.NET
일정 관리 : 화이트 보드, 포스트잇, 엑셀
피드백 : Trac, 게시판
문서화 : 위키위키, Doxygen

회고(Retrospective)

우리가 하려고 하는 것
의사 소통
피드백
지식 공유
TDD
짝 프로그래밍
코드 리뷰
긴장된 리듬
안정적이고 빠른 릴리즈

효과
.
.

개선해야 할 사항
프로그램팀 중심으로 인한 부분 최적화
팀의 개발 속도
Legacy Code에 테스트를 추가하기
더 많은 기술적인 교육이 필요(설계, TDD, 리팩
토링)
옛날 개발 방법으로 돌아가려고 하는 경향 막기
크런치 모드일 경우의 프로세스는 아직 경험해
보지 못함
결론적으로 아직까지 팀이 애자일하다고 말할
수 없다.

정리
유저에게 사랑받는 재미있는 게임을 만드
는 것이 목표
프로세스의 중요한 것은 팀문화, 사람
실천방법보다 애자일의 가치, 원칙을 이해
해야 한다.
각 실천방법들이 습관화 되어야 한다.
팀의 능력안에서 천천히 변화시켜 나간다.
계속해서 프로세스를 개선하려는 노력이
필요하다.

QA