[기획] 프로젝트 관리
댓글 0
댓글을 작성하려면 로그인이 필요합니다.
아직 댓글이 없습니다. 첫 번째 댓글을 작성해보세요!
이 세 가지를 해결하기 위한 방법이 1주일 단위 스프린트, 칸반 보드, 그리고 명확하고 단순하지만 엄격한 팀 규칙이다.
애자일은 작고 반복적인 개발 주기를 통해 제품을 만들어가는 방법론이다. 목표나 요구사항, 개발 환경이 수시로 바뀌는 프로젝트에 특히 적합해서, 많은 게임 프로젝트에서 채택하고 있다.
기본 프로세스는 다음 순서로 진행된다.
업무 분해(WBS) → 규모 추정 → 우선순위 결정 → 일정 배치
WBS(Work Breakdown Structure)는 프로젝트 전체를 작은 작업 단위로 쪼갠 작업 분해도다. 처음부터 시간 단위로 쪼개는 게 아니라, 먼저 전체 업무를 큰 기능 덩어리로 나누고 그 다음 각 기능을 다시 시간 단위 작업으로 세분화하는 순서로 진행한다.
이때 각 기능에는 다음 세 가지를 함께 정리해야 한다.
여기서 중요한 건 기획의 완성도다. 기획이 꼼꼼할수록 기능 정리도 정확해지고, 뒤에 나올 추정치와 검증 체크리스트의 품질도 같이 올라간다.
기능마다 아래 네 등급 중 하나를 매긴다.
| 등급 | 의미 |
|---|---|
| M (Must) | 무조건 구현되어야 하는 기능. 이게 없으면 게임의 기본이 안 된다 |
| S (Should) | 되도록 구현할 기능. 있으면 좋지만 시간이 부족하면 뺄 수 있다 |
| C (Could) | 없어도 되지만 있으면 좋은 기능. 난이도가 높아 역량 어필은 크지만 작업 시간 예측이 힘들거나, 있으면 퀄리티는 크게 오르지만 필수는 아닌 기능 |
| W (Won't) | 이번 스프린트/프로젝트에서는 구현하지 않을 기능 |
각 기능을 구현하는 데 걸리는 시간을 산정하는 단계다. 정확하게 추정하려면 결국 그 기능을 다시 WBS로 한 번 더 쪼개봐야 한다.
여기서 실전 팁 하나: 업무 시간을 추정할 때는 반드시 버퍼를 넣어야 한다. 스스로 추정한 시간에 대략 1.5배를 곱해야 실제 소요 시간에 가까워진다. 앞서 말한 "낙관성 추정의 오류"를 시스템적으로 보정하는 장치인 셈이다.
의존성이란 작업 간의 영향 관계를 말한다. 예를 들어 기본적인 애니메이션 시스템이 먼저 구현돼야, 이동 속도에 따라 애니메이션 프레임을 제어하는 시스템도 만들 수 있다. 이 경우 프레임 제어 시스템은 애니메이션 시스템에 의존성이 있는 것이다.
쪼개놓은 작업들을 의존성 단위로 연결해야 업무 배분이 명확해지고, 팀원 간 비는 시간이나 병목이 생기지 않는다. 또한 이 과정에서 처음엔 두루뭉술했던 작업 단위가 더 명확하게 다듬어지는 효과도 있다.
해당 기능이 완벽하게 구현되었음을 증명할 수 있는 테스트 항목이다. 여기서 주의할 점은, 이게 단순히 기능 목록 나열이 아니라는 것이다. 최대한 유저 관점에서 체험할 수 있는 요소 위주로 정리해야 하고, 프로그래밍·기획·그래픽 작업을 모두 아우를 수 있도록 구성해야 한다.
스프린트는 반복적인 개발 주기다. 여기서 핵심은 스프린트가 단순히 하나의 긴 작업을 기간으로만 나눠놓은 게 아니라는 점이다. 각 스프린트는 그 자체로 완결된 형태의 결과물이 나와야 한다. 그래서 매 스프린트의 마무리는 항상 빌드로 끝맺는다.
운영 원칙은 이렇다.
팀의 기본적인 작업 규칙이다. 우리 팀은 이렇게 정했다.
게임 기획이란 - 게임의 핵심 개념을 정리하고 개발 방향성을 설계하는 과정 - 플레이어에게 재미를 제공하기 위한 시스템, 스토리, 인터페이스 등을 구체화 하는 역할 - 개발팀(프로그래머, 아티스트, 사운드 디자이너 등)과 협력하여 게임의 완성도를 높이는 핵심 단계 게임 기획자의 주요 역할 - 게임 컨셉 및 구조 설계 - 게임의 기본 아이디어 및 장르 설정
MDA Framework
XR을 활용한 게임 개발 3기(유니티) 수강생입니다. 곧 수료 하지만 앞으로 이곳에 가끔 저의 개발 경험이 나 지식 기록할까 합니다. 더 나아가 이 사이트가 제 개인위키의 역할을 할 수 있으면 좋겠습니다. 한국 게임 시장을 흔들겠습니다