Ознакомительная версия. Доступно 11 страниц из 52
начала 2000-х годов. Смысл в том, что очень много времени мы отводим на тщательное составление четкой документации и лишь после этого приступаем непосредственно к разработке. Проблема в том, что составить адекватный подробный план на год вперед – крайне сложная задача.
Такой подход основан на линейном, последовательном цикле разработки: концепт → составление документации → аналитика и сбор информации по рынку → дизайн → программирование → тестирование → поддержка.
Рис. 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 – они должны дополнять друг друга. Кроме этих двоих, все занимаются своей обычной работой.
3. Далее СОЗДАЕМ БЭКЛОГ – хранилище всех идей, связанных с проектом. Во многом Scrum – про демократию, так что обычно любой участник команды может внести свою идею для дальнейшего ее обсуждения с командой. К тому же, когда каждый может высказаться, уменьшается риск пропустить эффективное решение.
Бэклог постоянно дополняется новыми инициативами и идеями, так что ситуация, когда ваша игра давно в сторах (магазинах), хотя в бэклоге полно невыполненных задач, встречается нередко.
4. Потом команда собирается, чтобы обсудить и ОЦЕНИТЬ ЗАДАЧИ. Молодым командам сложно сразу правильно определить, сколько времени и ресурсов уйдет на то или иное действие. Определите хотя бы два параметра: длительность (насколько задача трудоемкая) и риски (что может пойти не так).
В игровых студиях, работающих по Agile, исполнители часто сами оценивают поставленные задачи. Иногда эту функцию берет на себя Scrum-мастер, например если сотрудник – новичок или ранее он уже оценивал свои задачи неправильно.
5. Далее ПЛАНИРУЕМ СПРИНТ. Мы просмотрели, оценили наши задачи и убедились, что можем уложиться в сроки спринта (это может быть неделя, две недели, три недели, месяц).
Спринт – это итерация. Он жестко фиксирован по времени, и каждая команда определяет для себя оптимальный срок спринта. Чем он короче, тем более гибким становится процесс разработки, меньше ресурсов тратится на неправильные задачи, чаще демонстрируется результат. Однако есть риск много времени и сил тратить на презентации продукта и совещания.
Современный подход говорит о том, что директивно раздавать задачи – не всегда эффективно. Если никто в команде не хочет браться за какую-то задачу, это повод обсудить, насколько проекту вообще она нужна. Это верно для небольших команд. Для крупных комплексных проектов, где все фичи взаимосвязаны (ММО, MOBA и пр.), такое решение может мгновенно привести к коллапсу, так что следует быть осторожным. Однозначных ответов здесь нет, все зависит от конкретной команды и проекта.
6. ЕЖЕДНЕВНЫЙ СТЕНД-АП позволяет всем
Ознакомительная версия. Доступно 11 страниц из 52
