실전 애자일 게임 개발 (Agile Game Development From The Trenches) <ul><ul><li>강연 :  Noel Llopis( llopis@convexhull.com) </li></ul></...
 
왜  Agile 인가 ?
Agile Development 란 ? <ul><li>[ 상황에 따라 ]  적시에 결정한다 . </li></ul><ul><li>변화에 적응 ( Adapt to change) 한다 . </li></ul><ul><li>꼭 ...
Agile Development 란 ? 출발 도착 출발 도착 출발 원래 목표 도착
 
Agile 의 실천 사항들 ( Practices) 익스트림 프로그래밍 고객에 의한 테스트 테스트 주도 개발 공동 소유권 코딩 표준 짝 프로그래밍 리팩토링 안정적인 속도 단순한 설계 계속적인 통합 작고 빈번한 출시 계획 ...
Agile 의 실천 사항들 ( Practices) 상호 검토 (Peer Review) 짝 프로그래밍 유니트 테스트 자동화된 일일 구축 정적 분석과 프로파일링 도구들 형상 관리 (Source Control) 코딩 표준 코...
자동화된 구축 <ul><li>이제는 보편화된 사항 . </li></ul><ul><li>한 방에 완전 구축 .  복잡한 절차 없음 . </li></ul><ul><li>다른 기법들을 위한 필수 사항 . </li></ul>
자동화된 구축 <ul><li>경고 : </li></ul><ul><ul><li>빌드는 치명적인 오류가 없고 ,  신뢰할 수 있는 것이어야 한다 . </li></ul></ul><ul><ul><li>빠르면 빠를수록 좋다 . ...
자동화된 테스트 <ul><li>유니트 테스트 :  각 함수와 클래스 단위로 시행한다 . </li></ul><ul><li>기능 테스트 :  프로그램 전체나 그 일부에 시행한다 . </li></ul><ul><li>완전 자동...
 
자동화된 테스트
<ul><li>경고 : </li></ul><ul><ul><li>충분히 신뢰할 수 있는 것이어야 한다 . </li></ul></ul><ul><ul><li>반드시 자주 시행해야 하며 ,  모든 사람들은 테스트가 성공적으로 ...
계속적인 통합 <ul><li>작고 매우 빈번한 체크 - 인 .  ( 약  3~5 분 마다 .) </li></ul><ul><li>코드가 체크 - 인 되자마자 ,  구축이 시작된다 . </li></ul><ul><li>구축이...
 
계속적인 통합 <ul><li>우리만의 규칙 :  어느 누구도 자신의 마지막 체크 - 인이 제대로 구축되는지 확인될 때까지 퇴근할 수 없다 . </li></ul><ul><li>구축을 빨리 하면 할수록 좋다 .  따라서 논...
계속적인 통합 <ul><li>경고 : </li></ul><ul><ul><li>적절한 자동화된 구축과 테스트를 필요로 한다 . </li></ul></ul><ul><li>다음의 경우 ,  사용하지 말 것 : </li></u...
한 방에 몰아넣기 ( Team Co-Location)
<ul><li>경고 : </li></ul><ul><ul><li>소란스러워지지 않도록 주의한다 .  공적인 영역과 사적인 영역을 분리하고 ,  조용한 분위기를 권장할 것 . </li></ul></ul><ul><li>다음의...
코드 공동 소유 <ul><li>“ 코드 소유권의 실종 (no code ownership)” 이 아닌 ,  진정한   코드 공동 소유 . </li></ul><ul><li>유니트 테스트와 공유하고 있는 배경 지식에 달려 있...
코드 공동 소유 <ul><li>경고 : </li></ul><ul><ul><li>“ 코드 소유권의 실종 (no code ownership)” 에 주의할 것 ! </li></ul></ul><ul><ul><li>비록 사람들이...
안정적인 속도 <ul><li>장기적인 생산성을 극대화하도록 한다 . </li></ul><ul><li>근무 시간에는 집중적으로 열심히 일하되 ,  그 뒤에는 집에서 편히 쉬도록 한다 . </li></ul>
안정적인 속도
안정적인 속도 시간 업무 강도 계획 구현 Alpha Beta 출시 주기
안정적인 속도 <ul><li>경고 : </li></ul><ul><ul><li>출근 도장만 찍으면 된다는 생각 ( punch card mentality) 이 만연하지 않도록 한다 . </li></ul></ul><ul><u...
짝 프로그래밍
 
짝 프로그래밍 <ul><li>프로그래머 한 명이 하는 것보다 두 배의 효과가 날까 ? </li></ul><ul><li>약간 낮지만 ( 약  1.7 배 ),  다른 어마어마한 장점들이 있음 : </li></ul><ul><...
짝 프로그래밍 <ul><li>그 밖의 장점 :  강도 높은 근무와 높은 집중력 .  느슨해지거나 ,  늘어질 여유가 별로 없다 . 8 시간 동안 열심히 일하고 나면 기진맥진해진다 ! </li></ul>
짝 프로그래밍 <ul><li>경고 : </li></ul><ul><ul><li>일부 사람들은 좋아하지 않음 . </li></ul></ul><ul><ul><li>모든 것을 짝 프로그래밍으로 개발할 필요는 없음 . </li>...
테스트 주도 개발 (TDD) 체크 - 인 체크 - 인 테스트 작성 코드 작성 리팩토링
TDD  의 장점 :   단순함 ,  모듈화
TDD  의 장점 :   안전망
TDD  의 장점 :   문서화
TDD !=  유니트 테스트 TDD   !=  테스팅 전략 TDD ==  개발 기법
TDD 를 사용하고는 싶지만…
테스트 주도 개발 <ul><li>경고 : </li></ul><ul><ul><li>초반에 생산성의 하락이 있음 . </li></ul></ul><ul><ul><li>저질의  codebase 를 다루는 것은 어려울 뿐만 아니...
추가 정보 <ul><li>Games from Within </li></ul><ul><li>http://www.gamesfromwithin.com   </li></ul><ul><li>Agile Game Developmen...
Upcoming SlideShare
Loading in …5
×

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

2,314 views
2,204 views

Published on

Noel Llopis가 Montreal International Game Summit 2006에서 발표한 내용을 번역.

Agile 중에서 XP에 대해서 주로 다룸.

자세한 것은 http://betterways.tistory.com/51 참조.

Source: http://www.gamesfromwithin.com/articles/0611/000112.html

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,314
On SlideShare
0
From Embeds
0
Number of Embeds
37
Actions
Shares
0
Downloads
78
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • 실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)

    1. 1. 실전 애자일 게임 개발 (Agile Game Development From The Trenches) <ul><ul><li>강연 : Noel Llopis( llopis@convexhull.com) </li></ul></ul><ul><ul><li>Senior Architect, High Moon Studios </li></ul></ul><ul><ul><li>번역 : 김기웅 ( [email_address] ) </li></ul></ul><ul><ul><li>betterways.wo.to </li></ul></ul>
    2. 3. 왜 Agile 인가 ?
    3. 4. Agile Development 란 ? <ul><li>[ 상황에 따라 ] 적시에 결정한다 . </li></ul><ul><li>변화에 적응 ( Adapt to change) 한다 . </li></ul><ul><li>꼭 필요하지 않은 것을 최대한 덜 개발한다 . ( Maximize work not done.) </li></ul>
    4. 5. Agile Development 란 ? 출발 도착 출발 도착 출발 원래 목표 도착
    5. 7. Agile 의 실천 사항들 ( Practices) 익스트림 프로그래밍 고객에 의한 테스트 테스트 주도 개발 공동 소유권 코딩 표준 짝 프로그래밍 리팩토링 안정적인 속도 단순한 설계 계속적인 통합 작고 빈번한 출시 계획 게임 포괄적인 팀 메타포
    6. 8. Agile 의 실천 사항들 ( Practices) 상호 검토 (Peer Review) 짝 프로그래밍 유니트 테스트 자동화된 일일 구축 정적 분석과 프로파일링 도구들 형상 관리 (Source Control) 코딩 표준 코딩 재사용 일일 회의 공동 설계 리팩토링 계속적인 통합 TDD
    7. 9. 자동화된 구축 <ul><li>이제는 보편화된 사항 . </li></ul><ul><li>한 방에 완전 구축 . 복잡한 절차 없음 . </li></ul><ul><li>다른 기법들을 위한 필수 사항 . </li></ul>
    8. 10. 자동화된 구축 <ul><li>경고 : </li></ul><ul><ul><li>빌드는 치명적인 오류가 없고 , 신뢰할 수 있는 것이어야 한다 . </li></ul></ul><ul><ul><li>빠르면 빠를수록 좋다 . </li></ul></ul><ul><ul><li>코드와 그래픽 소스 (assets) 에 모두 사용한다 . 게임 전반에 적용할 것 . </li></ul></ul><ul><li>다음의 경우 , 사용하지 말 것 : </li></ul><ul><ul><li>그저 실행하라 . 하지 말아야 할 이유 따윈 없다 . </li></ul></ul>
    9. 11. 자동화된 테스트 <ul><li>유니트 테스트 : 각 함수와 클래스 단위로 시행한다 . </li></ul><ul><li>기능 테스트 : 프로그램 전체나 그 일부에 시행한다 . </li></ul><ul><li>완전 자동화 . 빌드 서버에서 최소 하루에 한 번씩은 시행한다 . (High Moon </li></ul><ul><li>Studios 는 매 2 시간마다 시행 .) </li></ul><ul><li>동시에 목표로 하는 플랫폼들에서도 </li></ul><ul><li>테스트한다 . </li></ul>
    10. 13. 자동화된 테스트
    11. 14. <ul><li>경고 : </li></ul><ul><ul><li>충분히 신뢰할 수 있는 것이어야 한다 . </li></ul></ul><ul><ul><li>반드시 자주 시행해야 하며 , 모든 사람들은 테스트가 성공적으로 끝나도록 도울 책임 있다 . </li></ul></ul><ul><li>다음의 경우 , 사용하지 말 것 : </li></ul><ul><ul><li>게임이 불안정하거나 , 테스트가 실패할 거라고 예상되는 경우 . </li></ul></ul><ul><ul><li>값싼 인력을 어마어마하게 갖고 있을 경우 . ( 아마도 .) </li></ul></ul>자동화된 테스트
    12. 15. 계속적인 통합 <ul><li>작고 매우 빈번한 체크 - 인 . ( 약 3~5 분 마다 .) </li></ul><ul><li>코드가 체크 - 인 되자마자 , 구축이 시작된다 . </li></ul><ul><li>구축이 실패할 경우 , 즉시 사람들에게 알린다 . </li></ul><ul><li>유니트 테스트는 게임을 안정화시키는데 매우 유용하다 . </li></ul><ul><li>CruiseControl.Net 강추 ! </li></ul>
    13. 17. 계속적인 통합 <ul><li>우리만의 규칙 : 어느 누구도 자신의 마지막 체크 - 인이 제대로 구축되는지 확인될 때까지 퇴근할 수 없다 . </li></ul><ul><li>구축을 빨리 하면 할수록 좋다 . 따라서 논리적이고 물리적인 의존 관계에 주의를 기울일 것 . ( 일반적인 체크 - 인에 대한 응답 시간은 보통 10~20 초 정도 .) </li></ul><ul><li>단 , Unreal Engine 의 경우에는 훨씬 </li></ul><ul><li>오래 걸림 . </li></ul>
    14. 18. 계속적인 통합 <ul><li>경고 : </li></ul><ul><ul><li>적절한 자동화된 구축과 테스트를 필요로 한다 . </li></ul></ul><ul><li>다음의 경우 , 사용하지 말 것 : </li></ul><ul><ul><li>주요 분기점 ( Main branch) 이 불안정할 때 . ( 통합하기 전에 고쳐라 !) </li></ul></ul><ul><ul><li>서로 다른 여러 분기점들에서 동시 에 작업을 해야 할 때 . </li></ul></ul>
    15. 19. 한 방에 몰아넣기 ( Team Co-Location)
    16. 20. <ul><li>경고 : </li></ul><ul><ul><li>소란스러워지지 않도록 주의한다 . 공적인 영역과 사적인 영역을 분리하고 , 조용한 분위기를 권장할 것 . </li></ul></ul><ul><li>다음의 경우 , 사용하지 말 것 : </li></ul><ul><ul><li>팀원들이 물리적으로 서로 멀리 떨어져 있을 경우 . </li></ul></ul>한 방에 몰아넣기 ( Team Co-Location)
    17. 21. 코드 공동 소유 <ul><li>“ 코드 소유권의 실종 (no code ownership)” 이 아닌 , 진정한 코드 공동 소유 . </li></ul><ul><li>유니트 테스트와 공유하고 있는 배경 지식에 달려 있다 . </li></ul>
    18. 22. 코드 공동 소유 <ul><li>경고 : </li></ul><ul><ul><li>“ 코드 소유권의 실종 (no code ownership)” 에 주의할 것 ! </li></ul></ul><ul><ul><li>비록 사람들이 모든 codebase 를 작성하지 않았더라도 , codebase 를 자랑스럽게 여기도록 한다 . </li></ul></ul><ul><li>다음의 경우 , 사용하지 말 것 : </li></ul><ul><ul><li>유니트 테스트를 하지 않는 경우 . </li></ul></ul><ul><ul><li>완전히 다른 분야의 전문가들로만 구성되어 있을 경우 . </li></ul></ul>
    19. 23. 안정적인 속도 <ul><li>장기적인 생산성을 극대화하도록 한다 . </li></ul><ul><li>근무 시간에는 집중적으로 열심히 일하되 , 그 뒤에는 집에서 편히 쉬도록 한다 . </li></ul>
    20. 24. 안정적인 속도
    21. 25. 안정적인 속도 시간 업무 강도 계획 구현 Alpha Beta 출시 주기
    22. 26. 안정적인 속도 <ul><li>경고 : </li></ul><ul><ul><li>출근 도장만 찍으면 된다는 생각 ( punch card mentality) 이 만연하지 않도록 한다 . </li></ul></ul><ul><ul><li>팀이 함께 하기 위해서 , 더 강도 높은 집중 근무 시간 (tighter core hours) 이 필요하다 . </li></ul></ul><ul><li>다음의 경우 , 사용하지 말 것 : </li></ul><ul><ul><li>장기적인 측면에 신경 쓰지 않거나 , 신입 개발자들을 무제한 고용할 수 있을 경우 </li></ul></ul>
    23. 27. 짝 프로그래밍
    24. 29. 짝 프로그래밍 <ul><li>프로그래머 한 명이 하는 것보다 두 배의 효과가 날까 ? </li></ul><ul><li>약간 낮지만 ( 약 1.7 배 ), 다른 어마어마한 장점들이 있음 : </li></ul><ul><ul><li>훨씬 좋은 품질의 코드 </li></ul></ul><ul><ul><li>지식 / 철학의 확산 </li></ul></ul><ul><ul><li>공동체 정신 ( Team spirit) </li></ul></ul><ul><li>장기적인 측면에서는 커다란 이익 . </li></ul>
    25. 30. 짝 프로그래밍 <ul><li>그 밖의 장점 : 강도 높은 근무와 높은 집중력 . 느슨해지거나 , 늘어질 여유가 별로 없다 . 8 시간 동안 열심히 일하고 나면 기진맥진해진다 ! </li></ul>
    26. 31. 짝 프로그래밍 <ul><li>경고 : </li></ul><ul><ul><li>일부 사람들은 좋아하지 않음 . </li></ul></ul><ul><ul><li>모든 것을 짝 프로그래밍으로 개발할 필요는 없음 . </li></ul></ul><ul><li>다음의 경우 , 사용하지 말 것 : </li></ul><ul><ul><li>숙련된 고참 프로그래머들로 이루어진 작은 팀 . </li></ul></ul>
    27. 32. 테스트 주도 개발 (TDD) 체크 - 인 체크 - 인 테스트 작성 코드 작성 리팩토링
    28. 33. TDD 의 장점 : 단순함 , 모듈화
    29. 34. TDD 의 장점 : 안전망
    30. 35. TDD 의 장점 : 문서화
    31. 36. TDD != 유니트 테스트 TDD != 테스팅 전략 TDD == 개발 기법
    32. 37. TDD 를 사용하고는 싶지만…
    33. 38. 테스트 주도 개발 <ul><li>경고 : </li></ul><ul><ul><li>초반에 생산성의 하락이 있음 . </li></ul></ul><ul><ul><li>저질의 codebase 를 다루는 것은 어려울 뿐만 아니라 사기를 떨어뜨림 . </li></ul></ul><ul><ul><li>모든 사람이 함께 적용해야만 함 . </li></ul></ul><ul><li>다음의 경우 , 사용하지 말 것 : </li></ul><ul><ul><li>일회용 (throwaway) 코드를 작성하고 있고 , 다시 사용하지 않을 경우 . </li></ul></ul><ul><ul><li>초반의 하락을 감당할 수 없을 경우 . </li></ul></ul>
    34. 39. 추가 정보 <ul><li>Games from Within </li></ul><ul><li>http://www.gamesfromwithin.com </li></ul><ul><li>Agile Game Development </li></ul><ul><li>http://www.agilegamedevelopment.com </li></ul>질문 ?

    ×