Методология в работе — Манжеты Гейм-дизайнера
legoman

Методология в работе

Как мы работаем со Scrum

Для начала я хочу написать несколько строк о прошлой статье, не касающейся Scrum. В тот раз я писал о том, каково это — быть инди. Там было много воды и общих слов, в том числе недвусмысленное предупреждение об опасности «пути инди». Но, допустим, вы всё-таки им стали.

Уважаемые господа смотрят на тебя, как на инди

Уважаемые господа смотрят на тебя, как на инди

 

Окей. Следующий вопрос: какое это всё, черт побери, имеет отношение к гейм-дизайну?! Итак, first things first.

Про команду

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

Зачастую инди — это коллектив друзей или хороших знакомых, но и здесь важно соблюдать осторожность, ведь слова ранят!

Не имей 100 рублей

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

Документация

У нас есть вики. Да, говорят, что гейм-дизайнер заполняет вики, которую никто не читает :) Но это неправда. Я документирую все движения по проекту: идеи, фичи, механики, лор, вот это всё, и поддерживаю ее в актуальном состоянии. И мы постоянно обращаемся к ней, как к источнику знаний.

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

Собственно Scrum

SCRUM, как много в этом слове

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

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

Начинается всё с предпродакшена (х**к-х**к… — не путь инди!), в котором формируется список ключевых элементов игры, ее видение. Например «в игре можно отрыть свой лунапарк, с блэкджеком и шлю…». Это еще не конкретные задачи, скорее, видение будущей игры. Такой список называется backlog, а сами элементы называются историями — user story. За backlog отвечает Product owner, иными словами — заказчик, который расставляет приоритеты между ними. Он должен понимать про истории всё: зачем та или иная нужна. В идеале это отдельный человек, не входящий в состав команды разработки, но если вы — инди, то backlog заполняется совместными усилиями. На мой взгляд в этом нет ничего критичного, просто занимает больше времени.

Далее, элементы backlog’а превращаются в настоящие задачи и попадают в Sprint backlog, с которым уже работает команда.

Вся методология основана на нескольких принципах, рассмотрим их ниже.

Итерации

Доска — очень полезная штука

Весь процесс разработки делится на итерации (спринты) — это ограниченные по времени этапы. Обычно этап длится от недели до трех, это зависит от темпа выполнения задач, который возьмет команда. Разбиение процесса разработки на этапы позволяет видеть изменения, привнесенные новыми задачами и проверять прогресс поставленных целей. Например, введение в билд нового моба. Конечно, для гейм-дизайнера это — сказка, ведь есть возможность пощупать моба в свежем билде, протестить и, при необходимости, запланировать изменения в следующий спринт. Главное, что выполнение задач будет упорядоченным, а баги можно будет фиксировать сразу, не дожидаясь финальной версии билда.

Планирование и спринт

Твоя команда, сделанная из Лего

Планированию мы отводим отдельный день, ставим цели спринта, забираем user story из backlog’а, разбиваем их на задачи, расставляем приоритеты и проставляем сроки. Просрочки — это плохо. Это значит, что цели спринта не достигнуты.

Но после нескольких спринтов процесс уже налажен: задачи, сроки и приоритеты отскакивают от зубов.

Подсказка: разбивайте большие задачи на подзадачи, чтобы вопросов не оставалось, а сроки выполнения были максимально прозрачны.

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

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

Во-первых, это позволяет контролировать самого себя. Особенно актуально для гейм-дизайнера, ведь можно залезть в такие дебри, в которые изначально не планировал, и потратить на это больше времени, чем нужно. К примеру, это касается баланса. Во время расчетов пришла идея, но её проработка явно требует больше времени — такие объемные задачи лучше дорабатывать в следующем спринте.

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

Демонстрация

Но увы, вы просрали все спринты

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

Ретроспектива

Даже они проводят ретро!

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

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

Мы не переходим к планированию в день ретроспективы. Во-первых, планировать нужно с холодной головой, впопыхах может выйти совсем не то, что хотелось бы видеть — плавали, знаем :) и потом, всегда найдется, что можно доработать напильником, пофиксить, обдумать и т.п. в остатке дня. Поэтому планирование мы проводим на следующий день после ретро. Затем начинаем новый спринт.

Заключение

Для нас Scrum стал весьма полезной штукой. Многие спрашивают, зачем вам Scrum, ведь вы маленькая инди-команда. Но мы имели неудачный опыт с другими методиками, решили попробовать и не жалеем. Ведь у нас, как у инди — не будет времени тестировать финальный билд, поэтому для нас так важно проводить проверки уже на этапе разработки.


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

В ней детально описывается применение методологии на еще одном живом примере.

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

На этом всё. Спасибо за внимание.

kroha-go-away

 
Артем Волков
Артем Волков
Professional Dreamer / Lead Game Designer @ Rocket Jump