Ознакомительная версия. Доступно 11 страниц из 52
членам команды знать, чем заняты остальные. Scrum должен обеспечивать прозрачность процессов и результатов, так что обычно с такой встречи и начинается рабочий день. Хороший стенд-ап длится недолго. Достаточно, чтобы каждый за пару минут обозначил, каких результатов добился вчера, какие у него планы на сегодня и есть ли какие-то проблемы, мешающие выполнению задачи. Возможные трудности не должны решаться здесь и сейчас, лучше назначить отдельное обсуждение, а на следующем собрании обозначить, что было сделано, чтобы исправить положение.
7. По пятницам обычно команда собирается для ОБЗОРА СПРИНТА (ДЕМО): обсуждаем прошедшую неделю, удалось ли воплотить в жизнь все запланированное, показываем заказчику результаты. Хорошей практикой считается, когда демо проводят не одни и те же люди, это дает разным сотрудникам ощущение причастности к проекту.
8. РЕТРОСПЕКТИВУ СПРИНТА лучше проводить также в конце недели, но отдельно от демо. Этот этап – позитивная точка окончания рабочей недели. Здесь не обсуждают задачи (мы уже все обсудили во время демо); это время обсуждения проекта без давления, с целью укрепления командного духа. Правильное окончание ретроспективы: «Ребята, всем спасибо, на сегодня работать закончили, на кухне вас ждет пицца».
Недельная итерация завершилась, можем двигаться к пункту 5 и планировать следующий спринт.
Пункты 5–8 идут циклично. Так что логично планировать спринт в один и тот же день, например в понедельник, чтобы поставить задачи на неделю.
Еще бывает практика больших собраний гейм-дизайнеров, где каждый может высказать свое мнение, идет ли проект в правильном направлении. Например, кто-то в команде может считать, что мы выбрали неправильный арт-стиль и наша игра только выиграет, если мы сменим сеттинг киберпанка на фэнтези. Можно поручить арт-директору еще раз провести исследование, и, даже если решение не изменится, человек будет видеть, что к нему прислушались. Такие собрания особенно эффективно проводить перед планированием.
Зачастую административные процессы (зарплаты, часы работы и пр.) устанавливаются руководителем для всей компании, продуктовые же – можно менять, исходя из команды и проекта: это нормально, если проектный менеджер предпочитает работать, например, в Trello, а лид программистов любит развешивать на доске бумажки. Хотя руководители некоторых игровых компаний настаивают на одинаковых методологиях и подходах для всех проектов студии.
Проектное управление на этапе препродакшен
Классическое проектное управление помогает компаниям укладываться в сроки, выполняя обязательства, а инди-разработчикам дает возможность построить процессы таким образом, чтобы хотя бы довести проект до релиза.
Цель предлагаемых нами моделей – выпустить качественный проект в срок, потратив определенные, в том числе денежные, ресурсы. Поэтому, если вы инди-одиночка, который делает игру для себя и рискует только тратой собственного времени (что, конечно, тоже нежелательно), тщательная подготовка ко всем этапам может быть необязательной. Если что-то пойдет не так, вы просто поработаете над игрой лишний месяц/год. Если вы при этом учитесь или работаете, как обычно, и уверены, что страсть доделать игру не пропадет, то в общем-то в этом нет ничего страшного. Если же время, которое вы тратите на создание игры, не позволяет полноценно зарабатывать, а, как говорится, надо кормить семью, риски многократно возрастают.
Игровые компании в свою очередь рискуют миллионами долларов, и для них правильное построение процессов критично: даже один убыточный проект – это риск закрытия студии навсегда.
Без предварительной документации довольно трудно понять, какие сотрудники на каком этапе разработки могут понадобиться. Ваша идея должна обрести новую форму, которая поможет ответить на этот вопрос. У проекта уже есть концепт, вижн, теперь предстоит еще немного углубиться в детали и составить FEATURE-ЛИСТ.
Это краткое описание всех фичей, из которых состоит игра, например строительство базы, клановые бои, система повышений и т. д. Также этот документ – анализ всех действий с точки зрения приоритетов и временных затрат. Он состоит из списка задач, категории, к которой можно отнести задачу (программный код, графика и т. д.), и времени на реализацию. Можно просто оценить задачи одной строкой по времени, а можно разбить по этапам (препродакшен, продакшен или релиз).
Обычно такой документ составляется в два этапа: первый раз вы встречаетесь всей командой и просто составляете полный список фичей, затем каждый ответственный заполняет свою часть. Вторая встреча посвящена согласованию этих оценок, после чего можно приступать к планомерной работе. Грамотно составленный feature-лист может сэкономить в будущем уйму времени.
Многие разработчики, особенно начинающие, игнорируют этот документ, так как неопытным специалистам составлять его нелегко. В этом случае можно обойтись просто оценкой бэклога, о которой мы писали выше, когда говорили о Scrum. Однако помните, что без feature-листа вы сможете оценить общее время разработки игры только очень приблизительно. Именно на основании этого документа вы (ваш продюсер или ПМ) будете ставить конкретные сроки для своих задач.
Рис. 12. Пример feature-листа
Чтобы не терять понимания, когда мы вообще сможем запустить проект, лучше заранее составить майлстоуны[39]. Допустим, мы насчитали 10 фичей, по одному месяцу на реализацию каждой. Так что мы надеемся завершить проект за десять месяцев. Но что должно быть готово, например, на пятом месяце разработки? Укладываемся ли мы в сроки? Если мы хотим сделать клановые войны, логично, что перед этим надо завершить создание самих кланов. Одни фичи могут тянуть за собой другие. Чтобы не блуждать во тьме, мы разбиваем список задач на отдельные большие блоки с конкретными сроками. Для людей, работающих за деньги, это критично, ведь ресурсы нужно распределить так, чтобы их хватило до конца проекта.
Майлстоуны делят на более мелкие итерации, короткие промежутки времени, за которые необходимо успеть сделать определенный набор фичей. Если задачи комплексные, лучше разбивать их на более мелкие.
Обычно в feature-листе вы можете найти ссылку на отдельные части ГДД (гейм-дизайн-документа) с более подробным описанием каждой задачи.
Рис. 13. Майлстоун проекта
ФИЧЕКРИП[40] И ФИЧЕКАТ[41]
Обычно жанр определяет некоторое количество игровых фичей, ожидаемых игроками. Гейм-дизайнеры стараются добавить также несколько свежих фичей, чтобы выделить свой проект среди конкурентов и чтобы игра стала интереснее. Принимая решение, гейм-дизайнеры всегда должны проанализировать три вещи: насколько фича полезная, насколько рискованная и насколько дорогая (сколько человеко-часов нужно для ее реализации).
Ошибки в оценках чаще всего происходят из-за того, что геймдизайнер не смог объяснить исполнителям, что именно представляет собой фича, над которой им предстоит работать. Особенно это актуально для экспериментальных проектов и команд новичков. Если на проекте нет ни одного опытного
Ознакомительная версия. Доступно 11 страниц из 52
