애자일 소프트웨어 개발

1부 문제와 해결책
1장 게임 개발이 직면한 위기
__간추린 게임 개발의 역사
____오락실 게임에서의 반복
____초기 방법론
____묻지마 투자의 종말
__위기
____줄어든 혁신
____떨어진 가치
____악화된 업무 환경
__한 줄기 희망
__추가 자료

2장 애자일 개발
__프로젝트가 어려운 이유
____프로젝트 검토로부터 배우기
____문제
__왜 게임 개발에 애자일을 사용하는가
____아는 것이 열쇠다
____비용과 품질
____우선 재미를 찾는 것부터
____낭비 제거
____게임 개발에 적용하는 애자일 가치
__애자일 프로젝트 모습
____애자일 개발
____전체 프로젝트
__애자일 도전
__추가 자료

2부 스크럼과 애자일 계획
3장 스크럼
__스크럼의 역사
____큰 그림
____스크럼 원칙
__스크럼 구성
____제품 백로그
____스프린트
____릴리스
__스크럼 역할
____스크럼 팀
____팀
____스크럼마스터
____제품 책임자
__고객과 이해관계자
__돼지와 닭
__스크럼 크기 조정
__요약
__추가 자료

4장 스프린트
__큰 그림
__계획하기
____스프린트 우선순위 결정
____스프린트 계획하기
____길이
__진척 추적하기
____작업 카드
____번다운 차트
____일일 스프린트 백로그 추세
____작업 보드
____전략 회의실
__일일 스크럼 회의
__실천방안
__스프린트 검토
____단일 팀 검토
____멀티 팀 검토
____게임회사 이해관계자
____스튜디오 이해관계자
____정직한 피드백
__회고
____회의
____결과 게시 및 추적
__스프린트 실패
____스프린트 중단
____스프린트 리셋
____팀이 실패했을 때
____작업 부족
__요약
__추가 자료

5장 사용자 스토리
__운명적인 만남
__사용자 스토리란 무엇인가
__상세 수준
__만족 조건
__사용자 스토리 인덱스 카드 사용
__사용자 스토리의 INVEST
____독립적이다
____협상 가능하다
____가치가 있다
____추정 가능하다
____적절한 크기다
____테스트 가능하다
__사용자 역할
__완료 정의
__스토리 수집
__사용자 스토리의 장점
____대면 의사소통
____사용자 스토리는 모두가 이해할 수 있다
__요약
__추가 자료

6장 애자일 계획
__왜 애자일 계획인가
__제품 백로그
____제품 백로그 우선순위 결정
____지속적인 계획
____미래 예측
__스토리 크기 추정
____추정에 얼마나 많은 노력을 기울여야 하는가
____스토리 크기는 얼마만큼 추정해야 하는가
____스토리 점수
____플래닝 포커
____스토리 점수 크기와 피보나치 수열
____이상적인 작업일
릴리스 계획
____릴리스 계획 회의
____계획 발표
____릴리스 계획 갱신
____잡지 데모와 경화 스프린트
__요약
__추가 자료

3부 애자일 게임 개발
7장 비디오 게임 프로젝트 계획
__<미드나잇 클럽> 이야기
__최소 요구 피처 목록
__단계의 필요성
__개발 단계
__단계 혼합
__릴리스로 단계 관리
__애자일 프로젝트에서의 프로덕션
____프로덕션 빚
____프로덕션에서 스크럼의 어려움
____린 프로덕션
____스크럼으로 작업하기
____스크럼 팀 전환
__요약
__추가 자료

8장 팀
__좋은 팀
__팀에 대한 스크럼 접근법
____다분야통합 팀
____자기 관리
____자기 조직화
____팀 크기
____리더
__게임 팀과 협업
____피처 팀
____기능 팀
____프로덕션 팀
____공용 기반 환경 팀
____도구 팀
____풀 팀
____통합 팀
__스크럼 크기 조정과 분산
____대형 팀의 문제
____스크럼의 스크럼
____제품 책임자의 계층 구조
____스프린트 날짜 맞춤
____실천방안 커뮤니티
____종속성 피하기
____분산 팀
__요약
__추가 자료

9장 빠른 반복
__반복 오버헤드는 무엇으로부터 비롯되는가
__반복 시간 측정 및 표시
____반복 시간 측정
____반복 시간 표시
__개인 반복과 빌드 반복
____개인 반복
____빌드 반복
__요약
__추가 자료

4부 애자일 관심 분야
10장 애자일 기술
__문제
____불확실성
____변경이 문제를 야기
____늦은 변경의 비용
____초기에 너무 많은 아키텍처
__애자일 접근법
____익스트림 프로그래밍
____디버깅
____최적화
__요약
__추가 자료

11장 애자일 아트와 음향
__애자일로 해결하는 문제들
__애자일에 대한 우려
__아트 리더
__다분야통합 팀의 아트
____창의적 긴장
____아트 QA
____아트 지식 구축
____'아직 끝나지 않은' 신드롬 극복
____예산
____'마지막 단계' 음향
____프로덕션에서의 협업
__요약
__추가 자료

12장 애자일 설계
__문제
____기획자는 지식을 만들지 않는다
____게임은 마지막에 드러난다
__스크럼으로 설계하기
____모든 팀에 기획자 한 명씩?
____문서의 역할
____차고 바닥의 부품들
____집합 기반 설계
____선임 기획자 역할
____제품 책임자로서의 기획자
__요약
__추가 자료

13장 애자일 QA 및 제작
__애자일 QA
____QA의 문제점
____애자일에서 테스트는 단계가 아니다
__애자일 게임 팀의 QA 역할
____QA를 팀에 소속시켜야 할까, 풀에 두어야 할까
____팀에 몇 명의 테스터가 있어야 하는가
____버그 데이터베이스 사용
____수행 테스트
____QA의 미래
__애자일 제작
____애자일 프로젝트에서 제작자의 역할
____스크럼마스터로서 제작자
____제품 책임자 지원 역할로서 제작자
____제품 책임자로서 제작자
____제작의 미래
__요약
__추가 자료

5부 시작하기
14장 스크럼의 신화와 도전
__은총알 신화
____스크럼은 당신을 위해 모든 문제를 해결해줄 것이다
____스크럼을 사용하는 프로젝트는 항상 제시간에 출시할 수 있다
__두려움, 불확실성, 의심: FUD
____끝없는 개발
____관리 방법에 대한 일시적 유행
____이중 잣대
____변화는 나쁜 것
____끝없는 회의
__스크럼 도전
____프로세스 및 문화 변화를 위한 도구, 스크럼
____스크럼은 작업의 추적이 아닌 가치를 추가
____현재 상태 vs. 지속적인 향상
____화물 숭배 스크럼
____스크럼은 모든 사람을 위한 것이 아니다
____초과근무
____크런치
__요약
__추가 자료

15장 게임회사와 일하기
__어려움
____때 늦은 집중
____마일스톤 대가 지급과 협업
____제한된 반복
____게임기 하드웨어 제작사 문제
____포트폴리오가 날짜를 좌우한다
__신뢰 구축, 두려움 타파
____두려움
____애자일 이해하기
____게임회사 측 제품 책임자
____조기에 프로젝트 어려움을 해결하기
____프로덕션 계획 관리
____두려움 완화
__애자일 계약
____계획보다는 반복
____고정된 출시일
____애자일 프리프로덕션
____스테이지 게이트 모델
__요약
__추가 자료

16장 스크럼 시작하기
__적용의 3단계
____견습생 단계
____숙련 단계
____달인 단계
__적용 전략
____교두보 팀
____대대적인 확산
__요약
__추가 자료

결론