Хочу в геймдев!

3. Далее СОЗДАЕМ БЭКЛОГ – хранилище всех идей, связанных с проектом. Во многом Scrum – про демократию, так что обычно любой участник команды может внести свою идею для дальнейшего ее обсуждения с командой. К тому же, когда каждый может высказаться, уменьшается риск пропустить эффективное решение.

Бэклог постоянно дополняется новыми инициативами и идеями, так что ситуация, когда ваша игра давно в сторах (магазинах), хотя в бэклоге полно невыполненных задач, встречается нередко.

4. Потом команда собирается, чтобы обсудить и ОЦЕНИТЬ ЗАДАЧИ. Молодым командам сложно сразу правильно определить, сколько времени и ресурсов уйдет на то или иное действие. Определите хотя бы два параметра: длительность (насколько задача трудоемкая) и риски (что может пойти не так).

В игровых студиях, работающих по Agile, исполнители часто сами оценивают поставленные задачи. Иногда эту функцию берет на себя Scrum-мастер, например если сотрудник – новичок или ранее он уже оценивал свои задачи неправильно.

5. Далее ПЛАНИРУЕМ СПРИНТ. Мы просмотрели, оценили наши задачи и убедились, что можем уложиться в сроки спринта (это может быть неделя, две недели, три недели, месяц).

Спринт – это итерация. Он жестко фиксирован по времени, и каждая команда определяет для себя оптимальный срок спринта. Чем он короче, тем более гибким становится процесс разработки, меньше ресурсов тратится на неправильные задачи, чаще демонстрируется результат. Однако есть риск много времени и сил тратить на презентации продукта и совещания.

Современный подход говорит о том, что директивно раздавать задачи – не всегда эффективно. Если никто в команде не хочет браться за какую-то задачу, это повод обсудить, насколько проекту вообще она нужна. Это верно для небольших команд. Для крупных комплексных проектов, где все фичи взаимосвязаны (ММО, MOBA и пр.), такое решение может мгновенно привести к коллапсу, так что следует быть осторожным. Однозначных ответов здесь нет, все зависит от конкретной команды и проекта.

6. ЕЖЕДНЕВНЫЙ СТЕНД-АП позволяет всем членам команды знать, чем заняты остальные. Scrum должен обеспечивать прозрачность процессов и результатов, так что обычно с такой встречи и начинается рабочий день. Хороший стенд-ап длится недолго. Достаточно, чтобы каждый за пару минут обозначил, каких результатов добился вчера, какие у него планы на сегодня и есть ли какие-то проблемы, мешающие выполнению задачи. Возможные трудности не должны решаться здесь и сейчас, лучше назначить отдельное обсуждение, а на следующем собрании обозначить, что было сделано, чтобы исправить положение.

7. По пятницам обычно команда собирается для ОБЗОРА СПРИНТА (ДЕМО): обсуждаем прошедшую неделю, удалось ли воплотить в жизнь все запланированное, показываем заказчику результаты. Хорошей практикой считается, когда демо проводят не одни и те же люди, это дает разным сотрудникам ощущение причастности к проекту.

8. РЕТРОСПЕКТИВУ СПРИНТА лучше проводить также в конце недели, но отдельно от демо. Этот этап – позитивная точка окончания рабочей недели. Здесь не обсуждают задачи (мы уже все обсудили во время демо); это время обсуждения проекта без давления, с целью укрепления командного духа. Правильное окончание ретроспективы: «Ребята, всем спасибо, на сегодня работать закончили, на кухне вас ждет пицца».

Недельная итерация завершилась, можем двигаться к пункту 5 и планировать следующий спринт.

Пункты 5–8 идут циклично. Так что логично планировать спринт в один и тот же день, например в понедельник, чтобы поставить задачи на неделю.

Еще бывает практика больших собраний гейм-дизайнеров, где каждый может высказать свое мнение, идет ли проект в правильном направлении. Например, кто-то в команде может считать, что мы выбрали неправильный арт-стиль и наша игра только выиграет, если мы сменим сеттинг киберпанка на фэнтези. Можно поручить арт-директору еще раз провести исследование, и, даже если решение не изменится, человек будет видеть, что к нему прислушались. Такие собрания особенно эффективно проводить перед планированием.

Зачастую административные процессы (зарплаты, часы работы и пр.) устанавливаются руководителем для всей компании, продуктовые же – можно менять, исходя из команды и проекта: это нормально, если проектный менеджер предпочитает работать, например, в Trello, а лид программистов любит развешивать на доске бумажки. Хотя руководители некоторых игровых компаний настаивают на одинаковых методологиях и подходах для всех проектов студии.

Проектное управление на этапе препродакшен

Классическое проектное управление помогает компаниям укладываться в сроки, выполняя обязательства, а инди-разработчикам дает возможность построить процессы таким образом, чтобы хотя бы довести проект до релиза.