3. 1. 문서 배경
제대로 관리가 이루어지지 못해 연기되는 일정에 대한 원인을 분석하고, 보다 효과적인 관리 방법론에 대해
연구하면서 본 문서를 작성함.
팀 생산성을 높이는 방법론에 대해 고민하면서, 이를 적용하는 방법은 다양하지만, 근본적인 철학을
먼저 이해한 후에, “Live feature 개발프로세스”에 대한 의미를 되새기는 문서이다.
이 방법론은 원리는 같아도 시행하는 관리자/피드백을 주고 받는 실무 담당자/ 팀의 환경 등에 따라서
다양한 방법으로 시행될 수 있으므로, 개발실에서 feature를 개발할 때 어떠한 방법과 의식을 가지고 업무를
수행해야 할지 정리하였다.
3
5. 2. 대 전제
우리의 목표는 성공한 게임을 만드는 것이다.
(여기서 성공은 높은 수익을 창출하는 게임을 의미한다.)
우리가 게임을 개발하는데 있어 예상치 못했던 문제점은 반드시 발생하고, 상황은 꼭 변화하게 되어있다.
(최종 결과물, 아니 중간과정에서만 보아도 우리가 처음 생각했던 것과는 반드시 다른 결과물이 우리 앞에 비춰질 것이다.)
잦은 변화와 수정은 위험 신호가 아니며, 필연적인 것이다.
(오히려 작업자는 이러한 변화를 당연하게 받아들이고, 즐길 줄 알아야 하며, 이에 대해 민첩하고 능동적으로 대처해야 한다.)
기획자, 프로그래머, 디자이너는 운명공동체이다. 그들에게 팀의 실패만이 있을 뿐 개인의 실패란 없다.
(그러므로 작업자들은 항상 스스로 최선을 다하고, 다른 사람들도 최선을 다하고 있다는 사실을 잊지 않으며, 항상 팀원을
도와줘야 한다. 그리고 각자의 장단점을 받아들이고 그것을 어떻게 조화시켜 보완해 나갈지 생각한다.)
5
7. 3. 개발 팀 관리 방법 1) 컨셉 회의 준비
컨셉 회의 준비 컨셉 회의 일정 회의 준비 일정 회의 개별 작업 일일 미팅 주간 미팅
기획자가 자신이 주관하게 될 컨셉 회의를 준비하는 단계이다.
기획자는 자신의 기획 의도와 핵심 사항을 명시한 기획서를 준비한다.
기획자는 컨셉 회의에서 완성된 기획문서를 보여주기 위해 많은 시간을 투자하지 말고,
자신이 생각하고 있는 바를 개발자와 디자이너에게 싱크로 시키는 것이 가장 큰 목적임을 인지하고 준비한다.
컨셉 회의에서 각 담당자들과의 브레인스토밍이 이루어질 수 있다.
담당자들이 생각을 가지고 회의에 참석하도록 모임요청 메일에 초안을 첨부하고, 회의개요를 간단히 설명한다.
7
8. 3. 개발 팀 관리 방법 2) 컨셉 회의
컨셉 회의 준비 컨셉 회의 일정 회의 개별 작업 일일 미팅 주간 미팅 QA
각 피쳐의 담당자들이 기획 의도를 이해하고 구현 핵심에 대해 논의하는 단계이다.
실무의 모든 진행은 각 담당자들이 맡게 되므로 파트 장들은 회의에 참석하지 않는다.
하지만 각 담당자들은 회의 전에, 파트 장들과 담당 Feature에 대해 미리 계획/논의를 마친 상태에서 참여한다.
기획자는 컨셉 회의를 주관하면서, 각 담당자들과의 브레인 스토밍을 통해 변화된 기획사항을 정리한다.
컨셉 회의가 끝나면 각 담당자들은 파트 장에게 결과를 보고하고, 일정 회의를 위해 필요한 작업을 시작한다.
1) 기획자는 컨셉 회의에서 나온 의견들을 갈무리하여 세부 기획서를 작성한다.
기획서는 개발자가 백 로그를 쉽게 작성할 수 있도록 기능 별로 구분하여 작성한다.
이 방법에서 마지막 기획서란 없다. 담당자와의 커뮤니케이션 이후 바로 무언가 추가될 수도 있다.
무언가 추가되었다면 한 단계 발전한 기획서가 되는 것이고 오류의 가능성 또한 줄어든다.
어차피 변화는 있을 것이므로 이를 즐길 각오로 용감무쌍하게 기획서를 지른다.
* 다만 생각없이 지르는 것은 용서 받지 못한다. 성심 성의껏 작성하되 수정을 두려워 하지 않아야 한다.
8
9. 3. 개발 팀 관리 방법 2) 컨셉 회의
컨셉 회의 준비 컨셉 회의 일정 회의 개별 작업 일일 미팅 주간 미팅 QA
2) 개발자는 백 로그와 추정 수치(작업 시간)를 정의한다(최대 4~8시간 단위).
한 소프트(일정 공유 소프트웨어)에 등록할 때 한번 더 고려될 내용이므로 작은 단위로 분류될수록 좋다.
기획자가 기획서를 변경하는 것처럼 개발자도 백 로그의 추정 수치나 요소들을 변경할 수 있다.
3) 디자이너는 아트웍 컨셉을 준비하고 핵심 기능을 고려하여 기획자와 기본 레이아웃에 대해 논의한다.
세부 기획서에 논의된 레이아웃이 삽입되도록 충분히 고민한다.
디자이너 또한 디자인을 변경하게 되는 것이 삽질이라고 생각하면 안 된다.
변화를 피할 수 없는 것은 디자인도 예외가 아니다.
* 준비 작업들은 각 담당 파트 장들과 논의되어 있어야 하며, 파트 장들은 해당 내용들을 알고 있어야 한다.
9
10. 3. 개발 팀 관리 방법 3) 일정 회의
컨셉 회의 준비 컨셉 회의 일정 회의 개별 작업 일일 미팅 주간 미팅 QA
각 담당자들이 준비한 내용들을 토대로 일일 미팅과 주간 미팅을 어떤 식으로 진행할 지에 대해 약속을 하는
자리이다.
일정 회의 전에 담당자들은 이미 파트 장들과 논의를 한 상태이므로 일정 회의에도 파트 장은 참석하지 않는다.
기획자는 모임 요청 시에 세부기획서를 미리 공유하고, 주안점에 대해 공지한다.
개발을 어떤 순서로 진행할지에 대한 전체적인 틀을 결정하고, 중간중간의 결과물을 어떠한 방식으로 체크하고
공유할지에 대해 결정한다
1) 개발 순서는 우선 순위가 높은 것을 먼저 진행하고, 가급적 작업 난이도가 높은 것부터 진행하도록 한다.
2) 가급적 자주 공유할 수 있는 방향으로 최대한 고민한다. (결과물 공유가 일주일을 넘기면 안 된다)
자주 공유할수록 오류 및 문제 발생을 빨리 발견할 수 있고, 예측하지 못한 상황에 빠르게 대처할 수 있다.
물론, 작업 Quality도 올릴 수 있다.
일정 회의가 끝나면 각 담당자들은 결과를 파트 장에게 보고한다.
10
11. 3. 개발 팀 관리 방법 4) 개별 작업
컨셉 회의 준비 컨셉 회의 일정 회의 개별 작업 일일 미팅 주간 미팅 QA
일정 회의의 결과를 바탕으로 각 담당자들이 자신의 업무를 좀 더 구체화하여 반영하는 단계이다.
1) 개발자는 ‘한 소프트’(스케줄 공유 프로그램)에 백 로그와 해당 추정치(작업시간)를 정의하고 매일매일
이를 반영한다.
추정은 반복적인 프로세스이므로 추가 정보가 발생하게 되어 있고, 각 항목에 대해 더 잘 이해하게 됨에 따라 계속
변화한다.
팀은 개발자가 정의한 백 로그 추정치에 구속 받지 않는다. 추정치는 추정한 시간 안에 반드시 개발해야 한다는 의미
가 아니다. 추정치는 출발점이며 현 시점에서 관리의 기반이 되는 추측이다.
따라서 개발자는 현재 생각할 수 있는 가장 현실적인 추정치를 산출해서 등록해야 한다. 이를 바탕으로 관리자와
일정을 만들어가야 하기 때문이다.
2) 기획자는 기획서를 구체화하고 등록된 한 소프트를 계속 모니터링 한다.
기획자는 각 Feature의 담당자들이 한 소프트에 백 로그 목록들을 기획 의도대로 보다 수월하게 작성할 수 있도록
기획 문서를 구체화 한다.
일정 또한 백 로그 항목들에서 우선순위가 높은 핵심 기능들 구현에 대한 문제점을 가장 먼저 직면할 수 있도록 한다.
관리자가 한 소프트에서 집중해야 하는 것은 “목표를 얼마나 달성했느냐” 이다. 작업자가 목표달성을 위해 얼마나
많은 시간을 썼는지는 중요하지 않다.
11
12. 3. 개발 팀 관리 방법 4) 개별 작업
컨셉 회의 준비 컨셉 회의 일정 회의 개별 작업 일일 미팅 주간 미팅 QA
* 한 소프트를 모니터링 할 때에는, 예상 진도와 실제 진도를 비교한다. 한 소프트는 프로젝트의 진행 속도를 객관적인
지표로 보여주므로, 이를 모니터링 하면서 팀의 속도를 측정하려고 노력한다. 지금 프로젝트가 예상대로 잘 진행되고
있는가? 제자리 걸음인가? 아니면 우왕좌왕하고 있지는 않은가? 만약 지원이 필요한 상황이라면 문제가 무엇이며,
어떻게 도와줄 수 있는가에 집중한다.
장애가 있다면, 모범을 보여야 하는 관리자는 장애 제거를 위해서 단호한 결단력과 불굴의 의지를 보여야 한다.
한 소프트 모니터링을 통해 리소스/일정/작업 Quality를 조율한다.
3) 디자이너는 일정을 고려하여 Art work 작업을 수행하고, 게임에 적용 시 효율성에 대해 검토한다.
디자이너도 중간 결과물 제출의 예외가 되지 않는다. 중간 결과물의 Visual Quality 조정에 대한 고민을 해야 한다.
디자인 구현이 끝나면, UX를 고려하여, 해당 디자인에 대한 유저 접근성과 편의성에 대해 기획자와 검토한다.
12
13. 3. 개발 팀 관리 방법 5) 일일 미팅
컨셉 회의 준비 컨셉 회의 일정 회의 개별 작업 일일 미팅 주간 미팅 QA
이 관리의 핵심 정의라고 할 수 있는 “피드백을 좀 더 일찍, 좀더 자주 좀더 많이 좀더 지속적으로 주고 받자”
를 실천하는 단계이다.
매일 같은 시간, 같은 장소에서 짧은 시간 동안 Daily meeting을 가진다
(시간을 엄수하고, 어떤 이유던 간에 절대로 Skip하지 않는다.)
회의가 길어지는 것을 방지하기 위해 Standing 회의를 진행하며, 실무자만 참석한다.
회의의 주제는 다음과 같이 고정된다.
1. 지난 일일 미팅 이후 무엇을 했는가? (일정 체크)
: 만약 Feature와 관련된 것 외의 것을 하고 있다면 그것은 장애요소로 취급해야 한다.
2. 다음 일일 미팅까지 무엇을 할 계획인가? (일정 체크)
: 만약 다른 일을 하려고 한다면 반드시 그 이유를 확인해야 하며, 그것에 따라 다른 팀원들도 자신의 기존 업무를 수정해야
한다. 다음 회의까지의 계획을 보면서 관리자는 계획에 맞게 일이 진행되고 있는지, 변경이 필요한지 판단한다.
13
14. 3. 개발 팀 관리 방법 5) 일일 미팅
컨셉 회의 준비 컨셉 회의 일정 회의 개별 작업 일일 미팅 주간 미팅 QA
3. 무엇이 작업을 방해하고 있는가?(특이 사항)
: 만약 계획한대로 업무를 수행할 수 없다면 원인이 무엇인지 작업자에게 직접적으로 전해 들어 원인을 제거해야 한다. 원인을
파악하는 것은 프로젝트가 민첩하게 진행되도록 하는 기본 행위이지만, 개발자가 작업에만 집중할 수 있도록 돕는 행위이기도
하다.
* 이 단계에서는 원인을 최대한 빨리 파악하여 의사 결정을 하는 것이 핵심이다. 설사 잘못된 의사결정일지라도, 작업자가 무언
가에 대한 의사결정을 기다리느라 아무것도 하지 않는 상황은 절대 만들지 않는다.
위 세 가지에 대해 요점만 간결하게 말해야 하며 장황하게 설명해서는 안 된다.
일일 미팅은 설계/작업 회의가 아니니 설계를 논하거나 그에 관련된 문제를 해결하려고 들어서는 안 된다.
: 필요하다면 토론형식의 제약 없는 후속 회의를 별도로 잡아야 한다. 그렇지 않으면 짧은 시간에 이루어지는 현황 파악
회의의 장점을 상실하게 된다.
* 일일 미팅은 단순한 보고로서의 의미 외에, 작업자가 자신의 작업을 한번 되돌아보는 시간을 갖게 한다.
여기서 자신이 생각지도 못했던 오류를 스스로 혹은 다른 작업자로부터 깨닫게 될 수 있다.
대 전제에서도 언급했듯이, 문제는 무조건 발생하게 되어 있다. 일일 미팅을 통해 매일 현재 상황을 보고하고
문제에 대처하므로, 매우 현실 적응적이고, 기민하며, 쉴 틈이 없는 방법이다. 문제가 발생해도 재조정의 기회를
일찍 얻어, 리스크와 불확실 성을 확실하게 감소시킬 수 있다.
14
15. 3. 개발 팀 관리 방법 5) 일일 미팅
컨셉 회의 준비 컨셉 회의 일정 회의 개별 작업 일일 미팅 주간 미팅 QA
일일 미팅의 영향과 기획자의 소명
- 기획자에게 일일 미팅은 스스로 실천해보고 자신의 기획에 대한 확신을 가지는 작업이며, 설득을 위한 기본 작업이다. 기획자
는 일일 미팅을 주관하면서 모범을 보이며, 작업자들이 타이트한 일정을 잘 따라오도록 리드해야 한다. 물론 개발팀이 갑자기
하루아침에 바뀔 수는 없다. 그리고 어떤 사람의 본성은 아예 바뀌지 않을 수도 있다. 하지만 매일매일 어제 한 일과 오늘 하려는
일을 묻는 짧은 모임을 가지는 작은 일부터 시작하다 보면, 팀원들은 자신과 함께 일하는 작업자가 매일 무엇을 하는지를
알게 되고 그들의 작업에 영향을 미치는 내적(일에 대한 흥미 정도, 열의 등)/외적(가족 문제 등) 환경요소도 인지하게 된다.
그들은 미팅을 통해 늘 팀 단위로 항상 움직이면서 서로에 대해 호의도 가지게 되며, 이는 일의 진행에도 상당한 영향을 주게
된다. 혼자 작업을 떠 안고 고민하던 사람들이 마음을 열고 일에서 팀 지향적인 재미를 추구하게 되며, 수동적인 태도를 견지하던
개발 팀원들이 주도적으로 행동하는 팀원으로서 자기조직화를 꾀하게 된다.
- 위에서 언급한 것은 매우 아름다운 케이스지만, 이 관리 방법은 생산적인 팀원만이 살아남는 타이트한 방법론이다. 일주일 안으
로 체크되는 중간 결과물 보고로 인해, 비생산적인 담당자는 일주일 단위로 확연히 드러나게 된다. (물론, 이는 일일 미팅에서의
보고에서도 금방 드러난다)
하지만 작업자들이 이를 두려워하여 작업자가 혼자 고민을 떠안는 현상이 일어나서는 안되며, 기획자는 팀의 솔직하고 투명한
자기조직화를 유도해야 한다.
Feature를 공유하는 각 담당자들이 팀이라는 운명 공동체로서 서서히 바뀌어져 나가도록 노력해야 할 것이다.
15
16. 3. 개발 팀 관리 방법 6) 주간 미팅
컨셉 회의 준비 컨셉 회의 일정 회의 개별 작업 일일 미팅 주간 미팅 QA
일주일 동안 작업한 결과물을 확인하고, 게임의 방향성과 Quality에 대한 토론이 이루어 지는 검토 단계이다.
모든 개발 팀원들은 각 담당자들이 개발한 Feature가 사용자 환경에서 어떻게 돌아가는지 직접 보게 되며,
다음에는 어떤 Contents가 추가 되어야 할지도 고민하게 된다. 이는 새로운 브레인 스토밍의 시작이 될 수
있다. 대부분의 사람이 검토 시에 기획서를 미리 읽어보거나 하지는 않으므로, 해당 Feature의 담당자는
Weekly Build를 시작하기 전에 이번 피쳐의 개요를 간단히 설명해 주는 것이 좋다.
* 만약 일일 미팅과 주간 미팅을 통해 Feature가 Deadline에 맞춰 개발되는 것이 불가능하다면, Feature를
무리하게 업데이트 할 생각을 하면 안 된다. 미팅을 통해 주어진 상황에서 최선을 다했다면, 팀원들은 모두
가장 빠른 시간에 문제점을 파악하였을 것이고, 보고 받은 상급자들도 그 사실을 알고 있을 것이다.
불안정한 Feature를 launching하고 다시 내리는 것이 가장 최악의 상황인 것을 명심하고, 적시에 개발을 완료
할 수 없는 상황이 다가왔을 때, 연기를 두려워 하지 않아야 한다.
16
17. 3. 개발 팀 관리 방법 7) QA
컨셉 회의 준비 컨셉 회의 일정 회의 개별 작업 일일 미팅 주간 미팅 QA
개발을 완료하고 개발 Quality를 높이기 위해 Test가 이루어지는 단계이다.
개발 파트 장은 QA시작 시, Build가 Freeze 되었음을 팀 메일로 선포한다.
QA를 시작한다는 것은, 적어도 그 시점에서는 모든 Contents가 기획의도에 맞게 구성되어 있고, 개발 버그
또한 존재하지 않는다는 것을 의미한다.
이를 위해서는 적어도 QA 시작 1주일 전에는 Feature 전반에 대한 Test를 시작해야 하며, 부분적인 기능 테스트는 평소에
이루어져 있어야 한다.
Contents 완료 여부에 대한 컨펌은 기획 파트 장이 담당하며, 버그 및 개발 이슈에 대한 컨펌은 개발 파트 장이 담당한다.
QA 시점부터 모든 내용들은 팀장의 컨펌을 받아야 한다.
Feature에 관련된 내용은 선 컴펌을 받아야 하며, Bug fix에 관한 내용은 사후 컨펌을 받는다.
17
