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

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

Рис. 9. Цикл разработки Waterfall

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

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

AGILE

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

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

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

Цикл разработки в Agile выглядит так:

Рис. 10. Цикл разработки в Agile

И Agile, и Waterfall позволяют создавать качественные продукты. Большинство игровых компаний используют гибридные методы этих двух методологий, в чистом виде они почти не встречаются. Если у заказчика есть четкое понимание, чего он хочет, а у вас – как воплотить это в жизнь, более жесткие процессы Waterfall могут быть эффективнее. Если же игра содержит экспериментальные идеи, заказчики хотят вносить изменения, а на реализацию мало времени – обратите внимание на методы Agile.

SCRUM

Scrum – один из самых популярных способов практического внедрения философии Agile. Он подходит в основном небольшим командам до 10 человек, причем используется повсеместно, не только в IT-сфере. Предполагается, что некоторые члены команды возьмут на себя определенные роли, обязанности и будут соблюдать четыре постоянно повторяющиеся «церемонии»:

• планирование спринта[37] (итерации);

• регулярный стенд-ап;

• подведение итогов по задачам спринта;

• ретроспектива спринта.

Давайте разберем их подробнее.

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

Рис. 11. Схема Scrum

Если коротко, на практике все это выглядит так.

1. Прежде всего назначается ВЛАДЕЛЕЦ ПРОДУКТА (PRODUCT OWNER). Это человек, который лучше всех знает, что за продукт вы делаете, и определяет его видение. Чаще всего именно ему принадлежит идея, и именно он отвечает за бэклог[38]. В реальных условиях роль этого человека во многом схожа с ролью продюсера проекта.

2. После того как команда собрана, следует выбрать СКРАМ-МАСТЕРА (SCRUM MASTER). Это должен быть самый организованный человек на проекте, способный следить за эффективной работой всех участников. Он не обязательно хороший управленец; главная его задача – помогать всем соблюдать методы Scrum, приоритезировать задачи и улаживать кризис. Можно не назначать его специально: подходящий на эту роль человек сам, скорее всего, не выдержит беспорядка и предложит свою кандидатуру.

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

Чтобы не возникало конфликта интересов, один человек не должен выполнять роль и Scrum Master, и Product Owner – они должны дополнять друг друга. Кроме этих двоих, все занимаются своей обычной работой.