Путеводитель по геймдеву. Как довести проект до конца и в срок? Про бэклог и итерации в разработке

Всем привет! С вами снова Илья - из команды TinyPlay. Сегодня я вновь продолжаю цикл статей про мир разработки игр и хотел бы рассказать об очень важной вещи - менеджменте вашего проекта. И это касается не только команд-разработчиков, но и инди-одиночек. Надеюсь, данная статья будет полезна для вас.

Путеводитель по геймдеву. Как довести проект до конца и в срок? Про бэклог и итерации в разработке

Итак, устраивайтесь по-удобнее, наливайте чаек и погнали изучать мир управления проектами.

Важно. Здесь описаны лишь некоторые методологии, которые помогут вам организовать работу, прикидывать примерные сроки и возможные риски, а также проложить план к релизу проекта. Но это не значит, что это единственно верный путь.

С чего начинается проект?

Прежде всего - написание диздока и концепт-документа, но в этой статье мы опустим стадию пре-продакшна и перейдем непосредственно к самому действу - распределению обязанностей, беклогу и прочим прелестям управления проектом.

Бэклог

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

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

Раскладываем все это на бэклог и получаем примерно такую табличку:

Путеводитель по геймдеву. Как довести проект до конца и в срок? Про бэклог и итерации в разработке

Итак, что мы имеем здесь и чем это нам помогает?

  • Детальный разбор каждой задачи, поэтапно;
  • Определяем порядок действия в зависимости от связей;
  • Расставляем приоритет задачам;
  • Можем примерно набросать затрачиваемое время на реализацию;

Чем подробнее вы разложите ваш концепт-документ, тем проще будет дальнейшее планирование вашей разработки. То же самое касается и арта, и других составляющих проекта. Бэклог определяет дальнейшую дорожную карту на весь период разработки проекта.

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

Для начала проекта - лучше сделать 1 спринт = 1 неделя.

Таким образом - вы можете добавить колонку "Спринт" в ваш бэклог и разбить его с распределением, в зависимости от ресурсов. Допустим, что у вас один разработчик, который может работать по 30 часов в неделю. Таким образом (на примере бэклога выше) мы получаем примерно 2 спринта + 4 часа. Также не забываем закладывать время на фиксы багов и другие непредвиденные вещи и получаем примерно 2,5 спринта, что в нашем случае равно 2,5 недели:

Путеводитель по геймдеву. Как довести проект до конца и в срок? Про бэклог и итерации в разработке

Итак вы уже будете понимать, сколько времени уйдет на ваши задачи, примерно знать приоритет и итерации в разработке.

Также для наглядности приложу шаблон бэклога:

Как декомпозировать проект?

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

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

Примером смещения сроков из-за плохо проработанного бэклога может быть такая ситуация: вы не учли, что для разработки контроллера игрока требуется 3D модель с анимациями игрока, поскольку некоторые действия завязаны на анимации и нужно понимать, как она будет выглядеть. Из-за того, что вы слабо проработали приоритезацию - вы получаете момент, когда разработчику приходится ждать художника, потому что его следующая задача может зависеть от контроллера игрока.

Итерационный подход к проекту

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

Один из самых простых вариантов - использование досок (канбанов) со статусами задач. Обычно их 3 - что нужно сделать, в работе и готовые:

Путеводитель по геймдеву. Как довести проект до конца и в срок? Про бэклог и итерации в разработке

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

В начале каждого отрезка вы проводите небольшие митинги (встречи) на которых обсуждаете свои планы на неделю.

Итоги итераций (спринтов) и стопы

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

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

Что стоит задеть на подведении итогов за спринт?

  • Разобрать что готово, а что не готово;
  • Оценить эффективность работы;
  • Обсудить проблемные места (к примеру, вы что-то не учли в бэклоге) и доработать дорожную карту;

Исходя из этих итогов вы сможете примерно скорректировать свои планы на следующий спринт и понять, на что лучше требуется обращать внимание в работе.

Оценка своей эффективности

Здесь все достаточно просто - вы берете количество затраченного времени на задачи и количество времени, которое было запланировано. И из этих двух показателей вы получаете некую примерную оценку эффективности своей работы.

Путеводитель по геймдеву. Как довести проект до конца и в срок? Про бэклог и итерации в разработке

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

Полезные ссылки для изучения:

Про бэклог, agile и другую информацию достаточно много статей, поэтому просто оставлю ссылку на статьи Atlassian:

Простые такс-трекеры и системы управления проектами:

Итоги

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

Таким образом это повышает ваши шансы на реализацию проекта в более сжатые сроки и его жизнеспособность в целом.

Ну и прилагаю небольшой опрос для вас:

Вы разрабатываете бэклог вашей игры?
Да
Нет, иду сразу в бой и продумываю все на ходу

И как всегда, буду рад услышать о вашем опыте и узнать, как вы организуете работу над своим проектом и оцениваете сроки его реализации.

4040 показов
3K3K открытий
22 репоста
28 комментариев

Какоето скрамНО
Щас бы планирование спринта(который должен быть минимум 2 недели) желать в экселе, когда цивилизованные люди юзают бесплатный миро
Надеюсь автор выложил сий позор на хабр и его погнали оттуда ссаными тряпками

Ответить

я поставил минус, потому что вы критикуете образовательный пост

мы, живущие в джире годами, забываем, что образовательный пост должен быть понятен и тем, что джиру в глаза не видал

а если вы живете в миро, а не в джире - то тогда и вам нечем гордиться, и зачем тогда кичиться? Всегда найдется человек опытнее и сильнее.

Давайте с уважением относиться к новичкам и особенно с уважением - к образовательным постам.

Ответить

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

Ответить

Он относительно новый и я его ещё не смотрел, но обязательно гляну. Я просто предоставил пару наиболее простых примеров, чтобы не тащить огромные джиры в этот список, которые маленьким командам нафиг не упадут

Ответить